[Bug gold/18010] gold -O2 breaks LLVM's TableGen on ppc64
https://sourceware.org/bugzilla/show_bug.cgi?id=18010 --- Comment #8 from Cary Coutant --- >> Does it seem reasonable to simply disable optimization for sections with >> alignment > 1? > > Works for me. > > I'll note that for aligned strings the most useful optimisation is likely > removal of exact duplicates. Oh, sorry, I didn't mean to suggest disabling duplicate merging -- just the optimization where we look for strings that are suffixes of others. I'd argue that your statement is true for unaligned strings as well. (I'm actually surprised that anyone is actually using -O2!) -cary -- 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 gold/18010] gold -O2 breaks LLVM's TableGen on ppc64
https://sourceware.org/bugzilla/show_bug.cgi?id=18010 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #6 from Cary Coutant --- It seems that optimization of string merge sections is even less useful when the section has an alignment > 1 -- I just don't think it would be worth trying to find tails that just happen to fall on the required alignment boundary. Does it seem reasonable to simply disable optimization for sections with alignment > 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/18028] New: 32-bit ld runs out of memory when linking 32-bit clang with debug info
https://sourceware.org/bugzilla/show_bug.cgi?id=18028 Bug ID: 18028 Summary: 32-bit ld runs out of memory when linking 32-bit clang with debug info Product: binutils Version: 2.26 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com On Linux/x86, 32-bit ld runs out of memeory when linking 32-bit clang with debug info: [hjl@gnu-mic-2 build-i686-linux]$ /usr/local32/bin/ld.bfd `cat args` /usr/local32/bin/ld.bfd: final link failed: Memory exhausted [hjl@gnu-mic-2 build-i686-linux]$ /usr/local32/bin/ld.bfd -s `cat args` [hjl@gnu-mic-2 build-i686-linux]$ file Debug+Asserts/bin/clang Debug+Asserts/bin/clang: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=670f5994a01c0d03c089dffd439e338233638fd1, stripped [hjl@gnu-mic-2 build-i686-linux]$ -- 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/18025] New: dwarf2 debug info after rebasing DLLs unusable
https://sourceware.org/bugzilla/show_bug.cgi?id=18025
Bug ID: 18025
Summary: dwarf2 debug info after rebasing DLLs unusable
Product: binutils
Version: 2.26 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: corinna at vinschen dot de
Target: cygwin, i686 and x86_64
Hi,
we're encountering a problem evaluating Dwarf2 debug info in DLLs after
rebasing the DLL. Rebasing, that is, moving the image base address of a
DLL and adjusting the relocation information, is an essential part of
DLL handling in the Cygwin distro, required for smooth operation of
the fork emulation.
Consider a DLL built with debug info, unstripped. As an example, I'm
using the latest file-5.22-1 package which comes with a DLL called
cygmagic-1.dll. The output of objdump -h on the built DLL looks like this:
$ objdump -h cygmagic-1.dll.
cygmagic-1.dll: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00013618 0004d9221000 0004d9221000 0600 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 0068 0004d9235000 0004d9235000 00013e00 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .rdata5258 0004d9236000 0004d9236000 00014000 2**6
CONTENTS, ALLOC, LOAD, READONLY, DATA
[...]
10 .debug_aranges 0510 0004d9243000 0004d9243000 0001c400 2**4
CONTENTS, READONLY, DEBUGGING
11 .debug_info 0002b4ab 0004d9244000 0004d9244000 0001ca00 2**0
CONTENTS, READONLY, DEBUGGING
12 .debug_abbrev 3d2b 0004d927 0004d927 00048000 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_line 6046 0004d9274000 0004d9274000 0004be00 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_frame 2b68 0004d927b000 0004d927b000 00052000 2**3
CONTENTS, READONLY, DEBUGGING
15 .debug_str0302 0004d927e000 0004d927e000 00054c00 2**0
CONTENTS, READONLY, DEBUGGING
16 .debug_loc000259a2 0004d927f000 0004d927f000 00055000 2**0
CONTENTS, READONLY, DEBUGGING
17 .debug_ranges 3230 0004d92a5000 0004d92a5000 0007aa00 2**0
CONTENTS, READONLY, DEBUGGING
Notice the VMA addresses. The DLL is based at 0x4d922. This DLL
works and evaluating the debug info works nicely. This is the `nm -l'
output before rebasing:
$ nm -l cygmagic-1.dll | grep usr/src/debug
[...]
0004d922bd80 T file_fmttime /usr/src/debug/file-5.22-1/src/print.c:232
0004d922c520 T file_fsmagic /usr/src/debug/file-5.22-1/src/fsmagic.c:104
0004d922d3f0 T file_getbuffer
/usr/src/debug/file-5.22-1/src/funcs.c
:321
0004d922b120 T file_is_tar /usr/src/debug/file-5.22-1/src/is_tar.c:64
0004d922a1d0 T file_looks_utf8
/usr/src/debug/file-5.22-1/src/encodin
g.c:295
[...]
So it shows the sources and line numbers for the symbols as expected:
$ nm -l cygmagic-1.dll | grep usr/src/debug | wc -l
198
And here's what happens after rebase to some arbitrary address:
$ rebase -b 0x3 cygmagic-1.dll
$ nm -l cygmagic-1.dll | grep usr/src/debug | wc -l
0
nm lost all connection between the symbols and their sources.
Checking with GDB: In GDB you can set a breakpoint on this function and
it's loaded to the same address. When breaking, GDB shows the function,
its arguments, and the source line:
Breakpoint 1, file_fsmagic (ms=ms@entry=0x6000394f0,
fn=fn@entry=0x23cb75 "./file", sb=sb@entry=0x23c8f0)
at /usr/src/debug/file-5.22-1/src/fsmagic.c:104
104 {
After rebasing to, e.g., 0x3 as above, it looks like this:
$ rebase -b 0x3 cygmagic-1.dll
$ nm cygmagic-1.dll | grep file_fsmagic
0003c520 T file_fsmagic
(gdb) r ./file
Starting program: /usr/bin/file ./file
[New Thread 2696.0xecc]
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x4d922c520
So, apparently the debug info uses absolute addresses, rather than
image base relative or section relative addresses. After rebasing,
the info points to invalid addresses.
Shouldn't binutils be aware of the effect of rebasing, and make sure
that the existing debug info is correctly evaluated even after rebase?
Even better, shouldn't the dwarf2 debug info be defined image base
relative rather than using absolute addressing, to make sure it
still contains valid information even after rebasing a DLL? At least
on PE/COFF targets?
Thanks,
Corinna
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-b
[Bug admin/18022] change in libiberty.h prevents compilation by IBM C compiler
https://sourceware.org/bugzilla/show_bug.cgi?id=18022
--- Comment #2 from Michael ---
My bad - was stil asleep I guess...
/opt/bin/make > build/aix/make.out # only text to stderr shown
"./regex.c", line 31.3: 1506-224 (I) Incorrect pragma ignored.
"/usr/include/alloca.h", line 34.1: 1506-224 (I) Incorrect pragma ignored.
"./../include/libiberty.h", line 113.24: 1506-172 (S) Parameter type list for
function basename contains parameters without identifiers.
"./../include/libiberty.h", line 113.38: 1506-276 (S) Syntax error: possible
missing '{'?
make[2]: *** [cp-demangle.o] Error 1
make[1]: *** [all-libiberty] Error 2
make: *** [all] Error 2
/opt/bin/make returned an error
--
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 admin/18022] change in libiberty.h prevents compilation by IBM C compiler
https://sourceware.org/bugzilla/show_bug.cgi?id=18022 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #1 from Ian Lance Taylor --- What is the actual error? I don't see it. -- 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 gold/18010] gold -O2 breaks LLVM's TableGen on ppc64
https://sourceware.org/bugzilla/show_bug.cgi?id=18010 --- Comment #5 from Markus Trippelsdorf --- Given that the -Wl,-O2 optimization is rather unimportant ,see the comment in stringpool.cc, optimize_ could be simply left as false for ppc64 targets in that file. -- 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 admin/18022] New: change in libiberty.h prevents compilation by IBM C compiler
https://sourceware.org/bugzilla/show_bug.cgi?id=18022 Bug ID: 18022 Summary: change in libiberty.h prevents compilation by IBM C compiler Product: binutils Version: 2.25 Status: NEW Severity: critical Priority: P2 Component: admin Assignee: unassigned at sourceware dot org Reporter: aixtools at gmail dot com I was able to compile and build binutils-2.24 without any real issues. However, version 2.25 will not build. make stops with the following error Details: +103 /* HAVE_DECL_* is a three-state macro: undefined, 0 or 1. If it is +104 undefined, we haven't run the autoconf check so provide the +105 declaration without arguments. If it is 0, we checked and failed +106 to find the declaration so provide a fully prototyped one. If it +107 is 1, we found it so don't provide any declaration at all. */ +108 #if !HAVE_DECL_BASENAME +109 #if defined (__GNU_LIBRARY__ ) || defined (__linux__) \ +110 || defined (__FreeBSD__) || defined (__OpenBSD__) || defined (__NetBSD__) \ +111 || defined (__CYGWIN__) || defined (__CYGWIN32__) || defined (__MINGW32__) \ +112 || defined (__DragonFly__) || defined (HAVE_DECL_BASENAME) +113 extern char *basename (const char *) ATTRIBUTE_RETURNS_NONNULL ATTRIBUTE_NONNULL(1); +114 #else +115 /* Do not allow basename to be used if there is no prototype seen. We +116 either need to use the above prototype or have one from +117 autoconf which would result in HAVE_DECL_BASENAME being set. */ +118 #define basename basename_cannot_be_used_without_a_prototype +119 #endif +120 #endif The important part of the diff for this file between 2.24 and 2.25 is: --- ./binutils-2.24/include/libiberty.h 2013-11-04 15:33:39 + +++ ./binutils-2.25/include/libiberty.h 2014-10-14 07:32:04 + ... @@ -106,8 +106,11 @@ to find the declaration so provide a fully prototyped one. If it is 1, we found it so don't provide any declaration at all. */ #if !HAVE_DECL_BASENAME -#if defined (__GNU_LIBRARY__ ) || defined (__linux__) || defined (__FreeBSD__) || defined (__OpenBSD__) || defined(__NetBSD__) || defined (__CYGWIN__) || defined (__CYGWIN32__) || defined (__MINGW32__) || defined (HAVE_DECL_BASENAME) -extern char *basename (const char *); +#if defined (__GNU_LIBRARY__ ) || defined (__linux__) \ + || defined (__FreeBSD__) || defined (__OpenBSD__) || defined (__NetBSD__) \ + || defined (__CYGWIN__) || defined (__CYGWIN32__) || defined (__MINGW32__) \ + || defined (__DragonFly__) || defined (HAVE_DECL_BASENAME) +extern char *basename (const char *) ATTRIBUTE_RETURNS_NONNULL ATTRIBUTE_NONNULL(1); #else /* Do not allow basename to be used if there is no prototype seen. We either need to use the above prototype or have one from ... Hopefully, this will not be too difficult to correct. If you need any additional info (e.g., config.log) - just ask. Michael -- 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
