From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7195 invoked by alias); 10 Jun 2011 14:11:43 -0000 Received: (qmail 7161 invoked by uid 22791); 10 Jun 2011 14:11:40 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 10 Jun 2011 14:11:25 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id p5AEBJ0j008865; Fri, 10 Jun 2011 16:11:19 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id p5AEBHnx000301; Fri, 10 Jun 2011 16:11:17 +0200 (CEST) Date: Fri, 10 Jun 2011 14:11:00 -0000 Message-Id: <201106101411.p5AEBHnx000301@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: jakub@redhat.com CC: libc-alpha@sourceware.org, binutils@sourceware.org, gdb@sourceware.org, mjw@redhat.com, fche@redhat.com In-reply-to: <20110610074524.GR17079@tyan-ft48-01.lab.bos.redhat.com> (message from Jakub Jelinek on Fri, 10 Jun 2011 09:45:24 +0200) Subject: Re: RFC: Unwind info for PLT References: <20110610074524.GR17079@tyan-ft48-01.lab.bos.redhat.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-06/txt/msg00070.txt.bz2 > Date: Fri, 10 Jun 2011 09:45:24 +0200 > From: Jakub Jelinek > > Hi! > > gdb apparently has some code to default to a certain unwind info if > no FDE is found, as b 'f0001@plt'; c; bt; works and stepi; bt; works > too, but next stepi; bt; already gives > #0 0x0000000000494f73 in f0001@plt () > #1 0x0000000000000be7 in ?? () > #2 0x00000000004b03d8 in main () at prg1.c:29 > instead of > #0 0x0000000000494f73 in f0001@plt () > #1 0x00000000004b03d8 in main () at prg1.c:29 > But when doing b 'f0002@plt'; c; then kill -USR1 `pidof prg1` from > another terminal and then continuing, the backtrace shown stops in > the plt and doesn't go back. Typically PLT entries are handled by unwinders that analyze the code, either by the default unwinder that does standard prologue analysis (sparc/sparc64) or a dedicated unwinder (s390 for example). For most targets this isn't a big issue, since the PLT stubs are typically defined by the appropriate ABI. Generally the most difficult part is to figure out where the PLT entries actually start since linkers are a bit inconsistent in choosing symbol names for the start of the PLT, and not all targets have a proper .plt section. Looks like we don't do a particular good job on amd64 though. Seems nobody actually bothered to do this properly for i386/amd64, probably because it mostly works without special code. > I wonder whether ld couldn't synthetize unwind info for the .plt > section (perhaps with some option), A potential problem here is that the PLT entries get patched up by the dynamic linker. You must make sure that the unwind info is correct for both the unpacthed and patched versions of the PLT entries. That may not be possible. But otherwise I think this is a sound idea. > or alternatively if it couldn't just provide hidden > __PLT_START__/__PLT_END__ or similar symbols and the unwind info > couldn't be written in glibc crtfiles linked into it. I don't think I fully understand what you're trying to say here. Sounds complicated/fragile. The canonical name for the start of the PLT is _PROCEDURE_LINKAGE_TABLE_, but as I said the PLT isn't consistently named across toolchains. I think for GNU ld, the name is assigned by a linker script, which people tend to replace by something they've written themselves. > 00000035e7a1ec60 : > 35e7a1ec60: ff 25 9a 33 37 00 jmpq *0x37339a(%rip) # 35e7d92000 <_GLOBAL_OFFSET_TABLE_+0x18> > 35e7a1ec66: 68 00 00 00 00 pushq $0x0 > 35e7a1ec6b: e9 e0 ff ff ff jmpq 35e7a1ec50 That pushq instruction is the reason you get that weird backtrace. > Anyway, I think hardcoding this in the linker would be problematic, > we couldn't tweak it, so providing some special hidden symbols around > the .plt section and let glibc crtfiles provide it sounds like the best > option to me. Well, the linker is the one generating/inserting the PLT entries. So it should know how to generate unwind infor for them. I really don't see how you could make sure that the description provided the crtfiles are consistent with what the linker generated.