This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]