Message ID | 20190816155753.GA22229@delia |
---|---|
State | New, archived |
Headers |
Received: (qmail 41537 invoked by alias); 16 Aug 2019 15:58:00 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 41519 invoked by uid 89); 16 Aug 2019 15:57:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.1 spammy=relocate, FNAME, stabs, Relocate X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Aug 2019 15:57:58 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 9802EAE2F for <gdb-patches@sourceware.org>; Fri, 16 Aug 2019 15:57:56 +0000 (UTC) Date: Fri, 16 Aug 2019 17:57:55 +0200 From: Tom de Vries <tdevries@suse.de> To: gdb-patches@sourceware.org Subject: [PATCH][gdb/symtab] Handle gas-generated stabs with -fPIE/-pie Message-ID: <20190816155753.GA22229@delia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes |
Commit Message
Tom de Vries
Aug. 16, 2019, 3:57 p.m. UTC
Hi, With gdb.dwarf2/dw2-ranges.exp and target board unix/-fPIE/-pie, we run into: ... info line main3^M No line number information available for address 0x55555555464c <main3>^M (gdb) FAIL: gdb.dwarf2/dw2-ranges.exp: info line main3 ... The main3 function in the executable comes from dw2-ranges3.o, which is generated like this (leaving out -fPIE -pie for clarity): ... $ gcc -S dw2-ranges3.c $ gcc dw2-ranges3.s -o dw2-ranges3.o -gstabs ... So, main3 is described in stabs format, generated by gas. The difference between gcc-generated and gas-generated SLINE stabs is that gcc generates a sequence SO (source), FUN (function), SLINE (source line) whereas gas generates SO, SLINE. The problem is that the line address relocation handling in process_one_symbol assumes an order of SO, FUN, SLINE. Fix this by also handling SO, SLINE. This also fixes FAILs in gdb.btrace/instruction_history.exp with target board stabs/-fPIE/-pie. Tested on x86_64-linux with target boards unix, unix/-fPIE/-pie, stabs, and stabs/-fPIE/-pie. OK for trunk? Thanks, - Tom [gdb/symtab] Handle gas-generated stabs with -fPIE/-pie gdb/ChangeLog: 2019-08-16 Tom de Vries <tdevries@suse.de> PR symtab/12497 * dbxread.c (process_one_symbol): Handle relocation of SLINE address without preceding FUN/FNAME. --- gdb/dbxread.c | 3 +++ 1 file changed, 3 insertions(+)
Comments
On 16-08-19 17:57, Tom de Vries wrote: > Hi, > > With gdb.dwarf2/dw2-ranges.exp and target board unix/-fPIE/-pie, we run into: > ... > info line main3^M > No line number information available for address 0x55555555464c <main3>^M > (gdb) FAIL: gdb.dwarf2/dw2-ranges.exp: info line main3 > ... > > The main3 function in the executable comes from dw2-ranges3.o, which is > generated like this (leaving out -fPIE -pie for clarity): > ... > $ gcc -S dw2-ranges3.c > $ gcc dw2-ranges3.s -o dw2-ranges3.o -gstabs > ... > So, main3 is described in stabs format, generated by gas. > > The difference between gcc-generated and gas-generated SLINE stabs is that gcc > generates a sequence SO (source), FUN (function), SLINE (source line) whereas > gas generates SO, SLINE. > > The problem is that the line address relocation handling in process_one_symbol > assumes an order of SO, FUN, SLINE. > > Fix this by also handling SO, SLINE. > > This also fixes FAILs in gdb.btrace/instruction_history.exp with > target board stabs/-fPIE/-pie. > > Tested on x86_64-linux with target boards unix, unix/-fPIE/-pie, stabs, and > stabs/-fPIE/-pie. > > OK for trunk? > Ping. Thanks, - Tom > [gdb/symtab] Handle gas-generated stabs with -fPIE/-pie > > gdb/ChangeLog: > > 2019-08-16 Tom de Vries <tdevries@suse.de> > > PR symtab/12497 > * dbxread.c (process_one_symbol): Handle relocation of SLINE address > without preceding FUN/FNAME. > > --- > gdb/dbxread.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/gdb/dbxread.c b/gdb/dbxread.c > index e339d1f7ec..e0ab4ec19c 100644 > --- a/gdb/dbxread.c > +++ b/gdb/dbxread.c > @@ -2626,6 +2626,9 @@ process_one_symbol (int type, int desc, CORE_ADDR valu, const char *name, > > /* Relocate for dynamic loading and for ELF acc > function-relative symbols. */ > + if (function_start_offset == 0) > + function_start_offset > + = ANOFFSET (section_offsets, SECT_OFF_TEXT (objfile)); > valu += function_start_offset; > > /* GCC 2.95.3 emits the first N_SLINE stab somwehere in the >
On 29-08-19 17:04, Tom de Vries wrote: > On 16-08-19 17:57, Tom de Vries wrote: >> Hi, >> >> With gdb.dwarf2/dw2-ranges.exp and target board unix/-fPIE/-pie, we run into: >> ... >> info line main3^M >> No line number information available for address 0x55555555464c <main3>^M >> (gdb) FAIL: gdb.dwarf2/dw2-ranges.exp: info line main3 >> ... >> >> The main3 function in the executable comes from dw2-ranges3.o, which is >> generated like this (leaving out -fPIE -pie for clarity): >> ... >> $ gcc -S dw2-ranges3.c >> $ gcc dw2-ranges3.s -o dw2-ranges3.o -gstabs >> ... >> So, main3 is described in stabs format, generated by gas. >> >> The difference between gcc-generated and gas-generated SLINE stabs is that gcc >> generates a sequence SO (source), FUN (function), SLINE (source line) whereas >> gas generates SO, SLINE. >> >> The problem is that the line address relocation handling in process_one_symbol >> assumes an order of SO, FUN, SLINE. >> >> Fix this by also handling SO, SLINE. >> >> This also fixes FAILs in gdb.btrace/instruction_history.exp with >> target board stabs/-fPIE/-pie. >> >> Tested on x86_64-linux with target boards unix, unix/-fPIE/-pie, stabs, and >> stabs/-fPIE/-pie. >> >> OK for trunk? >> Ping^2. Thanks, - Tom >> [gdb/symtab] Handle gas-generated stabs with -fPIE/-pie >> >> gdb/ChangeLog: >> >> 2019-08-16 Tom de Vries <tdevries@suse.de> >> >> PR symtab/12497 >> * dbxread.c (process_one_symbol): Handle relocation of SLINE address >> without preceding FUN/FNAME. >> >> --- >> gdb/dbxread.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/gdb/dbxread.c b/gdb/dbxread.c >> index e339d1f7ec..e0ab4ec19c 100644 >> --- a/gdb/dbxread.c >> +++ b/gdb/dbxread.c >> @@ -2626,6 +2626,9 @@ process_one_symbol (int type, int desc, CORE_ADDR valu, const char *name, >> >> /* Relocate for dynamic loading and for ELF acc >> function-relative symbols. */ >> + if (function_start_offset == 0) >> + function_start_offset >> + = ANOFFSET (section_offsets, SECT_OFF_TEXT (objfile)); >> valu += function_start_offset; >> >> /* GCC 2.95.3 emits the first N_SLINE stab somwehere in the >>
On 06-09-19 17:31, Tom de Vries wrote: > On 29-08-19 17:04, Tom de Vries wrote: >> On 16-08-19 17:57, Tom de Vries wrote: >>> Hi, >>> >>> With gdb.dwarf2/dw2-ranges.exp and target board unix/-fPIE/-pie, we run into: >>> ... >>> info line main3^M >>> No line number information available for address 0x55555555464c <main3>^M >>> (gdb) FAIL: gdb.dwarf2/dw2-ranges.exp: info line main3 >>> ... >>> >>> The main3 function in the executable comes from dw2-ranges3.o, which is >>> generated like this (leaving out -fPIE -pie for clarity): >>> ... >>> $ gcc -S dw2-ranges3.c >>> $ gcc dw2-ranges3.s -o dw2-ranges3.o -gstabs >>> ... >>> So, main3 is described in stabs format, generated by gas. >>> >>> The difference between gcc-generated and gas-generated SLINE stabs is that gcc >>> generates a sequence SO (source), FUN (function), SLINE (source line) whereas >>> gas generates SO, SLINE. >>> >>> The problem is that the line address relocation handling in process_one_symbol >>> assumes an order of SO, FUN, SLINE. >>> >>> Fix this by also handling SO, SLINE. >>> >>> This also fixes FAILs in gdb.btrace/instruction_history.exp with >>> target board stabs/-fPIE/-pie. >>> >>> Tested on x86_64-linux with target boards unix, unix/-fPIE/-pie, stabs, and >>> stabs/-fPIE/-pie. >>> >>> OK for trunk? >>> Ping^3. Thanks, - Tom >>> [gdb/symtab] Handle gas-generated stabs with -fPIE/-pie >>> >>> gdb/ChangeLog: >>> >>> 2019-08-16 Tom de Vries <tdevries@suse.de> >>> >>> PR symtab/12497 >>> * dbxread.c (process_one_symbol): Handle relocation of SLINE address >>> without preceding FUN/FNAME. >>> >>> --- >>> gdb/dbxread.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/gdb/dbxread.c b/gdb/dbxread.c >>> index e339d1f7ec..e0ab4ec19c 100644 >>> --- a/gdb/dbxread.c >>> +++ b/gdb/dbxread.c >>> @@ -2626,6 +2626,9 @@ process_one_symbol (int type, int desc, CORE_ADDR valu, const char *name, >>> >>> /* Relocate for dynamic loading and for ELF acc >>> function-relative symbols. */ >>> + if (function_start_offset == 0) >>> + function_start_offset >>> + = ANOFFSET (section_offsets, SECT_OFF_TEXT (objfile)); >>> valu += function_start_offset; >>> >>> /* GCC 2.95.3 emits the first N_SLINE stab somwehere in the >>>
>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
Tom> The main3 function in the executable comes from dw2-ranges3.o, which is
Tom> generated like this (leaving out -fPIE -pie for clarity):
Tom> ...
Tom> $ gcc -S dw2-ranges3.c
Tom> $ gcc dw2-ranges3.s -o dw2-ranges3.o -gstabs
Tom> ...
Tom> So, main3 is described in stabs format, generated by gas.
Tom> 2019-08-16 Tom de Vries <tdevries@suse.de>
Tom> PR symtab/12497
Tom> * dbxread.c (process_one_symbol): Handle relocation of SLINE address
Tom> without preceding FUN/FNAME.
I don't know enough about stabs to say whether this change is correct or
whether it will cause problems in some other scenario. It modifies
"valu" - which isn't then reset, so perhaps it's used in some other way
later.
Do we need to support PIE + stabs? Can we just declare stabs as mostly
dead and ignore this instead? On the whole that would be my preference,
if it's possible, because in my view this more closely mirrors
reality... my understanding is that, last time anybody checked, stabs
were still used by a few programs in a typical distro (for some unknown
reason), but otherwise they are just totally obsolete.
Tom
[ was: Re: [PATCH][gdb/symtab] Handle gas-generated stabs with -fPIE/-pie ] On 09-10-2019 16:46, Tom Tromey wrote: >>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes: > > Tom> The main3 function in the executable comes from dw2-ranges3.o, which is > Tom> generated like this (leaving out -fPIE -pie for clarity): > Tom> ... > Tom> $ gcc -S dw2-ranges3.c > Tom> $ gcc dw2-ranges3.s -o dw2-ranges3.o -gstabs > Tom> ... > Tom> So, main3 is described in stabs format, generated by gas. > > Tom> 2019-08-16 Tom de Vries <tdevries@suse.de> > > Tom> PR symtab/12497 > Tom> * dbxread.c (process_one_symbol): Handle relocation of SLINE address > Tom> without preceding FUN/FNAME. > > I don't know enough about stabs to say whether this change is correct or > whether it will cause problems in some other scenario. It modifies > "valu" - which isn't then reset, so perhaps it's used in some other way > later. > > Do we need to support PIE + stabs? Can we just declare stabs as mostly > dead and ignore this instead? On the whole that would be my preference, > if it's possible, because in my view this more closely mirrors > reality... my understanding is that, last time anybody checked, stabs > were still used by a few programs in a typical distro (for some unknown > reason), but otherwise they are just totally obsolete. I don't know the answer to that, and I think it's a question broader than suggested by the current subject, so, promoting the question to the subject. Thanks, - Tom
>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes: >> Do we need to support PIE + stabs? Can we just declare stabs as mostly >> dead and ignore this instead? On the whole that would be my preference, >> if it's possible, because in my view this more closely mirrors >> reality... my understanding is that, last time anybody checked, stabs >> were still used by a few programs in a typical distro (for some unknown >> reason), but otherwise they are just totally obsolete. Tom> I don't know the answer to that, and I think it's a question broader Tom> than suggested by the current subject, so, promoting the question to the Tom> subject. No-one has answered yet... I still think the answer is "no" for the reasons outlined above. thanks, Tom
diff --git a/gdb/dbxread.c b/gdb/dbxread.c index e339d1f7ec..e0ab4ec19c 100644 --- a/gdb/dbxread.c +++ b/gdb/dbxread.c @@ -2626,6 +2626,9 @@ process_one_symbol (int type, int desc, CORE_ADDR valu, const char *name, /* Relocate for dynamic loading and for ELF acc function-relative symbols. */ + if (function_start_offset == 0) + function_start_offset + = ANOFFSET (section_offsets, SECT_OFF_TEXT (objfile)); valu += function_start_offset; /* GCC 2.95.3 emits the first N_SLINE stab somwehere in the