Another Unaligned Access/Code Generation Question

[Jay Estabrook]

Hi, Sergey!

Sergey Tikhonov wrote:
>>
> Please, take a look at kde patches from AC3 distro.
> I remember that some there in kde where was a double/float value defined
> as sequence of bytes in the middle of char
> arrays definitions. Later on it was stored into a data section as
> unaligned. I remember adding some long dummy variable
> in front of that to force the defined double to be correctly aligned.

That sounds just like something that would cause the problem I see.

> As for dbus problem - I was using temporary volatile pointer to the
> passed structure (patches are in AC3 tree) and that forced the
> compiler to generate the correct code.

Yes, exactly; my point was that the two compilers reacted differently
to the same code, and only the final version (with "volatile") would
work on both. I was looking for guidelines that wouold say either
"that's the way to do it", or propose something more reliable... ;-}

> I remember I discussed that problem sometime ago with some guy from
> debian and Richard (gcc alpha patcher).
> It seems that in current case that gcc assumption might be correct - it
> expects that the passed pointer to that union is aligned.
> At it is supported by declaration of that function. That problem is that
> the caller assigns value to that pointer just from some data it has
> (I guess some buffer received over network if I remember correctly).

Yes again; the union allowed an easy way to take an arbitrary address
and pick up an arbitrary-length datum located there.

> To make it to work correctly it is necessary to use temporary structure
> on caller side and do byte copy of data into it and then call our
> "problem" method or teach the method to not assume that pointer is
> properly aligned.

I went with the latter, obviously; in this case, there was only one
place where the "char" store was being done, so only one place to fix.
The other data lengths actually had some funky alignment code in them,
and thus didn't need to be fixed.

Other situations might require other remedies; a different application
went to great lengths to do its own "optimized" memcpy/memset
operations, but in fact on Alpha, they generated UAs. Fortunately, they
left on option to just use GCC's memcpy/memset instead, and presto!
Fixed on Alpha... :-)

> Again, I remember fixing most of the UAEs during AC2/AC3 preparations.

Thanks for all the work you did on making AC2/3 as good as they were.
I'll be looking into those SRPMS you made later today!!! :-) :-)

Thanks again, Sergey.

--Jay++