> 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 :
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
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.