[Bug gdb/31851] New: GDB ignores absolute function symbols

[Bug gdb/31851] New: GDB ignores absolute function symbols

[marian.buschsieweke at posteo dot net]

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

            Bug ID: 31851
           Summary: GDB ignores absolute function symbols
           Product: gdb
           Version: 14.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: marian.buschsieweke at posteo dot net
  Target Milestone: ---

Hi,

for xtensa-esp32-elf targets some functions end up being absolute symbols.

I created a simple proof of concept that does not require exotic targets (e.g.
I used this on x86_64 / Linux):

main.c:

    extern void func(void);

    int main(void)
    {
        func();
        return 0;
    }

func.c:

    #include <stdio.h>

    void func_impl(void)
    {
        puts("Hello from func");
    }

And I used a custom linker script that is based on the default linker script,
but I added the following line:

    PROVIDE(func = ABSOLUTE(func_impl));

With nm I can confirm that func_impl is a regular function symbol (section
.text) and func is an absolute symbol (section *ABS*) at the same address. When
I try to create a break point I get

    Function "func" not defined.

When I change the linker script to use

    PROVIDE(func = func_impl);

I get a regular symbol for func (section .text) and setting the break point
just works:

    (gdb) break func
    Breakpoint 1 at 0x1199: file func.c, line 5.

To my understanding this is a bug, as GDB should not ignore absolute function
symbols.

(Context: There is no special handling of functions that end up as absolute
symbols in either the C code or the linker script, so there is no obvious
reason why those functions do end up being absolute. My wild guess is that
those functions are being called from functions that get placed in flash as
well as from functions that are placed in instruction RAM. I would happily
apply any change that would prevent functions from becoming absolute symbols,
if someone knows what could cause this. I do however believe that there is a
valid use case for function symbols being explicitly absolute symbols: E.g. on
the RP2040 MCU there are functions in Mask ROM. So even if I could fix this on
my side by not having functions as absolute symbols, I do think that GDB should
be prepared to handle functions that are absolute symbols.)

Kind regards,
Marian

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

[Bug gdb/31851] GDB ignores absolute function symbols

[marian.buschsieweke at posteo dot net]

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

--- Comment #1 from Marian Buschsieweke <marian.buschsieweke at posteo dot net> ---
Created attachment 15567
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15567&action=edit
main.c

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

[Bug gdb/31851] GDB ignores absolute function symbols

[marian.buschsieweke at posteo dot net]

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

--- Comment #2 from Marian Buschsieweke <marian.buschsieweke at posteo dot net> ---
Created attachment 15568
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15568&action=edit
func.c

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

[Bug gdb/31851] GDB ignores absolute function symbols

[marian.buschsieweke at posteo dot net]

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

--- Comment #3 from Marian Buschsieweke <marian.buschsieweke at posteo dot net> ---
Created attachment 15580
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15580&action=edit
look up the symbol type for absolute symbols

This patch adapts elf_symtab_read() to figure out correctly
which symbol type an absolute symbol is. Since bfd doesn't
freely offer this info, the section the symbol belongs to
is looked up by the symbol address and the type is deduced
from the section.

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

[Bug gdb/31851] GDB ignores absolute function symbols

[marian.buschsieweke at posteo dot net]

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

--- Comment #4 from Marian Buschsieweke <marian.buschsieweke at posteo dot net> ---
Note: I extended the test application a bit:


main.c:

    #include <stdio.h>

    extern void func(void);
    extern int data;
    extern int bss;

    int main(void)
    {
        volatile int *p;
        func();
        printf("data = %d, bss = %d\n", data, bss);
        p = &data;
        *p = 1;
        p = &bss;
        *p = 2;
        printf("data = %d, bss = %d\n", data, bss);
        return 0;
    }


func.c:

    #include <stdio.h>

    void func_impl(void)
    {
        puts("Hello from func");
    }

data.c:

    int data_impl = 42;
    int bss_impl = 0;

additions to the linker script:

    PROVIDE(func = ABSOLUTE(func_impl));
    /* ... */
    PROVIDE(data = ABSOLUTE(data_impl));
    /* ... */
    PROVIDE(bss = ABSOLUTE(bss_impl));

With the above patch applied, the symbol "func" was correctly identified as a
function, "bss" as .bss, and "data" as .data. I could successfully attach a
break point to "func" and watch points to "data" and "bss", and they triggered
as expected.

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

[Bug gdb/31851] GDB ignores absolute function symbols

[marian.buschsieweke at posteo dot net]

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

--- Comment #5 from Marian Buschsieweke <marian.buschsieweke at posteo dot net> ---
This is only anecdotally relevant to the bug, but may be of interest to some
reader anyway. I figured out why the functions became absolute symbols in the
first place.

Before, I claimed:

> There is no special handling of functions that end up as absolute symbols in either the C code or the linker script.

That turns out to be incorrect, in fact, the linker script explicitly placed
functions at absolute addresses. I overlooked this because this was not part of
the linker script of the application I looked at, but done by an external
linker script [1] of the vendor SDK I wasn't aware that it was included.

I guess for providing an ABI to a pre-compiled binary blob that needs to be
loaded at a given address, the use of absolute addresses does make sense :'(

[1]:
https://github.com/espressif/esp-idf/blob/24c20d188e24c815e28351cddb838c01e7dfb241/components/esp_rom/esp32/ld/esp32.rom.newlib-funcs.ld

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

[Bug gdb/31851] GDB ignores absolute function symbols

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
FWIW gdb does try to respect absolute symbols, but since they
are relatively uncommon, probably the support has regressed
somewhat.

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