[Bug binutils/19849] New: Solaris 11 as generated object incompatible with 2.26 objcopy "no group info for section" during GCC 5.3.0 gccgo build
https://sourceware.org/bugzilla/show_bug.cgi?id=19849 Bug ID: 19849 Summary: Solaris 11 as generated object incompatible with 2.26 objcopy "no group info for section" during GCC 5.3.0 gccgo build Product: binutils Version: 2.26 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: andrew at ishiboo dot com Target Milestone: --- Created attachment 9109 --> https://sourceware.org/bugzilla/attachment.cgi?id=9109&action=edit gccgo + Solaris 11 as generated object sparc-sun-solaris2.11 $ as -V as: Sun Compiler Common 12 SunOS_sparc s11_2sru04_1 09/30/2014 $ objcopy -V | head -1 GNU objcopy (GNU Binutils) 2.26.20160125 During a build of GCC 5.3.0, the build only fails inside gccgo during an objcopy operation. Disabling the Go language lets the build succeed. I raised the issue in the GCC bugtracker and they suggested raising the issue with objcopy here. ... rm -f libgobegin.a ar cru libgobegin.a libgobegin_a-go-main.o ranlib libgobegin.a rm -f libgolibbegin.a ar cru libgolibbegin.a libgolibbegin_a-go-libmain.o ranlib libgolibbegin.a f=`echo errors.lo | sed -e 's/.lo$/.o/'`; objcopy -j .go_export $f errors.gox.tmp && mv -f errors.gox.tmp errors.gox objcopy: errors.o: no group info for section .group%__go_pimt__I5_ErrorFrN6_stringeee__N18_errors.errorString objcopy: errors.o: no group info for section .group%__go_pimt__I5_ErrorFrN6_stringeee__N18_errors.errorString objcopy:errors.o: Bad value make[9]: *** [errors.gox] Error 1 make[9]: *** Waiting for unfinished jobs Attempting to objdump the .o file results in the same: $ objdump -x errors.o | less BFD: errors.o: no group info for section .group%__go_pimt__I5_ErrorFrN6_stringeee__N18_errors.errorString BFD: errors.o: no group info for section .group%__go_td_pN18_errors.errorString BFD: errors.o: no group info for section .group%__go_td_S1_sN6_stringe$gc BFD: errors.o: no group info for section .group%__go_td_FppN18_errors.errorStringerN6_stringee BFD: errors.o: no group info for section .group%__go_td_FppN18_errors.errorStringerN6_stringee$gc BFD: errors.o: no group info for section .group%__go_td_FrN6_stringee BFD: errors.o: no group info for section .group%__go_tdn_string BFD: errors.o: no group info for section .group%__go_td_pN6_string BFD: errors.o: no group info for section .group%__go_td_pN6_string$gc BFD: errors.o: no group info for section .group%__go_tdn_string$gc BFD: errors.o: no group info for section .group%__go_td_z$gc BFD: errors.o: no group info for section .group%go$zerovalue BFD: errors.o: no group info for section .group%__go_td_FrN6_stringee$gc BFD: errors.o: no group info for section .group%__go_td_pN18_errors.errorString$gc Attaching the errors.o objects. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24064] New: bfd/warning.m4 warning detection broken when !defined(__GNUC__)
https://sourceware.org/bugzilla/show_bug.cgi?id=24064 Bug ID: 24064 Summary: bfd/warning.m4 warning detection broken when !defined(__GNUC__) Product: binutils Version: 2.32 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: andrew at ishiboo dot com Target Milestone: --- Created attachment 11511 --> https://sourceware.org/bugzilla/attachment.cgi?id=11511&action=edit Adjust bfd/warning.m4 egrep patterns `bfd/warning.m4` performs `egrep` checks against the preprocessor output of `__GNUC__`: > # Set WARN_WRITE_STRINGS if the compiler supports -Wwrite-strings. > WARN_WRITE_STRINGS="" > AC_EGREP_CPP([^[0-3]$],[__GNUC__],,WARN_WRITE_STRINGS="-Wwrite-strings") This will incorrectly enable `-Wwrite-strings` if a non-GNU compiler is being used and `__GNUC__` is not defined by the preprocessor. The pattern for these checks needs to be adjusted to also treat `__GNUC__` in the output as "unsupported". This breaks when Oracle Studio compiler is used, as `-W` is not a warning switch, and it errors: > $ cc -Wwrite-strings > cc: -W option with unknown program write-strings -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24800] New: ar fails to create / append archives in aixcoff64-rs6000 target
https://sourceware.org/bugzilla/show_bug.cgi?id=24800
Bug ID: 24800
Summary: ar fails to create / append archives in
aixcoff64-rs6000 target
Product: binutils
Version: 2.31
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: andrew at ishiboo dot com
Target Milestone: ---
ar fails to create archives when using the aixcoff64-rs6000 or
aix5coff64-rs6000 targets, but *does* succeed when using the aixcoff-rs6000
target.
$ gnu-ar -V | head -1
GNU ar (GNU Binutils) 2.31.1
Test setup:
$ echo "int foo() { return 0; }" > test.c
$ gcc -c -o test32.o test.c
$ gcc -maix64 -c -o test64.o test.c
Working target:
$ rm -f dummy.a
$ gnu-ar -q --target=aixcoff-rs6000 dummy.a test32.o
gnu-ar: creating dummy.a
$ gnu-ar -t --target=aixcoff-rs6000 dummy.a
test32.o
Broken target, can't create an archive:
$ rm -f dummy.a
$ gnu-ar -q --target=aixcoff64-rs6000 dummy.a test64.o
gnu-ar: creating dummy.a
gnu-ar: dummy.a: invalid operation
... can list/extract an archive created by the OS ar:
$ rm -f dummy.a
$ /bin/ar -X64 q dummy.a test64.o
ar: creating an archive file dummy.a
$ /bin/ar -X64 t dummy.a
test64.o
$ gnu-ar -t --target=aixcoff64-rs6000 dummy.a
test64.o
$ gnu-ar -x --target=aixcoff64-rs6000 dummy.a test64.o
$
... can't append to an archive created by the OS ar:
$ rm -f dummy.a
$ /bin/ar -X64 q dummy.a test64.o
ar: creating an archive file dummy.a
$ /bin/ar -X64 t dummy.a
test64.o
$ cp test64.o foo.o
$ gnu-ar -q --target=aixcoff64-rs6000 dummy.a foo.o
$ gnu-ar -t --target=aixcoff64-rs6000 dummy.a
test64.o
$ /bin/ar -X64 t dummy.a
test64.o
... supported targets:
$ gnu-ar 2>&1 | grep targets
gnu-ar: supported targets: aixcoff-rs6000 aix5coff64-rs6000 aixcoff64-rs6000
elf32-sparc-sol2 elf64-sparc-sol2 elf64-little elf64-big elf32-little elf32-big
elf64-x86-64 elf32-i386 elf32-iamcu elf32-x86-64 pei-i386 pei-x86-64 elf64-l1om
elf64-k1om srec symbolsrec verilog tekhex binary ihex
I don't have many local versions built to narrow the range more, but I do have
2.23.2 and the aixcoff64-rs6000 target works correctly in that version. If I
can narrow the range anymore, I'll provide an update.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24800] ar fails to create / append archives in aixcoff64-rs6000 target
https://sourceware.org/bugzilla/show_bug.cgi?id=24800 --- Comment #2 from Andrew Paprocki --- (In reply to Nick Clifton from comment #1) > > have 2.23.2 and the aixcoff64-rs6000 target works correctly in that version. > > So it was broken in 2.31.1 but it is fixed in 2.32.2, right ? No, I was saying the older version 2.23.2 shows it working correctly, but it is broken by the later version 2.31.1, indicating that it broke somewhere between 23.2 -> 31.1. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/25458] New: --gc-sections removes _environ symbol since version 2.21
https://sourceware.org/bugzilla/show_bug.cgi?id=25458
Bug ID: 25458
Summary: --gc-sections removes _environ symbol since version
2.21
Product: binutils
Version: 2.35 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: andrew at ishiboo dot com
Target Milestone: ---
The following issue is observed in all `ld` versions >= 2.21. Version 2.20 does
not exhibit this behavior.
A simple C file:
#include
extern char **environ;
int main(int argc, char **argv) {
printf("%p\n", environ);
return 0;
}
When compiled, will reference `_environ`:
$ gcc -o environ environ.c && \
readelf -s environ | grep " _environ"
4: 00601040 8 OBJECT WEAK DEFAULT 24
_environ@GLIBC_2.2.5 (2)
$
When compiled passing the linker `--gc-sections`, the `_environ` alias is
dropped, but the `__environ` and `environ` ones remain:
$ gcc -Wl,--gc-sections -o environ environ.c && \
readelf -s environ | grep " _environ"
$
This breaks glibc functionality that looks at `_environ` internally, because it
then points to a different address when the shared object is loaded. This
manifested in glibc not respecting memory sub-system environment variables.
Code x-reference:
https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/arena.c;h=4d0deefe19156a46d7d51a8da5d7b1f8e4e2afdd;hb=6164128f1ca84eea240b66f977054e16b94b3c86#l541
The `gold` linker does not discard the `_environ` symbol when `--gc-sections`
is used:
$ gcc -fuse-ld=gold -Wl,--gc-sections -o environ environ.c && \
readelf -s environ | grep " _environ"
5: 00402040 8 OBJECT GLOBAL DEFAULT 24
_environ@GLIBC_2.2.5 (2)
31: 00402040 8 OBJECT GLOBAL DEFAULT 24 _environ
This was checked against older versions of `ld` and version 2.20 works and
retains the `_environ` symbol. Searching for changes that occurred in the
release of 2.21, it appears this commit for bug 20828 changed the behavior:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=81ff47b3a54633819fac4d973e34f1ff0c65606e
https://www.sourceware.org/ml/binutils/2017-01/msg00263.html
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25458] --gc-sections removes _environ symbol since version 2.21
https://sourceware.org/bugzilla/show_bug.cgi?id=25458 Andrew Paprocki changed: What|Removed |Added CC||ma...@linux-mips.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/6922] New: objdump fails to read debugging stabs from SUNPro C++ compiler
Also noted here:
http://osdir.com/ml/gnu.binutils/2002-08/msg00624.html
If the SUNPro C++ compiler is used with the "-xs -g" (embed debugging symbols in
executable, debugging enabled) options, 'objdump -g' fails to output the
debugging stabs:
$ objdump -g foo.o
foo.o: file format elf32-sparc
Bad stab: uv4;0;32
Last stabs entries before error:
n_type n_desc n_value string
1980 short:t(0,2)=bs2;0;16
1980 int:t(0,3)=bs4;0;32
1980 long:t(0,4)=bs4;0;32
1980 long long:t(0,5)=bs8;0;64
1980 unsigned char:t(0,6)=buc1;0;8
1980 unsigned short:t(0,7)=bu2;0;16
1980 unsigned:t(0,8)=bu4;0;32
1980 unsigned long:t(0,9)=bu4;0;32
1980 unsigned long long:t(0,10)=bu8;0;64
1980 signed char:t(0,11)=bsc1;0;8
1980 wchar_t:t(0,12)=buc4;0;32
1980 void:t(0,13)=bs0;0;0
1980 float:t(0,14)=R1;4
1980 double:t(0,15)=R2;8
1980 long double:t(0,16)=R6;16
1980 ...:t(0,17)=buv4;0;32
--
Summary: objdump fails to read debugging stabs from SUNPro C++
compiler
Product: binutils
Version: 2.18
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: andrew at ishiboo dot com
CC: bug-binutils at gnu dot org
GCC build triplet: sparc-sun-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9
http://sourceware.org/bugzilla/show_bug.cgi?id=6922
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6922] objdump fails to read debugging stabs from SUNPro C++ compiler
--- Additional Comments From andrew at ishiboo dot com 2008-09-29 20:25
---
$ cat /tmp/foo.cc
int main(void) {
return 0;
}
$ CC -xs -g -o /tmp/foo /tmp/foo.cc
$ objdump -g /tmp/foo
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6922
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6922] objdump fails to read debugging stabs from SUNPro C++ compiler
--- Additional Comments From andrew at ishiboo dot com 2008-09-29 20:27 --- Created an attachment (id=2968) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2968&action=view) Solaris binary exhibiting the problem in the description Run 'objdump -g' on this file to reproduce the problem. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6922 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6922] objdump fails to read debugging stabs from SUNPro C++ compiler
--- Additional Comments From andrew at ishiboo dot com 2008-09-29 21:40 --- Created an attachment (id=2970) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2970&action=view) Patch to add "cbv" intrinsic encoding parsing support. This information was gleaned from the following OpenSolaris code: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/tools/ctf/cvt/ctf.c#281 -- http://sourceware.org/bugzilla/show_bug.cgi?id=6922 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6934] New: binutils stabs does not read SUNPro C++ namespace stab
stabs.c is missing support for many SUNPro C++ stabs. This patch will add support for reading the "=Yn0;" stab so that basic C++ objects can be used with objdump. Upon adding this support, I was able to read full C++ objects without adding any of the other missing stabs. -- Summary: binutils stabs does not read SUNPro C++ namespace stab Product: binutils Version: 2.18 Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassigned at sources dot redhat dot com ReportedBy: andrew at ishiboo dot com CC: bug-binutils at gnu dot org GCC build triplet: sparc-sun-solaris2.10 GCC host triplet: sparc-sun-solaris2.10 GCC target triplet: sparc-sun-solaris2.10 http://sourceware.org/bugzilla/show_bug.cgi?id=6934 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6934] binutils stabs does not read SUNPro C++ namespace stab
--- Additional Comments From andrew at ishiboo dot com 2008-10-01 21:37 --- Created an attachment (id=2972) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2972&action=view) Add support for "=Yn0;" stab This patch adds just one of the missing SUNPro Y stab types. I've noted the other missing types to make it clear for any others which hit them. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6934 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6934] binutils stabs does not read SUNPro C++ namespace stab
--- Additional Comments From andrew at ishiboo dot com 2008-10-01 21:38 --- The patch allows objdump -G to read the following stab generated by SUNPro C++: __1n9uX__unnamed_2WQdDEsI794I2IM_:T(0,19)=Yn0; -- http://sourceware.org/bugzilla/show_bug.cgi?id=6934 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gprofng/32825] New: gprofng autoreconf fails with libtoolize AC_CONFIG_MACRO_DIRS error
https://sourceware.org/bugzilla/show_bug.cgi?id=32825 Bug ID: 32825 Summary: gprofng autoreconf fails with libtoolize AC_CONFIG_MACRO_DIRS error Product: binutils Version: 2.44 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: andrew at ishiboo dot com Target Milestone: --- autoreconf has always worked w/ the gprof directory, but when the gprofng directory is added to the command line, it fails with the error below (using the 2.44 release tarball): autoreconf -vif . bfd binutils gas gold gprof gprofng ld libctf libiberty libsframe opcodes ... autoreconf: Entering directory `gprof' libtoolize: putting auxiliary files in '..'. libtoolize: copying file '../ltmain.sh' libtoolize: putting macros in '..'. libtoolize: copying file '../libtool.m4' libtoolize: copying file '../ltoptions.m4' libtoolize: copying file '../ltsugar.m4' libtoolize: copying file '../ltversion.m4' libtoolize: copying file '../lt~obsolete.m4' libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([..])' to configure.ac, libtoolize: and rerunning libtoolize and aclocal. configure.ac:34: installing '../compile' configure.ac:25: installing '../missing' Makefile.am: installing '../depcomp' autoreconf: Leaving directory `gprof' autoreconf: Entering directory `gprofng' autoreconf: running: aclocal --force -I . -I .. autoreconf: configure.ac: adding subdirectory libcollector to autoreconf autoreconf: Entering directory `libcollector' autoreconf: running: aclocal --force -I . -I ../.. libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '../..'. libtoolize: copying file '../../ltmain.sh' libtoolize: error: AC_CONFIG_MACRO_DIRS([../../config]) conflicts with ACLOCAL_AMFLAGS=-I .. autoreconf: libtoolize failed with exit status: 1 -- You are receiving this mail because: You are on the CC list for the bug.
