[Bug target/103698] New: [12 regression] Code assigned to __attribute__((section(".data"))) generates invalid dwarf: leb128 operand is an undefined symbol

[Bug target/103698] New: [12 regression] Code assigned to __attribute__((section(".data"))) generates invalid dwarf: leb128 operand is an undefined symbol

[slyfox at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698

            Bug ID: 103698
           Summary: [12 regression] Code assigned to
                    __attribute__((section(".data"))) generates invalid
                    dwarf: leb128 operand is an undefined symbol
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---
            Target: arm-none-eabi

Created attachment 51990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51990&action=edit
bug.c.orig

One-liner extracted from axoloti-1.0.12:

  $ cat bug.c

    __attribute__((section(".data"))) int flash_Erase_sector1(int sector) {}

gcc-10/binutils-2.35 used to somewhat work. gcc-12/binutils-2.37 gets confused
with dwarf data:

$ arm-none-eabi-gcc-10.3.0 -mcpu=cortex-m4 -O2 -ggdb -c bug.c -o bug.o
/tmp/ccMDYjLi.s: Assembler messages:
/tmp/ccMDYjLi.s:15: Warning: ignoring changed section attributes for .data

$ arm-none-eabi-gcc-12.0.0 -mcpu=cortex-m4 -O2 -ggdb -c bug.c -o bug.o
/tmp/ccBo2IfJ.s: Assembler messages:
/tmp/ccBo2IfJ.s:18: Warning: ignoring changed section attributes for .data
/tmp/ccBo2IfJ.s:29: Warning: dwarf line number information for .data ignored
/tmp/ccBo2IfJ.s:34: Warning: dwarf line number information for .data ignored
/tmp/ccBo2IfJ.s:36: Warning: dwarf line number information for .data ignored
/tmp/ccBo2IfJ.s:174: Error: leb128 operand is an undefined symbol: .LVU2
/tmp/ccBo2IfJ.s:175: Error: leb128 operand is an undefined symbol: .LVU2

Also attached bug.c.orig before reduction to get the idea what was original
code's intent.

$ LANG=C ./12/arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/nix/store/396wib4x58qxz0i91ggwhwjx1w63rrh4-arm-none-eabi-stage-final-gcc-debug-12.0.0/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/nix/store/396wib4x58qxz0i91ggwhwjx1w63rrh4-arm-none-eabi-stage-final-gcc-debug-12.0.0/libexec/gcc/arm-none-eabi/12.0.0/lto-wrapper
Target: arm-none-eabi
Configured with:
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211212 (experimental) (GCC)

Is it reasonable to expect it to work? Or `.data` is too speacial to expect
code there for dwarf?

[Bug target/103698] [12 regression] Code assigned to __attribute__((section(".data"))) generates invalid dwarf: leb128 operand is an undefined symbol

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |MOVED

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Not a GCC bug. GCC is producing the correct output as requested:

        .section        .data,"ax",%progbits
        .align  1
        .p2align 2,,3
        .global flash_Erase_sector1
        .syntax unified
        .thumb
        .thumb_func
        .type   flash_Erase_sector1, %function
flash_Erase_sector1:
.LVL0:
.LFB0:
        .loc 1 1 75 view -0
        .cfi_startproc
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        .loc 1 1 76 view .LVU1
.LVL1:
        .loc 1 1 76 is_stmt 0 view .LVU2
        bx      lr

This might not even be a binutils bug either but GCC is not doing anything
special with respect to what the user requested.

[Bug target/103698] [12 regression] Code assigned to __attribute__((section(".data"))) generates invalid dwarf: leb128 operand is an undefined symbol

[slyfox at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698

--- Comment #2 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
Aha, sounds good. Let's consider it's an user error to mix -g* options with
`__attribute__((section(".data")))` applied to `.code` objects.

[Bug target/103698] [12 regression] Code assigned to __attribute__((section(".data"))) generates invalid dwarf: leb128 operand is an undefined symbol

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The change for binutils came from 
https://sourceware.org/bugzilla/show_bug.cgi?id=26850

[Bug target/103698] [12 regression] Code assigned to __attribute__((section(".data"))) generates invalid dwarf: leb128 operand is an undefined symbol

[matthijs at stdin dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698

Matthijs Kooijman <matthijs at stdin dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matthijs at stdin dot nl

--- Comment #4 from Matthijs Kooijman <matthijs at stdin dot nl> ---
I also ran into this problem, with an STM32 codebase that uses libopencm3 (for
peripheral code and the linker script) and uses section(".data") to put a bit
of code in RAM (to prevent flash reads while programming flash).

To fix this problem in my code, I switched from section(".data") to
section(".ramtext"), which is second section that is also put into RAM and
seems intended especially for this purpose. This works with the libopencm3
linker script, which defines this section, YMMV with other linker scripts. E.g.
from
https://github.com/libopencm3/libopencm3/blob/189017b25cebfc609a6c1a5a02047691ef845b1b/ld/linker.ld.S#L136:

        .data : {
                _data = .;
                *(.data*)       /* Read-write initialized data */
                *(.ramtext*)    /* "text" functions to run in ram */
                . = ALIGN(4);
                _edata = .;
        } >ram AT >rom


From looking at the linker script, it seems that .data and .ramtext are treated
pretty much in the same way, so I suspect that there is something else (maybe
some builtin rules in gcc/ld/as) that make the data section special in a way
that it causes this problem to be triggered.

Hopefully this is helpful for anyone else running into this same problem.

[Bug target/103698] [12 regression] Code assigned to __attribute__((section(".data"))) generates invalid dwarf: leb128 operand is an undefined symbol

[Manuel Köppen]

Hi!

I came across this problem as well.
I use the __attribute__((section(".data"))) as a kind of hack to get a function in the RAM using the standard linker file and startup provided for ST microcontrollers.
Not being able to make a debug build is inaccepable! With older GCC/binutils versions this problem didn't exist.
However, I found a workaround, I now use __attribute__((section(".datax"))).
In the Linker script they include *(.data*) so this  works and it does not generate the errors.
Just wanted to share this in case anyone else is stuck at this.

Best regards,
Manuel Köppen