Re: [PATCH] Fix GDB internal error by using text (instead of data) section offset

[Kevin Buettner via Gdb-patches <gdb-patches@sourceware.org>]

On Wed, 26 Jan 2022 11:03:33 -0700
Tom Tromey <tom@tromey.com> wrote:

> Kevin>     #3  0x000000000097c630 in stap_probe::get_relocated_address (this=0xa1a17a0,
> Kevin> 	objfile=0x4fa48f0)
> Kevin> 	at gdb/stap-probe.c:1341  
> 
> One oddity here is that get_relocated_address calls this->get_address(),
> which returns m_address, which is documented as:
> 
>   /* The address where the probe is inserted, relative to
>      SECT_OFF_TEXT.  */
>   CORE_ADDR m_address;
> 
> So using SECT_OFF_DATA here seems wrong in the first place.

Agreed.  (And, thanks for finding that.)

> Kevin> The obvious solution is to use some other section offset instead - as
> Kevin> I recall, on Linux, the section offsets (for those sections which
> Kevin> exist) will all be the same.  
> 
> Is this a Linux thing or an ELF thing?  I don't know.

Some ABIs specify that the difference between two addresses in
memory must be the same difference between those same addresses
specified by the executable.  The System V ABI, which most (though
not all) Linux systems use, is one such ABI.

Take a look at the first paragraph in the section titled "Base
Address" in:

    http://www.sco.com/developers/gabi/2012-12-31/ch5.pheader.html

The key part from that paragraph (for this discussion) is this:

    Because position-independent code on those platforms uses relative
    addressing between segments, the difference between virtual
    addresses in memory must match the difference between virtual
    addresses in the file.  The differences between the virtual
    address of any segment in memory and the corresponding virtual
    address in the file is thus a single constant value for any one
    executable or shared object in a given process. 

One ABI which does not have this property is the FDPIC ABI:

    ftp://ftp.redhat.com/pub/redhat/gnupro/FRV/FDPIC-ABI.txt

The FDPIC ABI was first created for the Fujitsu FR-V processor, but a
search shows that variations have been used by some ARM and SH
Linux implementations.  It's useful for processors which lack an
MMU.  In such a system, all processes share the same address space;
read-only sections such as .text can be shared among processes, but
processes will each have their own copy/version of writeable sections
such as .data.  That being the case, the difference between addresses
in .text and .data will be different for each process and will also
almost certainly be different from the addresses specified by the
executable.

> Kevin> So, what happens if there's no .text section?  
> 
> Not probe-related but this is already a way to crash gdb:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=19342
> https://sourceware.org/bugzilla/show_bug.cgi?id=25678
> 
> ... which is why I was curious about the ELF thing.  Like perhaps this
> could all be made more robust somehow.

I've looked at those bugs and skimmed Simon's RFC patches for dealing
with the lack of a .text section in GDB.  In the second patch, he
introduces a function, find_bfd_section_for_address().  I think this
is the right thing to do.  I have some quibbles with some other things
which are done in that series, but I'll try to raise those if/when
Simon resurrects that series.

> Your patch seems fine to me, though I don't have any idea if the dtrace
> part is correct.

Thanks for looking it over!  I'll push it after making some revisions
to the commit log.  (E.g. I'll remove the part about it being a
Linux thing and instead say that it's ABI dependent.  I'll also add
some additional info mentioning existing bugs to the part about
the .text section.)