From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 325 invoked by alias); 6 Jun 2003 20:31:30 -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 32763 invoked from network); 6 Jun 2003 20:31:29 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 6 Jun 2003 20:31:29 -0000 Received: by zenia.home (Postfix, from userid 5433) id BCAE320FE6; Fri, 6 Jun 2003 15:31:58 -0500 (EST) To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [ppc64-linux]: skip linkage functions References: <20030606000328.GA26538@nevyn.them.org> <20030606131122.GA20576@nevyn.them.org> <20030606201718.GA30328@nevyn.them.org> From: Jim Blandy Date: Fri, 06 Jun 2003 20:31:00 -0000 In-Reply-To: <20030606201718.GA30328@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00240.txt.bz2 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.