I don't think that is an alignment issue. What you wrote isn't even
convincing that there is anything wrong with the way type was passed.
But I don't know what exactly an Atom is, so I'm not sure how it should
be passed. Most importantly, how many bits are there in an Atom as
compiled for your architecture.
Rémi Cardona wrote:
- but if I break inside XGetWindowProperty, "type" changes completely
and seems to take some of the bytes of the adjacent parameter
(0x7fff00000089, when "size" is 0x7fff379c7704, the coincidence is
just too big IMHO).
That doesn't track as an alignment issue. It tracks as a left over data
issue.
If an Atom is passed as 32 bits or less, it still takes 64 bits of stack
or register space, but the high order 32 bits may be undefined. Those
undefined bits have the left over value of some other data that the
calling program happened to use earlier.
That brings me to three possibilities:
1) It is correct to pass an Atom as 32 bits with the high 32 undefined,
and the called routine correctly uses it that way and you are confused
by gdb and your problem is somewhere else.
2) It is correct to pass an Atom as 32 bits with the high 32 undefined,
but the called routine incorrectly uses the high bits.
3) It is incorrect to pass an Atom as 32 bits with the high 32 undefined.
