Re: unwind_stack() and an exception at the last instruction (after the epilogue)

["Dmitry Adamushko" <dmitry.adamushko@gmail.com>]

> > gcc version 3.4.2
>
> I figure it doesn't create such an zero access as shown in the example.

the code in question intentionally dereferenced a NULL pointer.

the funny thing is that when it's like this :

void cause_oops(void)
{
        unsigned long *addr = NULL;

        printf("Let's crash...");     // (1)
       *addr = 0;                     // (2)
}

the compiler (-g -Os) generates the code as I have sent before, iow
with "sw zero, 0(zero)" in the delay slot [see, the compiler is kindof
smart as it elimimates a need to store "addr" on stack :]
But if I change the order of (1) and (2), the generated code is different

00401364 <cause_oops>:
  401364:       3c1c0fc0        lui     gp,0xfc0
  401368:       279c6cec        addiu   gp,gp,27884
  40136c:       0399e021        addu    gp,gp,t9
  401370:       8f84801c        lw      a0,-32740(gp)
  401374:       8f9980b0        lw      t9,-32592(gp)
  401378:       ac000000        sw      zero,0(zero)
  40137c:       03200008        jr      t9
  401380:       24842010        addiu   a0,a0,8208

So the "prologue" and "epilogue" are omitted, that's good.

>
> It looks rather broken, given that the stack frame is only used to
> pointlessly push s8 around. The compiler should have optimized it away.

Yes, all the "broken" functions (there are a few in sched.o) have at
least one thing in common - they don't use stack at all, aside of
storing the frame pointer (s8).


> > Are there any configure options that might have caused such a
> > behaviour [hmmm... e.g. gcc was configured with --ignore-abi-rulles :]
> > ? Although, I don't think this would be an option-dependent case.
>
> Well, breakage happens from time to time in gcc. To cover such cases
> it would be nice to have a more robust stack unwinder, but that's easier
> said than done.

Yep, but this would add additional complexity which is not that
necessary for the common path.

e.g. as we know the start and end address of the function
(ksyms_lookup_size_off()), it's possible to find out a position of the
"prologue" and "epilogue" (addiu sp,sp,SIZE - the same way it's done
in get_frame_info()) so we would know:

function_start (1), prologue_addr (2), epilogue_addr (3), function_end (4)

and this would cover the (broken) cases when <epc> is in [1, 2] or [3, 4]
as well as the cases when e.g. <sp> is broken in the prologue ?

Anyway, thanks for the conversation.


>
> Thiemo
>


-- 
Best regards,
Dmitry Adamushko