From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21909 invoked by alias); 6 Jun 2003 21:40:08 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21894 invoked from network); 6 Jun 2003 21:40:07 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 6 Jun 2003 21:40:07 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19OOx6-0008Hl-00; Fri, 06 Jun 2003 16:40:48 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19OOwN-0002yt-00; Fri, 06 Jun 2003 17:40:03 -0400 Date: Fri, 06 Jun 2003 21:40:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: [ppc64-linux]: skip linkage functions Message-ID: <20030606214003.GA11393@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com References: <20030606000328.GA26538@nevyn.them.org> <20030606131122.GA20576@nevyn.them.org> <20030606201718.GA30328@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-06/txt/msg00244.txt.bz2 On Fri, Jun 06, 2003 at 03:31:58PM -0500, Jim Blandy wrote: > Daniel Jacobowitz writes: > > > On Fri, Jun 06, 2003 at 03:10:09PM -0500, Jim Blandy wrote: > > > Daniel Jacobowitz writes: > > > > > > > On Fri, Jun 06, 2003 at 01:22:27AM -0500, Jim Blandy wrote: > > > > > Daniel Jacobowitz writes: > > > > > > > > > > > On Thu, Jun 05, 2003 at 06:54:57PM -0500, Jim Blandy wrote: > > > > > > > > > > > > > > 2003-06-05 Jim Blandy > > > > > > > > > > > > > > Recognize and skip 64-bit PowerPC Linux linkage functions. > > > > > > > * ppc-linux-tdep.c (insn_d, insn_ds, insn_xfx, read_insn, struct > > > > > > > insn_pattern, insns_match_pattern, d_field, ds_field): New > > > > > > > functions, macros, and types for working with PPC instructions. > > > > > > > (ppc64_standard_linkage, PPC64_STANDARD_LINKAGE_LEN, > > > > > > > ppc64_in_solib_call_trampoline, ppc64_standard_linkage_target, > > > > > > > ppc64_skip_trampoline_code): New functions, variables, and macros > > > > > > > for recognizing and skipping linkage functions. > > > > > > > (ppc_linux_init_abi): Use ppc64_in_solib_call_trampoline and > > > > > > > ppc64_skip_trampoline_code for the 64-bit PowerPC Linux ABI. > > > > > > > > > > > > Hmm. Probably not good enough for our needs, but is the > > > > > > DW_AT_trampoline attribute useful here? > > > > > > > > > > I'll say it, so nobody else has to feel bad saying it: that patch is > > > > > complete shite. I just can't see any other way to do it with the info > > > > > I have. > > > > > > > > > > DW_AT_trampoline would allow me to implement in_solib_call_trampoline > > > > > and skip_trampoline_code simply by consulting the debugging info, > > > > > which would be eons better. And in generic code, to boot. The only > > > > > thing is, the trampolines are generated by the linker, not the > > > > > compiler. Could the linker contribute its own Dwarf compilation unit > > > > > to .debug_info and .debug_abbrev? How should it decide which > > > > > debugging format to use, and whether to emit anything at all? > > > > > > > > > > If we could get this working, we could start using it on other > > > > > architectures, too. > > > > > > > > Hmm. I believe it could be done. It would probably require adding > > > > a --gdwarf2 to the linker, matching the one added to GAS. It's > > > > certainly practical for the linker to add a CU. > > > > > > > > As always, it wouldn't free us from the need to grub through assembly > > > > trampolines by hand. There's always something without debug info. But > > > > it would make that code a little less important... > > > > > > I haven't been living with CFI long enough to know how these stories > > > turn out, but my gut feeling is that replacing these heuristic > > > techniques like prologue unwinding with real debug info has got to be > > > the Right Thing. > > > > The only problem is that DW_AT_trampoline doesn't live in the CFI - it > > lives in the .debug_info section with the full debug info. Some > > architectures are moving to always providing CFI, but debug info is > > more than we can count on. > > Oh, I know where DW_AT_trampoline lives. I was referring to the > general trend of providing debug info for stuff GDB previously had to > guess about, e.g., CFI and location lists replacing prologue analysis. > You can never really get rid of the old heuristics, but since they > won't be used every day any more, they're going to bit-rot. Even if > we included actual binaries in the test suite to make sure the > prologue analyzers continued to recognize what we'd once taught them, > compilers will continue to change the prologues they emit. In the > end, if it rots badly enough, is it worth keeping it at all? > > > What blows up if we don't recognize the trampolines though? > > On the PPC64, 'next' blows up. Oh, I hit this problem on another platform recently. And I had to do a similar hack for trampolines. It seems that there shold be a simpler solution than trying to parse the trampoline... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer