GDB 8.2 fails to load LTO applications

Bug #1813553 reported by Liviu Ionescu
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Arm Embedded Toolchain
New
Undecided
Unassigned

Bug Description

The problem occurs with gcc-arm-none-eabi-8-2018-q4-major and does not occur with gcc-arm-none-eabi-7-2017-q4-major.

It is an assert related to dwarf and occurs while GDB tries to load an .elf that was compiled with -flto.

Retaining the latest version of the compiler but reverting only GDB to the previous version (GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git) fixes the problem, so I expect the new GDB (GNU gdb (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.50.20181213-git) is to blame.

The GDB trace captured by Eclipse is below.

Any suggestions how to proceed? Report this via the GNU bugzilla?

Regards,

Liviu

551,953 &"symbol-file /Users/ilg/Desktop/eclipse-workspace-2018-12/f4b-lto-test/Debug/f4b-lto-test.e\
lf\n"
551,953 ~"Reading symbols from /Users/ilg/Desktop/eclipse-workspace-2018-12/f4b-lto-test/Debug/f4b-l\
to-test.elf...\n"
551,962 30^done
551,962 (gdb)
551,964 &"load /Users/ilg/Desktop/eclipse-workspace-2018-12/f4b-lto-test/Debug/f4b-lto-test.elf\n"
551,964 ~"Loading section .isr_vector, size 0x3bc lma 0x8000000\n"
551,966 31+download,{section=".isr_vector",section-size="956",total-size="934014"}
551,966 31+download,{section=".isr_vector",section-sent="956",section-size="956",total-sent="956",to\
tal-size="934014"}
551,966 ~"Loading section .inits, size 0x28 lma 0x80003bc\n"
551,968 31+download,{section=".inits",section-size="40",total-size="934014"}
551,968 ~"Loading section .text, size 0xcf3 lma 0x80003f0\n"
551,968 31+download,{section=".text",section-size="3315",total-size="934014"}
551,968 ~"Loading section .data, size 0x74 lma 0x80010e4\n"
551,969 31+download,{section=".data",section-size="116",total-size="934014"}
551,969 ~"Start address 0x80002a4, load size 4427\n"
552,406 ~"Transfer rate: 864 KB/sec, 1106 bytes/write.\n"

552,407 ~"/tmp/jenkins-GCC-8-build-toolchain-mac_cluster-128_20181216_1544945247/src/gdb/gdb/dwarf2r\
ead.c:9809: internal-error: void dw2_add_symbol_to_list(struct symbol *, struct pending **): Asserti\
on `(*listhead) == NULL || (SYMBOL_LANGUAGE ((*listhead)->symbol[0]) == SYMBOL_LANGUAGE (symbol))' f\
ailed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit \
this debugging session? "
552,408 ~"(y or n) [answered Y; input not from terminal]\n"
552,408 &"\nThis is a bug, please report it."
552,408 &" For instructions, see:\n<http://www.gnu.org/software/gdb/bugs/>."
552,408 &"\n\n"
552,408 ~"/tmp/jenkins-GCC-8-build-toolchain-mac_cluster-128_20181216_1544945247/src/gdb/gdb/dwarf2r\
ead.c:9809: internal-error: void dw2_add_symbol_to_list(struct symbol *, struct pending **): Asserti\
on `(*listhead) == NULL || (SYMBOL_LANGUAGE ((*listhead)->symbol[0]) == SYMBOL_LANGUAGE (symbol))' f\
ailed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nCreat\
e a core file of GDB? "
552,409 ~"(y or n) [answered Y; input not from terminal]\n"

Tags: gdb ice lto
Revision history for this message
Ramana Radhakrishnan (ramana) wrote :

In this case please file a bug upstream in the gdb bugzilla. Is the same issue occurring on a linux host and could you please put up a testcase (source and binaries) that folks could use to reproduce the issue ?

Revision history for this message
Liviu Ionescu (ilg) wrote :

> Is the same issue occurring on a linux host

I did not try exactly the same tests on a Linux host, but a friend did his own tests and he reported similar problems.

> could you please put up a testcase (source and binaries) that folks could use to reproduce the issue

Yes, I attached an archive with two folders.

The file that threw the assert is f4b-lto-test/Debug/f4b-lto-test.elf.

The entire f4b-lto-test project is a simplification of the initial f4b-lto project, which behaved even worse, GDB crashed with segmentation fault while loading symbols. This case can be easily replicated in a console, by trying to start with 'arm-none-eabi-gdb f4b-lto.elf'

$ /Users/ilg/opt/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-gdb /Users/ilg/Desktop/eclipse-workspace-2018-12/f4b-lto/Debug/f4b-lto.elf
GNU gdb (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.50.20181213-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
/Users/ilg/.gdbinit:1: Error in sourced command file:
No symbol table is loaded. Use the "file" command.
Reading symbols from /Users/ilg/Desktop/eclipse-workspace-2018-12/f4b-lto/Debug/f4b-lto.elf...
Segmentation fault: 11
$

Revision history for this message
Liviu Ionescu (ilg) wrote :
Revision history for this message
Liviu Ionescu (ilg) wrote :

Ramana, do you have any contacts amongst GDB maintainers, to help us with this issue?

Revision history for this message
Liviu Ionescu (ilg) wrote :

One more detail, it looks like the problem affects only C++ projects, since I managed to successfully debug a similar C project.

Revision history for this message
Liviu Ionescu (ilg) wrote :

The problem seems fixed, I ran a new build with the latest GDB commit from 20190129 and now I can debug the projects using LTO.

I have a few more details to fix related to liblto_plugin on Windows, then I plan to make a new toolchain release.

tags: added: ice
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.