[Bug target/103698] [12 regression] Code assigned to __attribute__((section(".data"))) generates invalid dwarf: leb128 operand is an undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698
Matthijs Kooijman changed:
What|Removed |Added
CC||matthijs at stdin dot nl
--- Comment #4 from Matthijs Kooijman ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698 --- Comment #3 from Andrew Pinski --- 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
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
[Bug target/103698] [12 regression] Code assigned to __attribute__((section(".data"))) generates invalid dwarf: leb128 operand is an undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698
--- Comment #2 from Sergei Trofimovich ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Andrew Pinski --- 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.
