Change in relocation of debug info

Change in relocation of debug info

[Rodney M. Bates]

I am maintaining a debugger, derived from gdb-6.4, with
additions for Modula-3.  A recent change in the way gcc
and gdb handle addresses of souce code line numbers in
stabs notation has broken breakpoint insertion.  I need
help understanding what has happened.

This could be a gcc problem, but I am starting here, because
modern gdb appears to at least partly overcome what has
changed in gcc, suggesting at least a coordinated change.

In a reduced example, I have an object file SetElem_m.o,
with the following:

   $objdump -g SetElem_m.o:
     ...
     /* file ../src/SetElem.m3 line 11 addr 0x11 */
     ...

When I link using gcc 5.4:

   $gcc --version:
   gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609,

giving executable named prog I see:

   $objdump -g prog
   ...
   /* file ../src/SetElem.m3 line 11 addr 0x4008ee */
   ...

I can set a breakpoint at SetElem.m3:11, and all works as
expected using either m3gdb or gdb:

   $m3gdb prog
   GNU gdb plus Modula-3 6.4
   ...
   (m3gdb) break SetElem.m3:11
   Breakpoint 1 at 0x4008ee: file ../src/SetElem.m3, line 11.
   (m3gdb) run
   Breakpoint 1, P (...) at ../src/SetElem.m3:11
   11	      RETURN SetTyp { Elem }
   (m3gdb) info reg rip
   rip            0x4008ee	0x4008ee <P+17>

But when linking with gcc 9.3:

   $gcc --version:
   gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

I see:

   $objdump -g prog
   ...
   /* file ../src/SetElem.m3 line 11 addr 0x9b1 */
   ...

neither unrelocated from the .o file nor where line 11
ends up (I think).  m3gdb tries to insert the breakpoint
at this address, failing, I presume because it is
not a writable address:

   $m3gdb prog
   GNU gdb plus Modula-3 6.4
   ...
   (m3gdb) break SetElem.m3:11
   Breakpoint 1 at 0x9b1: file ../src/SetElem.m3, line 11.
   (m3gdb) run
   Starting program: /home/rodney/proj/m3/exp/setelem/AMD64_LINUX-ig-m3cc/prog
   Warning:
   Cannot insert breakpoint 1.
   Error accessing memory address 0x9b1: Input/output error.

In constast, modern gdb inserts the breakpoint and stops,
showing the correct source line number, although not all is
right here either:

   $ gdb prog
   GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
   ...
   (gdb) break SetElem.m3:11
   Breakpoint 1 at 0x9b1: file ../src/SetElem.m3, line 11.
   (gdb) run
   Starting program: /home/rodney/proj/m3/exp/setelem/AMD64_LINUX-ig-m3cc/prog
   ...
   Breakpoint 1, SetElem__P (M3_AuNps8_Elem=<error reading variable>,
     M3_A6gO1v__result=<error reading variable>) at ../src/SetElem.m3:11
   11	      RETURN SetTyp { Elem }
   (gdb) info reg rip
   rip            <error reading variable> <error reading variable>

So I can't tell where the actual code was relocated to.  But it runs
to completion normally, by itself or under either debugger without
breakpoints.

Any help would be appreciated.

-- 
Rodney Bates
rodney.m.bates@acm.org

Re: Change in relocation of debug info

[Simon Marchi]

> When I link using gcc 5.4:
> 
>   $gcc --version:
>   gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609,
> 
> giving executable named prog I see:
> 
>   $objdump -g prog
>   ...
>   /* file ../src/SetElem.m3 line 11 addr 0x4008ee */
>   ...

> But when linking with gcc 9.3:
> 
>   $gcc --version:
>   gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
> 
> I see:
> 
>   $objdump -g prog
>   ...
>   /* file ../src/SetElem.m3 line 11 addr 0x9b1 */

It just sounds like your gcc 9.3.0 is producing position-indenpendent
executables by default, whereas your gcc 5.4.0 did not.  In the recent
years, this has become the norm.

The executable produced by your gcc 5.4.0 is made to always be loaded at
the same address, so the code at virtual address 0x4008ee in the
executable will always end up at address 0x4008ee in the virtual address
space of the process.

With the executable produced by your gcc 9.3.0, the OS / dynamic linker
will choose a different random base address for the executable
every time it's loaded (except when address randomization is disabled,
which GDB tries to do by default, then it will always be the same random
address).  So the virtual address 0x9b1 in the executable will end up at
<load address> + 0x9b1 in the virtual address space of the process.  GDB
has to account for that: detect the load address of the executable,
adjust the addresses of the symbols.

