[Bug inline-asm/56621] Misaligned stack with inline assembly

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56621



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||INVALID



--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-14 
18:58:12 UTC ---

No, that is just bogus inline asm, for multiple reasons.

message_size is 32-bit, so using movq on it means you can end up with arbitrary

garbage in the high 32-bits.  E.g. I see:

write(1,

test\n\0\0\0\5\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0005\27\202\351?\0\0\0...,

4294967301) = -1 EFAULT (Bad address)

where 4294967301 is 0x10005.  You'd want movl instead, which will zero the

upper 32 bits.

Also, nothing tells the compiler that the clobbered registers are clobbered

before consuming the inputs, the compiler could assign one of the two inputs to

the clobbered registers.  Better just use long dummy; int dummy2; ... =S

(dummy), =d (dummy2) ... : 0 (message), 1 (message_size) ...

then you don't need to do any of the bogus moves first, the compiler will

arrange all of that.  Or why aren't you just using syscall function, or write?

[Bug inline-asm/56621] Misaligned stack with inline assembly

[auc42 at yahoo dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56621



--- Comment #2 from auc42 at yahoo dot com 2013-03-14 20:00:56 UTC ---

Ah, I had forgotten to change tmp back to a long in the code snippet

provided.  I was experimenting to see variations of the generated assembly

while using different types.  The failure is present with both the 8-byte long

and 4-byte int, in this case.



I accept your explanation about the clobbered registers, though.  I apparently

misunderstood how clobber declarations worked (and in re-reading the manual,

either I'm still missing something or the text isn't very clear).  Placing the

variables directly in the S and d registers and skipping the movX instructions

eliminates the problem.  I suppose that the sequence only worked by

happenstance in earlier versions of gcc.



(As for the reason of doing it this way: the original code was avoiding use of

the C standard library and/or any include files, as a personal learning

exercise toward a later program.)