Sumanth Gundapaneni <Sumanth.Gundapaneni@xxxxxxxxxxxxxxx> writes:
> After debugging the unwinder code, we found out that the problem arises
> because of optimization flags -fno-gcse and -fno-dse. After defining
> LIBGCC2_UNWIND_ATTRIBUTE macro to
> __attribute__((optimize("no-dse","-no-gcse"))) , things looks a bit better.
>
> Comparing the object dumps with and without -fgcse
>
> Code snippet with -fno-gcse
> push $0x2,r0
> loadd 0x50:l(r12),(r1,r0)
> jal (r1,r0)
> addd $0x8:s,(sp)
>
> code snippet with -fgcse
> push $0x2,r0
> jal (r11,r10)
> addd $0x8:s,(sp)
>
> NOTE : r12 is PIC register
> jal jumps to address specified in register pair (r1,r0)
>
> With -fgcse optimizes PIC load instruction and jumps to address specified by
> (r11,r10) register pair . But (r11,r10) has no pointer stored in it. This is
> the place where my kernel gets crashed because of corrupted JAL.
>
> How can I make sure my LOAD instruction won't get optimized away with -fgcse.
GCSE certainly should not optimize away a necessary load. What makes it
think that it can simply jump to r11,r10? Where are the values being
loaded into those registers? Why does GCSE think that the value in
those registers is still valid at the point of the jal?
Ian