This works for DWARF but doesn't seem to work for stabs for some reason
(based on what you have shown, I didn't try it myself).  I don't know
how difficult it would be to make it work for stabs, but it's unlikely
that anybody working on GDB will do it, given that stabs is pretty much
a dead format.  You can try if you want though.

An alternative is to instruct your gcc 9.3.0 to produce good old
position-dependent executables, as your gcc 5.4.0 does.  This is done
using -fno-pie at link time, IIRC.

Simon

Re: Change in relocation of debug info

[Rodney M. Bates]

On 5/31/21 10:08 AM, Simon Marchi via Gdb wrote:
>> When I link using gcc 5.4:
>>
>>    $gcc --version:
>>    gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609,
>>
>> giving executable named prog I see:
>>
>>    $objdump -g prog
>>    ...
>>    /* file ../src/SetElem.m3 line 11 addr 0x4008ee */
>>    ...
> 
>> But when linking with gcc 9.3:
>>
>>    $gcc --version:
>>    gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
>>
>> I see:
>>
>>    $objdump -g prog
>>    ...
>>    /* file ../src/SetElem.m3 line 11 addr 0x9b1 */
> 
> It just sounds like your gcc 9.3.0 is producing position-indenpendent
> executables by default, whereas your gcc 5.4.0 did not.  In the recent
> years, this has become the norm.
> 
> The executable produced by your gcc 5.4.0 is made to always be loaded at
> the same address, so the code at virtual address 0x4008ee in the
> executable will always end up at address 0x4008ee in the virtual address
> space of the process.
> 
> With the executable produced by your gcc 9.3.0, the OS / dynamic linker
> will choose a different random base address for the executable
> every time it's loaded (except when address randomization is disabled,
> which GDB tries to do by default, then it will always be the same random
> address).  So the virtual address 0x9b1 in the executable will end up at
> <load address> + 0x9b1 in the virtual address space of the process.  GDB
> has to account for that: detect the load address of the executable,
> adjust the addresses of the symbols.
> 
> This works for DWARF but doesn't seem to work for stabs for some reason
> (based on what you have shown, I didn't try it myself).  I don't know
> how difficult it would be to make it work for stabs, but it's unlikely
> that anybody working on GDB will do it, given that stabs is pretty much
> a dead format.  You can try if you want though.
> 
> An alternative is to instruct your gcc 9.3.0 to produce good old
> position-dependent executables, as your gcc 5.4.0 does.  This is done
> using -fno-pie at link time, IIRC.
> 
> Simon
> 

Thanks.  Using -f=no-pie has gotten me going for now.  My build process
has been supplying -fPIC for ages, to the older gcc, so I don't fully
understand why it wasn't happening all along, but this works for now.

-- 
Rodney Bates
rodney.m.bates@acm.org

Re: Change in relocation of debug info

[Simon Marchi]

On 2021-06-03 2:54 p.m., Rodney M. Bates wrote:
> 
> Thanks.  Using -f=no-pie has gotten me going for now.  My build process
> has been supplying -fPIC for ages, to the older gcc, so I don't fully
> understand why it wasn't happening all along, but this works for now.

-fPIC is used at the compile step to produce code in the .o files that
_can_ be linked in a position-independent executable (or shared
library).  But whether the output executable is position dependent or
not ultimately depends on the link step, whether -pie or -no-pie is
passed.  And if neither are passed, it depends on the default setting of
the linker.  That default setting was "no pie", but has changed to "pie"
pretty much everywhere in the last few years.

Simon

Re: Change in relocation of debug info

[Rodney M. Bates]

On 6/3/21 2:02 PM, Simon Marchi via Gdb wrote:
> On 2021-06-03 2:54 p.m., Rodney M. Bates wrote:
>>
>> Thanks.  Using -f=no-pie has gotten me going for now.  My build process
>> has been supplying -fPIC for ages, to the older gcc, so I don't fully
>> understand why it wasn't happening all along, but this works for now.
> 
> -fPIC is used at the compile step to produce code in the .o files that
> _can_ be linked in a position-independent executable (or shared
> library).  But whether the output executable is position dependent or
> not ultimately depends on the link step, whether -pie or -no-pie is
> passed.  And if neither are passed, it depends on the default setting of
> the linker.  That default setting was "no pie", but has changed to "pie"
> pretty much everywhere in the last few years.

Thanks.  Now it makes sense.

> 
> Simon
> 

-- 
Rodney Bates
rodney.m.bates@acm.org