[Bug binutils/13548] New: C++ Filt Overflow
http://sourceware.org/bugzilla/show_bug.cgi?id=13548 Bug #: 13548 Summary: C++ Filt Overflow Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassig...@sourceware.org ReportedBy: rafaelsi...@rfdslabs.com.br Classification: Unclassified rfdss-MacBook-Pro:~ uluwatu$ c++filt -v GNU c++filt 070207 20070207 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. rfdss-MacBook-Pro:~ uluwatu$ gdb /usr/bin/c++filt GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov 3 21:59:02 UTC 2011) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .. done (gdb) run -t `perl -e 'print "1"x2;'` Starting program: /usr/bin/c++filt -t `perl -e 'print "1"x2;'` Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x7fff26dc6f31 0x00010004a478 in ?? () (gdb) (gdb) i r rax0x7fff5faf5cd0 140734798716112 rbx0x7fff5fbfa378 140734799782776 rcx0x7fff26dc6f31 140733845368625 rdx0xc71c71c7 3340530119 rsi0x7fff5fbffd6a 140734799805802 rdi0x0 0 rbp0x7fff5faca610 0x7fff5faca610 rsp0x7fff5faca5e0 0x7fff5faca5e0 r8 0x1 1 r9 0x0 0 r100xa 655360 r110x7fff967e94e0 140735718266080 r120x7fff5fbfa69c 140734799783580 r130x10006e301 4295418625 r140x1000493a2 4295267234 r150x11b283 rip0x10004a478 0x10004a478 eflags 0x10202 66050 cs 0x2b 43 ss 0x0 0 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) bt #0 0x00010004a478 in ?? () #1 0x000100049870 in ?? () #2 0x00010004b4f1 in ?? () #3 0x00010004b5b1 in ?? () #4 0x00010004b60e in ?? () #5 0x000100043a4c in ?? () #6 0x000114a5 in ?? () #7 0x000111a8 in ?? () #8 0x00011030 in ?? () (gdb) cheers rfdslabs -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/13557] New: Slim LTO does not work for mingw32 target
http://sourceware.org/bugzilla/show_bug.cgi?id=13557 Bug #: 13557 Summary: Slim LTO does not work for mingw32 target Product: binutils Version: 2.23 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sourceware.org ReportedBy: d.g.gorbac...@gmail.com Classification: Unclassified Target: mingw32 Created attachment 6143 --> http://sourceware.org/bugzilla/attachment.cgi?id=6143 Testcase -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/13121] bfd HEAD 2011-08-23 does not build on AIX 5.3 without --enable-werror=no
http://sourceware.org/bugzilla/show_bug.cgi?id=13121
Steven Schweda changed:
What|Removed |Added
CC||sms at antinode dot info
--- Comment #3 from Steven Schweda 2012-01-04
06:01:09 UTC ---
I was recently trying to build 2.22 on my AIX (6.1) system when I ran
into this problem. My solution was simple: Change the variable name
"finfo" to something less collision-prone ("flaginfo"):
blue# diff -u bfd/reloc.c_orig bfd/reloc.c
--- bfd/reloc.c_orig2011-07-24 09:20:06.0 -0500
+++ bfd/reloc.c 2011-12-31 00:32:36.0 -0600
@@ -6124,9 +6124,9 @@
void
bfd_generic_lookup_section_flags (struct bfd_link_info *info
ATTRIBUTE_UNUSED,
- struct flag_info *finfo)
+ struct flag_info *flaginfo)
{
- if (finfo != NULL)
+ if (flaginfo != NULL)
{
(*_bfd_error_handler) (_("INPUT_SECTION_FLAGS are not supported.\n"));
return;
To me, that seemed effective and harmless. Around here:
blue# uname -a
AIX blue 1 6 000F1F6E4C00
blue# gcc --version
gcc (GCC) 4.2.0
[...]
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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/13558] New: binutils 2.22 v. AIX 6.1 -- build fails with large-file support problems (and mkdtemp confusion)
http://sourceware.org/bugzilla/show_bug.cgi?id=13558 Bug #: 13558 Summary: binutils 2.22 v. AIX 6.1 -- build fails with large-file support problems (and mkdtemp confusion) Product: binutils Version: 2.22 Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassig...@sourceware.org ReportedBy: s...@antinode.info Classification: Unclassified I was recently trying to build 2.22 on my AIX (6.1) system when I ran into a problem. Instance 1: [...] In file included from syslex.c:549: /usr/include/unistd.h:171: error: conflicting types for 'lseek64' /usr/include/unistd.h:169: error: previous declaration of 'lseek64' was here In file included from /usr/include/unistd.h:746, from syslex.c:549: /usr/include/sys/lockf.h:64: error: conflicting types for 'lockf64' /usr/include/sys/lockf.h:62: error: previous declaration of 'lockf64' was here [and a host of others ...] The cause seems to be sub-optimal handling of the large-file support macros, which need to be defined before the affected system header files are processed. My manual fix to binutils/syslex.c was this: blue# diff binutils/syslex.c_orig binutils/syslex.c blue# diff binutils/syslex.c_orig binutils/syslex.c 1c1 < --- > #include "config.h" >From the looks of it, I suspect that this thing is generated, and so the change would need to be made elsewhere, but the essence is to get "config.h" processed before the system header files. Similarly, instance 2: [...] gcc -DHAVE_CONFIG_H -I. -I. -I. -I../bfd -I./../bfd -I./../include -DLOCALEDIR= "\"/usr/local/share/locale\"" -Dbin_dummy_emulation=bin_aix_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT od-xcoff.o -MD -MP -MF .deps/od-xcoff.Tpo -c -o od-xcoff.o od-xcoff.c In file included from sysdep.h:27, from od-xcoff.c:24: /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.2.0/include/stdio.h:511: error: c onflicting types for 'fgetpos64' /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.2.0/include/stdio.h:310: error: p revious declaration of 'fgetpos64' was here /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.2.0/include/stdio.h:514: error: c onflicting types for 'fseeko64' /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.2.0/include/stdio.h:454: error: p revious declaration of 'fseeko64' was here [...] My fix: blue# diff binutils/od-xcoff.c_orig binutils/od-xcoff.c 21a22,23 > #include "config.h" > Also, the "configure" test for 'mkdtemp' gets a result which might best be described as unfortunate: [...] gcc -DHAVE_CONFIG_H -I. -I. -I. -I../bfd -I./../bfd -I./../include -DLOCALEDIR= "\"/usr/local/share/locale\"" -Dbin_dummy_emulation=bin_aix_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT bucomm.o -M D -MP -MF .deps/bucomm.Tpo -c -o bucomm.o bucomm.c cc1: warnings being treated as errors bucomm.c: In function 'make_tempdir': bucomm.c:531: warning: implicit declaration of function 'mkdtemp' bucomm.c:531: warning: return makes pointer from integer without a cast gmake[4]: *** [bucomm.o] Error 1 [...] My manual fix: blue# diff binutils/config.h_orig binutils/config.h 93c93 < #define HAVE_MKDTEMP 1 --- > /* #define HAVE_MKDTEMP 1 */ I didn't look at the details, but I'm guessing that "configure" did some less-than-thorough test for "mkdtemp". Perhaps "mkdtemp" is in some run-time library, so a link-only test might work, but it appears not to be in any of the system header files, so an actual compilation (with "warnings being treated as errors") will fail this way. For my purposes, the (sleazy) manual edit of "binutils/config.h" was good enough, but a more realistic test in "configure" would be more satisfying. Around here: blue# uname -a AIX blue 1 6 000F1F6E4C00 blue# gcc --version gcc (GCC) 4.2.0 [...] -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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
