<larsc>
if for example offset was not the last parameter to the systemcall we would loose the assigments of the registers which come after it as well
<mwalle>
but thats only a workaround isn't it?
<larsc>
maybe
<larsc>
and it works
<mwalle>
i dont see what should be wrong with the original code
<larsc>
the problem here apparently is that if we do a function call after assigning the register the contents of that register is lost
<mwalle>
where are we doing a function call?
<larsc>
shift is a function call
<mwalle>
are we still talking about the mmap syscall function? :)
<larsc>
yes
<larsc>
offset >> 12 evaluates to __shri(offset, 12) or whatever that function is called
<larsc>
because we compile without barrel shifters enabled
<mwalle>
but thats outside the __syscall_mmap2 function
<larsc>
one would think so
<mwalle>
so gcc forgets about the input variables after its inlining the functions?!
<larsc>
it's probably some strange optimisation side effect
<mwalle>
both -fno-dce or -fkeep-inline-functions are working (with the original code), so i would consider this another lm32 gcc bug
<larsc>
it's probably not even lm32 specific
<mwalle>
i bet it is :)
<mwalle>
arm keeps it
<larsc>
x86 too
<larsc>
stuff get's properly reordered, so that the register is loaded after the function call
<mwalle>
larsc: ok so the bug is that the soft shift is not called before the actual function
<mwalle>
and of course the r8 assignment is optimized away, because its a caller saved register
<mwalle>
i bet if that function call would be a 'normal' one (that is not a replacement for an opcode) it works as expected
<larsc>
i think the bug is that gcc somehow forgets that _sco is in the asm instructions operand list
<mwalle>
no if you look at the assemebler output
<mwalle>
        addi    r8, r0, 222
<mwalle>
        or      r1, r6, r0
<mwalle>
        addi    r2, r0, 12
<mwalle>
        calli    __ashrsi3
<mwalle>
r8 may not be valid anymore after calli
<larsc>
i know
<larsc>
but gcc should restore it
<larsc>
put it on the stack or whatever during the function call
<mwalle>
        addi    r2, r0, 12
<mwalle>
        calli    __ashrsi3
<mwalle>
        addi    r8, r0, 222
<mwalle>
        or      r6, r1, r0
<mwalle>
        or      r5, r15, r0
<mwalle>
if you use return __syscall_mmap2(addr, len, prot, flags, fd, __ashrsi3(offset, 12));
<larsc>
hehe
<mwalle>
so it must somewhere in the arch code that translate >> to sri or that function call
<larsc>
so it probably assumes during the optimization phase that >> is a instruction
<mwalle>
lets have a look at the wonderful gcc code :)
<mwalle>
who understands that machine description language? :)
<mwalle>
antgreen: ? :)
<larsc>
i wonder if the same thing would happen if _sco would be used as a parameter for a normal function call
<mwalle>
mh, my microblaze toolchain fails too..
<larsc>
with the same problem?
<mwalle>
yes
<mwalle>
so either this is a general problem with libgcc calls or both implementations are crap :)
<larsc>
hm, i wonder what keywords to search for in the gcc bugtracker
<mwalle>
dunno, i dont even know how that mechanism works.. when is a call to libgcc emitted..
<larsc>
i would assume it is the default
<mwalle>
there are three methods to replace a shift, call to libgcc helper, barrelshifter or multiple shift by one
<larsc>
hm, the documenation doesn't look to bad: gcc/doc/gccint.info
<mwalle>
wonders if we are violating some internal gcc assumptions
<mumptai>
moin
<mwalle>
larsc: ok avr has the same problem
<mwalle>
i'm not sure if we are violating some constraints ..
<mwalle>
n the above example, beware that a register that is call-clobbered by the target ABI will be overwritten by any function call in the assignment, including library calls for arithmetic operators. Also a register may be clobbered when generating some operations, like variable shift, memory copy or memory move on x86. Assuming it is a call-clobbered register, this may happen to r0 above by the assignment
<mwalle>
to p2. If you have to use such a register, use temporary variables for expressions between the register assignment and use
<larsc>
so the fix is the right thing to do
<mwalle>
larsc: yes, but i think we have to evaluate all arguments and then assign them to the register variables
<mwalle>
ah arm does that :)
<mwalle>
oh and your proposed fix too, i missed the fact, that LOAD_ARGS is in the middle