[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug binutils/25676] New: binutils can't handle the split/linked nature
From: |
cialdi at gmail dot com |
Subject: |
[Bug binutils/25676] New: binutils can't handle the split/linked nature of the debug-records for variables whose (separate) extern-decl and definition are found in the same compilation unit |
Date: |
Sat, 14 Mar 2020 14:57:19 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=25676
Bug ID: 25676
Summary: binutils can't handle the split/linked nature of the
debug-records for variables whose (separate)
extern-decl and definition are found in the same
compilation unit
Product: binutils
Version: 2.33
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: cialdi at gmail dot com
Target Milestone: ---
let's take the following source file where g_my_externd_global is both declared
as extern and defined:
extern int g_my_externd_global;
int g_my_externd_global;
int g_my_private_global;
int main(void)
{
g_my_externd_global=1;
g_my_private_global=1;
return 0;
}
what I expect is that the command 'nm -s -l' will find the filename of each
symbol and under all circumstances.
if I compile with:
gcc -g3 -gdwarf-4 -nostdlib -ffunction-sections -fdata-sections -O1 -fno-common
-c main.c -o example-O1.o
and try to get info using nm I get:
nm -s -l example-O1.o
0000000000000000 B g_my_externd_global
0000000000000000 B g_my_private_global
/home/max/Dropbox/4202/prog/test-dwarf/main.c:3
0000000000000000 T main /home/max/Dropbox/4202/prog/test-dwarf/main.c:4
0000000000000000 n wm4.0.446323227e5a4f4144b12e5d1860fd5e
0000000000000000 n wm4.stdcpredef.h.19.8dc41bed5d9037ff9622e015fb5f0ce3
Only one variable (g_my_private_global) has the file name and line.
change compile from -O1 to -O0:
$ gcc -g3 -gdwarf-4 -nostdlib -ffunction-sections -fdata-sections -O0
-fno-common -c main.c -o example-O0.o
$ nm -s -l example-O0.o
0000000000000000 B g_my_externd_global
/home/max/Dropbox/4202/prog/test-dwarf/main.c:1
0000000000000000 B g_my_private_global
/home/max/Dropbox/4202/prog/test-dwarf/main.c:3
0000000000000000 T main /home/max/Dropbox/4202/prog/test-dwarf/main.c:4
0000000000000000 n wm4.0.1c9e441054e7296bffbe77203657809a
0000000000000000 n wm4.stdcpredef.h.19.8dc41bed5d9037ff9622e015fb5f0ce3
$ gcc -g3 -gdwarf-4 -nostdlib -ffunction-sections -fdata-sections -O0
-fno-common example-O0.o -o example-O0.elf
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to
0000000000001000
$ nm -s -l example-O0.elf
0000000000004000 B __bss_start
0000000000003f20 d _DYNAMIC
0000000000004000 B _edata
0000000000004008 B _end
0000000000004000 B g_my_externd_global
0000000000004004 B g_my_private_global
/home/max/Dropbox/4202/prog/test-dwarf/main.c:3
0000000000002000 r __GNU_EH_FRAME_HDR
0000000000001000 T main /home/max/Dropbox/4202/prog/test-dwarf/main.c:4
U _start
In this case (-0O) nm can successfully retrieve filename and line for both
variables, but once linked g_my_externd_global is again without information
change compile from -fno-common to -fcommon (using -O0)
$ gcc -g3 -gdwarf-4 -nostdlib -ffunction-sections -fdata-sections -O0 -fcommon
-c main.c -o example-O0-fcommon.o
$ nm -s -l example-O0-fcommon.o
0000000000000004 C g_my_externd_global
0000000000000004 C g_my_private_global
0000000000000000 T main /home/max/Dropbox/4202/prog/test-dwarf/main.c:4
0000000000000000 n wm4.0.1c9e441054e7296bffbe77203657809a
0000000000000000 n wm4.stdcpredef.h.19.8dc41bed5d9037ff9622e015fb5f0ce3
In this case nm cannot retrieve the information for any of the variables.
tested with various versions of the tools:
$ gcc --version
gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ nm --version
GNU nm (GNU Binutils for Ubuntu) 2.33
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
-------------------
$ gcc --version
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ nm --version
GNU nm (GNU Binutils for Ubuntu) 2.30
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
-------------------
$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1
20191025 (release) [ARM/arm-9-branch revision 277599]
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ arm-none-eabi-nm --version
GNU nm (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 2.33.1.20191025
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
-------------------
$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2019-q3-update)
8.3.1 20190703 (release) [gcc-8-branch revision 273027]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ arm-none-eabi-nm --version
GNU nm (GNU Tools for Arm Embedded Processors 8-2019-q3-update) 2.32.0.20190703
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug binutils/25676] New: binutils can't handle the split/linked nature of the debug-records for variables whose (separate) extern-decl and definition are found in the same compilation unit,
cialdi at gmail dot com <=
- [Bug binutils/25676] binutils can't handle the split/linked nature of the debug-records for variables whose (separate) extern-decl and definition are found in the same compilation unit, nickc at redhat dot com, 2020/03/18
- [Bug binutils/25676] binutils can't handle the split/linked nature of the debug-records for variables whose (separate) extern-decl and definition are found in the same compilation unit, cvs-commit at gcc dot gnu.org, 2020/03/19
- [Bug binutils/25676] binutils can't handle the split/linked nature of the debug-records for variables whose (separate) extern-decl and definition are found in the same compilation unit, nickc at redhat dot com, 2020/03/20
- [Bug binutils/25676] binutils can't handle the split/linked nature of the debug-records for variables whose (separate) extern-decl and definition are found in the same compilation unit, cialdi at gmail dot com, 2020/03/21
- [Bug binutils/25676] binutils can't handle the split/linked nature of the debug-records for variables whose (separate) extern-decl and definition are found in the same compilation unit, cialdi at gmail dot com, 2020/03/21
- [Bug binutils/25676] binutils can't handle the split/linked nature of the debug-records for variables whose (separate) extern-decl and definition are found in the same compilation unit, nickc at redhat dot com, 2020/03/23