[PATCH][gdb/symtab] Handle gas-generated stabs with -fPIE/-pie

[PATCH][gdb/symtab] Handle gas-generated stabs with -fPIE/-pie

[Tom de Vries]

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(+)

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

[PING][PATCH][gdb/symtab] Handle gas-generated stabs with -fPIE/-pie

[Tom de Vries]

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
> 

[PING^2][PATCH][gdb/symtab] Handle gas-generated stabs with -fPIE/-pie

[Tom de Vries]

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
>>

[PING^3][PATCH][gdb/symtab] Handle gas-generated stabs with -fPIE/-pie

[Tom de Vries]

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
>>>

Re: [PATCH][gdb/symtab] Handle gas-generated stabs with -fPIE/-pie

[Tom Tromey]

>>>>> "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

[RFC] Do we need to support PIE + stabs?

[Tom de Vries]

[ 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

Re: [RFC] Do we need to support PIE + stabs?

[Tom Tromey]

>>>>> "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