From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5243 invoked by alias); 5 Apr 2006 18:54:14 -0000 Received: (qmail 5222 invoked by uid 22791); 5 Apr 2006 18:54:13 -0000 X-Spam-Check-By: sourceware.org Received: from dsl027-180-168.sfo1.dsl.speakeasy.net (HELO sunset.davemloft.net) (216.27.180.168) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Apr 2006 18:54:07 +0000 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.60) (envelope-from ) id 1FRD7H-0005vu-9J; Wed, 05 Apr 2006 11:52:31 -0700 Date: Wed, 05 Apr 2006 18:54:00 -0000 Message-Id: <20060405.115217.71367429.davem@davemloft.net> To: mark.kettenis@xs4all.nl Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH]: Setup sparc32 to support dwarf2 unwind sniffer From: "David S. Miller" In-Reply-To: <11768.192.87.1.22.1144228265.squirrel@webmail.xs4all.nl> References: <20060404.202940.38078716.davem@davemloft.net> <11768.192.87.1.22.1144228265.squirrel@webmail.xs4all.nl> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00058.txt.bz2 From: "Mark Kettenis" 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: : ld [ %g7 + 0xc ], %g1 : cmp %g1, 0 : 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 <__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.