[Bug gdb/31669] New: wrong "info symbol" output, symbol shadowing, __dso_handle

[Bug gdb/31669] New: wrong "info symbol" output, symbol shadowing, __dso_handle

[k4lizen at proton dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=31669

            Bug ID: 31669
           Summary: wrong "info symbol" output, symbol shadowing,
                    __dso_handle
           Product: gdb
           Version: 13.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: k4lizen at proton dot me
  Target Milestone: ---

Created attachment 15478
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15478&action=edit
The file I encountered this issue with

gdb version: GNU gdb (Debian 13.2-1) 13.2
OS: Linux kali 6.6.9-amd64

In the attachment is the ELF I encountered the issue with. I initially
submitted an issue downstream: https://github.com/pwndbg/pwndbg/issues/2116.
Due to the way "info symbol" is used in pwndbg, it would be nice if this bug
was patched.

The issue:
Doing `info symbol 0x402367` gives `__dso_handle + 863 [...]` although the
value stored at 0x402367 has nothing to do with __dso_handle. The values at
0x402367 and 0x402a27 are the strings "r" and "./flag.txt" which are passed to
fopen near the start of the main function.

Notable:
+ The __dso_handle symbol seems to be registered even before libc is loaded,
but after libc is loaded doing "p __dso_handle" prints the symbol in libc. Is
the symbol supposed to be there before libc is loaded? It exists before libc in
multiple elfs I tried.

+ Is there a way to make "print" print the value of __dso_handle in
terminal.bin after libc is loaded?

+ I'm not sure if the bug is in "info symbol" and how it checks when a symbol
"ends" or with the handling of __dso_handle in particular.

===============
hacker@kali ~/m/gdbbugsymbols> gdb terminal.bin
GNU gdb (Debian 13.2-1) 13.2
[..copyright snip..]
Reading symbols from terminal.bin...
(No debugging symbols found in terminal.bin)
(gdb) x &__dso_handle
0x402008:       0x00000000
(gdb) break main
Breakpoint 1 at 0x401d9e
(gdb) run
Starting program: /home/hacker/mine/gdbbugsymbols/terminal.bin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, 0x0000000000401d9e in main ()
(gdb) x &__dso_handle
0x7ffff7f9a780 <__dso_handle>:  0xf7f9a780
(gdb) info symbol 0x402367
__dso_handle + 863 in section .rodata of
/home/hacker/mine/gdbbugsymbols/terminal.bin
(gdb) info symbol 0x402008
__dso_handle in section .rodata of /home/hacker/mine/gdbbugsymbols/terminal.bin
(gdb) info symbol 0x7ffff7f9a780
__dso_handle in section .data.rel.ro of /lib/x86_64-linux-gnu/libc.so.6
(gdb)
===============

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31669] wrong "info symbol" output, symbol shadowing, __dso_handle

[k4lizen at proton dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=31669

--- Comment #1 from k4lizen <k4lizen at proton dot me> ---
By the way I don't know anything about what __dso_handle actually is apart from
a stackoverflow post I read so I'm also lost as to what is happening in that
regard.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31669] wrong "info symbol" output, symbol shadowing, __dso_handle

[dominik.b.czarnota+bugzilla at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31669

Disconnect3d <dominik.b.czarnota+bugzilla at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dominik.b.czarnota+bugzilla
                   |                            |@gmail.com

--- Comment #2 from Disconnect3d <dominik.b.czarnota+bugzilla at gmail dot com> ---
Btw all this can be checked even without running the binary:

```
pwndbg> info address __dso_handle
Symbol "__dso_handle" is at 0x402008 in a file compiled without debugging.
pwndbg> info symbol 0x402008
__dso_handle in section .rodata
pwndbg> info symbol 0x402009
__dso_handle + 1 in section .rodata
pwndbg> info symbol 0x402100
__dso_handle + 248 in section .rodata
```

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31669] wrong "info symbol" output, symbol shadowing, __dso_handle

[dominik.b.czarnota+bugzilla at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31669

--- Comment #3 from Disconnect3d <dominik.b.czarnota+bugzilla at gmail dot com> ---
Also:

```
pwndbg> info symbol 0x402008+2748
__dso_handle + 2748 in section .rodata
pwndbg> info symbol 0x402008+2749
No symbol matches 0x402008+2749.
pwndbg> info symbol 0x402008+2750
No symbol matches 0x402008+2750.
pwndbg> info symbol 0x402008+2751
No symbol matches 0x402008+2751.
pwndbg> info symbol 0x402008+2752
__GNU_EH_FRAME_HDR in section .eh_frame_hdr
```

It seems that GDB creates symbols for each address past a given symbol address
until 4 bytes before another symbol?

It would be nice to be able to:
1) disable this behavior
2) have a way to query for symbols around a given address, e.g. 0x402008+2751
should show us the symbols/addresses of `__dso_handle` and `__GNU_EH_FRAME_HDR`

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31669] wrong "info symbol" output, symbol shadowing, __dso_handle

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31669

--- Comment #4 from Andreas Schwab <schwab@linux-m68k.org> ---
Since __dso_handle does not have a size and no other hint is available, gdb can
only assume that it extends until the next symbol.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31669] wrong "info symbol" output, symbol shadowing, __dso_handle

[dominik.b.czarnota+bugzilla at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31669

--- Comment #5 from Disconnect3d <dominik.b.czarnota+bugzilla at gmail dot com> ---
(In reply to Andreas Schwab from comment #4)
> Since __dso_handle does not have a size and no other hint is available, gdb
> can only assume that it extends until the next symbol.

How does this logic really works? Is this that some kind of map entry is
created for each memory address in such a case?

Is there any way to disable this behavior or tell GDB to assume a size for
unknown sizes to be sizeof(pointer) or something like this?

Eventually, I think we want to have Python API for the two use cases I noted
earlier, so that we can "get symbol for given address" and "find symbols around
addresses".

For now I guess we can workaround this issue in Pwndbg by ignoring returned
symbols with "+" but this may be buggy...

I bet that if there is a symbol with known size, it can also appear/resolve in
GDB with symbol+offset as it is done here, heh.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31669] wrong "info symbol" output, symbol shadowing, __dso_handle

[k4lizen at proton dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=31669

--- Comment #6 from k4lizen <k4lizen at proton dot me> ---
> Since __dso_handle does not have a size and no other hint is available, gdb can only assume that it extends until the next symbol.

It would probably make sense to say in the output of `info symbol` that gdb is
guessing it because there is no symbol size information (how commonly is this
the case?).

It would allow both users to not be confused, and pwndbg could check if the
output of the command contains the message and proceed accordingly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31669] wrong "info symbol" output, symbol shadowing, __dso_handle

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31669

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.