[osiris-devel] Osiris 2.4.4-stable released

[Brian Wotring]

bash-2.05$ make
gcc -m32 -g -O2 -Wall -o dump dump.c
bash-2.05$ file dump
dump:           ELF 32-bit MSB executable SPARC Version 1, dynamically 
linked, not stripped
bash-2.05$ ./dump
Bus Error (core dumped)

On Jan 29, 2004, at 12:43 PM, Alexei Roudnev wrote:

> Yes, but adjustmenmt depends of the memory model, so it shoul not  be 
> used
> in protocol, when possible.
>
> I agree (may be) that it is reasonable to keep **64 adjustments 
> instead of
> **32 ones. Anyway, 2.4.4 works on all Solaris systems without any 
> problems;
> I believe, that failure was caused by using /64 bit mode instead of 
> /32 bit
> mode (no any good reason to use 64 bits in Osiris).
>
> Sparc GCC:
>      -m32
> -m64
> Generate code for a 32-bit or 64-bit environment. The 32-bit 
> environment
> sets int, long and pointer to 32 bits. The 64-bit environment sets int 
> to 32
> bits and long and pointer to 64 bits.
>
>
> Of course, it may be too late change osiris-3 back.
>
> PS, Strange example - it is 100% machine dependent... This program 
> violate
> all possible rules.Additionally, internal data structures should not 
> be used
> in network without packing/unpacking or binary<->text conversion. 
> Windows
> have pragma to control data adjustment; moreover, it is critical to
> translate SSL in the same mode, as your program (we had some fun with 
> this
> problem 1 year ago).
>
> ----- Original Message -----
> From: "Brian Wotring" <brian at shmoo.com>
> To: "Osiris Developers" <osiris-devel at lists.shmoo.com>
> Sent: Thursday, January 29, 2004 7:37 AM
> Subject: Re: [osiris-devel] Osiris 2.4.4-stable released
>
>
>>
>> Here is an example of code that will seg, it demonstrates the problem,
>> exactly.  Correctly define the foo structure with an additional short,
>> and everything is happy.
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <string.h>
>>
>> struct foo
>> {
>>      short x;
>>      short y;
>>      short z;
>> };
>>
>> struct bar
>> {
>>      long long gold;
>>      char buf[1024];
>> };
>>
>> int main()
>> {
>>      struct foo myfoo;
>>      struct bar mybar;
>>
>>      struct bar * realbar;
>>
>>      char *buf = (char *)malloc( sizeof( myfoo ) + sizeof( mybar ) );
>>      mybar.gold = 4;
>>
>>      memcpy( buf, &myfoo, sizeof( myfoo ) );
>>      memcpy( (buf+sizeof(myfoo)), &mybar, sizeof( mybar ) );
>>
>>      realbar = (struct bar *)( buf + sizeof( myfoo ) );
>>      fprintf( stderr, "gold is: %llu\n", realbar->gold );
>>
>>      return 0;
>> }
>>
>>
>> On Jan 28, 2004, at 11:42 AM, Alexei_Roudnev wrote:
>>
>>> It is not hardware issue; it is (more likely) compilation mode issue.
>>> For
>>> Solaris, I strongly recommend to have binary version, built on 
>>> Solaris
>>> 2.7 /
>>> Ultra Sparc / 32 bits, which can work on ANY hardware and ANY 
>>> software
>>> (Solaris 2./7 - 2.9), and forget about this problem. You can not 
>>> align
>>> network data structure to theparticular hardware (what if next Sun
>>> will have
>>> 126bit mode - change structures again?).
>>>
>>> Moreover, I am 100% sure that C compiler allows to use un-aligned
>>> structures
>>> in 64 bit mode, just look for the compiler options.
>>>
>>> ----- Original Message -----
>>> From: "Brian Wotring" <brian at shmoo.com>
>>> To: "Osiris Developers" <osiris-devel at lists.shmoo.com>
>>> Sent: Wednesday, January 28, 2004 5:07 AM
>>> Subject: Re: [osiris-devel] Osiris 2.4.4-stable released
>>>
>>>
>>>>
>>>> You are correct, it would effect OpenBSD running on this hardware.
>>>>
>>>> On Jan 27, 2004, at 6:02 PM, Richard Johnson wrote:
>>>>
>>>>> At 06:23 -0700 on 2004-01-26, Brian Wotring wrote:
>>>>>> - - this release changes the message header structure used
>>>>>>    throughout the components of the Osiris sytem.  Thus,
>>>>>>    this release is not compatible with previous releases.
>>>>>>    The changes was necessary in order to fix an alignment
>>>>>>    problem on Solaris.
>>>>>
>>>>>
>>>>> While I understand this fix isn't actually in until the rel_3_dev
>>>>> branch,
>>>>> the alignment problem doesn't seem to affect just Solaris:
>>>>>
>>>>>  | $ uname -mpsv
>>>>>  | OpenBSD GENERIC#4 sparc64 SUNW,UltraSPARC-IIi @ 333 MHz, 
>>>>> version 0
>>>>> FPU
>>>>>  | $ dmesg | grep '3.4-current'
>>>>>  | OpenBSD 3.4-current (GENERIC) #4: Fri Jan 23 17:29:32 MST 2004
>>>>>  | $ osiris
>>>>>  | Osiris command line management utility - version 2.4.4-stable
>>>>>  | authenticating to (localhost)
>>>>>  |
>>>>>  | User: admin
>>>>>  | Password:
>>>>>  |
>>>>>  | [frozen here]
>>>>>
>>>>> The freeze noted in 2.4.4 does not occur in 3.0.1-current, so I
>>>>> suspect the
>>>>> alignment fix was the key for OpenBSD sparc64 support as well.
>>>>>
>>>>>
>>>>> Richard
>>>>> _______________________________________________
>>>>> osiris-devel mailing list
>>>>> osiris-devel at lists.shmoo.com
>>>>> https://lists.shmoo.com/mailman/listinfo/osiris-devel
>>>>>
>>>>>
>>>> --
>>>>      Brian Wotring ( brian at shmoo.com )
>>>>      PGP KeyID: 0x9674763D
>>>>
>>>> _______________________________________________
>>>> osiris-devel mailing list
>>>> osiris-devel at lists.shmoo.com
>>>> https://lists.shmoo.com/mailman/listinfo/osiris-devel
>>>>
>>>
>>> _______________________________________________
>>> osiris-devel mailing list
>>> osiris-devel at lists.shmoo.com
>>> https://lists.shmoo.com/mailman/listinfo/osiris-devel
>>>
>>>
>> --
>>      Brian Wotring ( brian at shmoo.com )
>>      PGP KeyID: 0x9674763D
>>
>> _______________________________________________
>> osiris-devel mailing list
>> osiris-devel at lists.shmoo.com
>> https://lists.shmoo.com/mailman/listinfo/osiris-devel
>>
>
> _______________________________________________
> osiris-devel mailing list
> osiris-devel at lists.shmoo.com
> https://lists.shmoo.com/mailman/listinfo/osiris-devel
>
>
--
     Brian Wotring ( brian at shmoo.com )
     PGP KeyID: 0x9674763D