This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH]: Setup sparc32 to support dwarf2 unwind sniffer
From: "Mark Kettenis" <mark.kettenis@xs4all.nl>
Date: Wed, 5 Apr 2006 11:11:05 +0200 (CEST)
> > This is very desirable because many current Sparc bugs are due to
> > the fact that sparc_analyze_prologue() cannot deal at all with clever
> > assembler sequences, for example in cases where the save is deferred
> > to somewhere past the beginning of the function which is also a
> > valid compiler optimization.
>
> Perhaps we should try to address those issues. I never went through the
> trouble of making the sparc and sparc64 prologue analyzers any smarter,
> because I never encountered any code that made it fail. This is probably
> because OpenBSD/sparc64 uses GCC 3.3.5 (and OpenBSD/sparc uses an even
> older compiler). If you can post some disaambly of (real-life) prologues
> that the current unwinder doesn't handle, I'll happiliy turn them into
> testcases and try to improve the analyzer.
I think working on making the sparc prologue analyzer smarter is
a double edged sword personally.
On the one hand I could argue that dwarf2 unwind information solves
all of these problems.
On the other hand I know that without some kind of sophisticated
prologue analyzer we'll never have reasonable backtraces in things
like JIT compilers such as Mono, which is an incredibly hard piece
of code to debug because of this. There is no symbol information
or function start/end markers available to gdb when there are JIT
compiled functions in the backtrace, so this is not an easy problem
to solve.
Anyways, here is an example of a code sequence that didn't work with
the current prologue analyzer:
<nanosleep>: ld [ %g7 + 0xc ], %g1
<nanosleep+4>: cmp %g1, 0
<nanosleep+8>: bne 0x9e35c <__nanosleep_nocancel+24>
<__nanosleep_nocancel>: mov 0xf9, %g1
<__nanosleep_nocancel+4>: ta 0x10
<__nanosleep_nocancel+8>: bcs 0x9e394 <__syscall_error_handler>
<__nanosleep_nocancel+12>: nop
<__nanosleep_nocancel+16>: retl
<__nanosleep_nocancel+20>: nop
<__nanosleep_nocancel+24>: save %sp, -96, %sp
<__nanosleep_nocancel+28>: call 0xed120 <__libc_enable_asynccancel>
<__nanosleep_nocancel+32>: nop
<__nanosleep_nocancel+36>: mov %o0, %l0
<__nanosleep_nocancel+40>: mov %i0, %o0
<__nanosleep_nocancel+44>: mov %i1, %o1
<__nanosleep_nocancel+48>: mov 0xf9, %g1
<__nanosleep_nocancel+52>: ta 0x10
<__nanosleep_nocancel+56>: bcs 0x9e3bc <__syscall_error_handler2>
<__nanosleep_nocancel+60>: mov %o0, %l1
<__nanosleep_nocancel+64>: call 0xed1c0 <__libc_disable_asynccancel>
<__nanosleep_nocancel+68>: mov %l0, %o0
<__nanosleep_nocancel+72>: ret
<__nanosleep_nocancel+76>: restore %g0, %l1, %o0
<__syscall_error_handler>: save %sp, -96, %sp
<__syscall_error_handler+4>: sethi %hi(0x1000), %l1
<__syscall_error_handler+8>: sethi %hi(0xb4c00), %l7
<__syscall_error_handler+12>: call 0x11e460 <__sparc_get_pic_l7>
<__syscall_error_handler+16>: add %l7, 0x60, %l7 ! 0xb4c60 <re_compile_internal+3456>
<__syscall_error_handler+20>: add %l1, 0xd4, %l1
<__syscall_error_handler+24>: ld [ %l7 + %l1 ], %l1
<__syscall_error_handler2>: call 0xed1c0 <__libc_disable_asynccancel>
<__syscall_error_handler2+4>: mov %l0, %o0
<__syscall_error_handler2+8>: call 0x154354 <__errno_location@plt>
<__syscall_error_handler2+12>: nop
<__syscall_error_handler2+16>: st %l1, [ %o0 ]
<__syscall_error_handler2+20>: ret
<__syscall_error_handler2+24>: restore %g0, -1, %o0
But I hesitate to show this because the compiler can move save/restore
sequences to arbitrary places, and this makes the most obvious approaches
to handle this easy to fool.
For example, your first idea might be to walk from the first instruction
up to current_pc looking for a save, but this does not analyze the
control transfer instructions, what if current_pc is in a basic block
outside of the save/restore sequence? You'll interpret things incorrectly
in that case. You really have to analyze the control transfers to get
this right. Example:
.text
.globl func
func:
cmp %o0, 1
be 1f
nop
save %sp, -96, %sp
call some_other_func
mov %i0, %o0
restore %g0, %g0, %g0
1: add %o0, 5, %o0
retl
nop
So if the PC were at "1", the naive analyzer would see the "save"
when scanning from func to PC and thing that we have a frame, when
in fact we're in the "frameless" part of the function.
Another case you'll run into problems with are PLT entries and that
trick we use to move the PC back to the first PLT entry where the save
is. That causes problems for testcases such as recurse.exp when
emitting sparc v7 code and this the multiply in the test case expands
into a library call through the PLT. When we try to step over the
multiply it hits the PLT and the frameless_p logic gets very confused.
This is a deep and dark passage and I've been down it before. :-)
My recommendation is:
1) For things like the above code sequence, depend upon dwarf2
unwind information. If the compiler starts to defer save/restore
sequences in the same way, it will emit the proper dwarf2 information
just like the glibc by-hand assembler above does.
2) For PLT entry sequences, each target knows what it's PLT entries
look like so should provide the frame building logic or at least
the helper functions to help the prologue analyzer decide what to
do.
> > Ok to apply?
>
> Yes, thanks!
Thanks for reviewing, applied.