[Bug binutils/31243] New: nm --help shall print ‘’--without-symbol-versions”
https://sourceware.org/bugzilla/show_bug.cgi?id=31243 Bug ID: 31243 Summary: nm --help shall print ‘’--without-symbol-versions” Product: binutils Version: 2.42 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- nm-2.41.50.20231117 --help prints --with-symbol-versions Display version strings after symbol names As this is the default, --help shall print how to deviate from it, thus: --without-symbol-versions Hide version strings after symbol names -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29987] bfd/archive.c:1447: undefined reference to `filename_ncmp'
https://sourceware.org/bugzilla/show_bug.cgi?id=29987 --- Comment #3 from dilyan.palauzov at aegee dot org --- You are right: # cd /usr/local/lib64 # ls libibe* -ld -rw-r--r-- 1 root staff 397474 Apr 24 2017 libiberty.a # mv libiberty.a libiberty.a.bak Now the build works. Nevertheless the build shall prefer its own libiberty.a . -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29987] bfd/archive.c:1447: undefined reference to `filename_ncmp'
https://sourceware.org/bugzilla/show_bug.cgi?id=29987 --- Comment #1 from dilyan.palauzov at aegee dot org --- linking ld.bfd also fails, when using ld.bfd 2.39.50.20220817: make V=1 make[1]: Entering directory '/root/binutils/ld' Making all in po make[2]: Entering directory '/root/binutils/ld/po' make[2]: Nothing to be done for 'all' make[2]: Leaving directory '/root/binutils/ld/po' make[2]: Entering directory '/root/binutils/ld' /bin/sh ./libtool --tag=CC --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -DELF_LIST_OPTIONS=true -DELF_SHLIB_LIST_OPTIONS=true -DELF_PLT_UNWIND_LIST_OPTIONS=true -I/usr/local/include -O2 -pipe -g -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o ldbuildid.o eelf_x86_64.o eelf32_x86_64.o eelf_i386.o eelf_iamcu.o ldelf.o ldelfgen.o ../bfd/libbfd.la ../libctf/libctf.la ../libiberty/libiberty.a -lz -L/usr/local/lib64 -lzstd libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -DELF_LIST_OPTIONS=true -DELF_SHLIB_LIST_OPTIONS=true -DELF_PLT_UNWIND_LIST_OPTIONS=true -I/usr/local/include -O2 -pipe -g -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o ldbuildid.o eelf_x86_64.o eelf32_x86_64.o eelf_i386.o eelf_iamcu.o ldelf.o ldelfgen.o ../bfd/.libs/libbfd.a -L/usr/local/lib64 ../libctf/.libs/libctf.a -L/root/binutils/libctf/../libiberty /root/binutils/bfd/.libs/libbfd.a /root/binutils/libsframe/.libs/libsframe.a -liberty ../libiberty/libiberty.a -lz -lzstd /usr/local/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../libiberty/libiberty.a(concat.o): in function `concat_length': /git/binutils-gdb/libiberty/concat.c:91: multiple definition of `concat_length'; /usr/local/lib64/libiberty.a(concat.o):concat.c:(.text+0x0): first defined here /usr/local/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../libiberty/libiberty.a(concat.o): in function `concat_copy': /git/binutils-gdb/libiberty/concat.c:106: multiple definition of `concat_copy'; /usr/local/lib64/libiberty.a(concat.o):concat.c:(.text+0xb0): first defined here /usr/local/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../libiberty/libiberty.a(concat.o): in fu[89/1980]oncat_copy2': /git/binutils-gdb/libiberty/concat.c:130: multiple definition of `concat_copy2'; /usr/local/lib64/libiberty.a(concat.o):concat.c:(.text+0x180): first defined here /usr/local/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../libiberty/libiberty.a(concat.o): in function `concat': /git/binutils-gdb/libiberty/concat.c:141: multiple definition of `concat'; /usr/local/lib64/libiberty.a(concat.o):concat.c:(.text+0x250): first defined here /usr/local/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../libiberty/libiberty.a(concat.o): in function `reconcat': /git/binutils-gdb/libiberty/concat.c:178: multiple definition of `reconcat'; /usr/local/lib64/libiberty.a(concat.o):concat.c:(.text+0x3e0): first defined here /usr/local/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../libiberty/libiberty.a(filename_cmp.o): in function `filename_cmp': /git/binutils-gdb/libiberty/filename_cmp.c:57: multiple definition of `filename_cmp'; /usr/local/lib64/libiberty.a(filename_cmp.o):filename_cmp.c:(.text+0x0): first defined here /usr/local/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../libiberty/libiberty.a(hashtab.o): in function `htab_size': /git/binutils-gdb/libiberty/hashtab.c:216: multiple definition of `htab_size'; /usr/local/lib64/libiberty.a(hashtab.o):hashtab.c:(.text+0x2c0): first defined here /usr/local/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../libiberty/libiberty.a(hashtab.o): in function `htab_elements': /git/binutils-gdb/libiberty/hashtab.c:226: multiple definition of `htab_elements'; /usr/local/lib64/libiberty.a(hashtab.o):hashtab.c:(.text+0x2d0): first defined here /usr/local/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../libiberty/libiberty.a(hashtab.o): in function `htab_create_alloc_ex': /git/binutils-gdb/libiberty/hashtab.c:297: multiple definition of `htab_create_alloc_ex'; /usr/local/lib64/libiberty.a(hashtab.o):hashtab.c:(.text+0x420): first defined here (and so on) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29987] New: bfd/archive.c:1447: undefined reference to `filename_ncmp'
https://sourceware.org/bugzilla/show_bug.cgi?id=29987 Bug ID: 29987 Summary: bfd/archive.c:1447: undefined reference to `filename_ncmp' Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- With gcc 12.2.1 20230108 I try to compile binutils-gdb gdb-13-branchpoint-431-gda1f81c128b (this is the output of $ git describe --always ) by calling export CONFIG_SITE="a" export CFLAGS="-O2 -pipe -g" export CXXFLAGS="-O2 -pipe -g" /git/binutils-gdb/configure --enable-threads --with-system-zlib --with-system-readline --with-python=/usr/local/bin/python3 --enable-default-hash-style=gnu --enable-gold --without-guile make This fails with make all-am make[5]: Entering directory '/root/binutils/gprofng/src' /bin/sh ../libtool --tag=CXX --mode=link g++ -Wall -pthread -Wno-switch -O2 -pipe -g -o gp-archive gp-archive.o ArchiveExp.o libgprofng.la -lz libtool: link: g++ -Wall -pthread -Wno-switch -O2 -pipe -g -o gp-archive gp-archive.o ArchiveExp.o ./.libs/libgprofng.a -L/usr/local/lib64 -L/root/binutils/libiberty /root/binutils/opcodes/.libs/libopcodes.a /root/binutils/bfd/.libs/libbfd.a -lzstd /root/binutils/libsframe/.libs/libsframe.a -liberty -lpthread -ldl /usr/local/lib/../lib64/libstdc++.so -lm -lz -pthread -Wl,-rpath -Wl,/usr/local/lib/../lib64 -Wl,-rpath -Wl,/usr/local/lib/../lib64 /usr/local/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: /root/binutils/bfd/.libs/libbfd.a(archive.o): in function `adjust_relative_path': /git/binutils-gdb/bfd/archive.c:1447: undefined reference to `filename_ncmp' /usr/local/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: /root/binutils/bfd/.libs/libbfd.a(archive.o): in function `_bfd_construct_extended_name_table': /git/binutils-gdb/bfd/archive.c:1643: undefined reference to `filename_ncmp' /usr/local/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: /root/binutils/bfd/.libs/libbfd.a(syms.o): in function `_bfd_stab_section_find_nearest_line': /git/binutils-gdb/bfd/syms.c:1423: undefined reference to `filename_ncmp' collect2: error: ld returned 1 exit status make[5]: *** [Makefile:728: gp-archive] Error 1 make[5]: Leaving directory '/root/binutils/gprofng/src' Last time I compiled successfully was with 2.39.50.20220817 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28141] support a small discontiguous stack for goroutines
https://sourceware.org/bugzilla/show_bug.cgi?id=28141 --- Comment #6 from dilyan.palauzov at aegee dot org --- > but given that it is specific to gccgo and not needed by the, umm, non-gcc go > compiler My understanding is that this can be used by any language, whenever -fsplit-stack - https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fsplit-stack - is passed to gcc. So it is not specific to gccgo, but to any multi-threaded program. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28435] New: ar --record--libdeps: ar l vs ar L
https://sourceware.org/bugzilla/show_bug.cgi?id=28435 Bug ID: 28435 Summary: ar --record--libdeps: ar l vs ar L Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- Info (binutils) ar command line says: A number of modifiers (MOD) may immediately follow the P keyletter, to specify variations on an operation's behavior: 'l' Specify dependencies of this library. The dependencies must immediately follow this option character, must use the same syntax as the linker command line, and must be specified within a single argument. I.e., if multiple items are needed, they must be quoted to form a single command line argument. For example 'L "-L/usr/local/lib -lmydep1 -lmydep2"' Shouldn’t in the example be used 'l "-L…"' instead of 'L "-L…"'? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28141] support a small discontiguous stack for goroutines
https://sourceware.org/bugzilla/show_bug.cgi?id=28141 --- Comment #2 from dilyan.palauzov at aegee dot org --- I filled https://github.com/golang/go/issues/47622 asking for clear specification. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28141] New: support a small discontiguous stack for goroutines
https://sourceware.org/bugzilla/show_bug.cgi?id=28141 Bug ID: 28141 Summary: support a small discontiguous stack for goroutines Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- According to https://golang.org/doc/install/gccgo the gold linker can use a small discontiguous stack for goroutines, and ld.bfd or lld can not do this. Please implement in ld.bfd whatever is necessary for “discontintigious stack” support. To be honest, I acknowledge that the documentation above can be wrong. E.g. https://llvm.org/docs/GoldPlugin.html says that only gold can support linker plugins, which is not the case for very long time. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] --dynamic-list doesn't work correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 --- Comment #23 from dilyan.palauzov at aegee dot org --- Can I delete https://mail.aegee.org/dpa/pr25975/pr-gold-25975.tar.xz ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] --dynamic-list doesn't work correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 --- Comment #21 from dilyan.palauzov at aegee dot org --- > Do you have __asan_extra_spill_area in ./libclang_rt.asan-x86_64.a.syms? If I do not have __asan_extra_spill_area in ./libclang_rt.asan-x86_64.a.syms does this mean, that clang/rt was self-compiled anyhow wrong? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] clang -fsanitze=address prints warning only with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 --- Comment #17 from dilyan.palauzov at aegee dot org --- libclang_rt.asan-x86_64.a.syms, included in https://mail.aegee.org/dpa/pr25975/pr-gold-25975.tar.xz, does not contain “spill". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] clang -fsanitze=address prints warning only with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 --- Comment #15 from dilyan.palauzov at aegee dot org --- My libclang_rt.asan-x86_64.a is included in https://mail.aegee.org/dpa/pr25975/pr-gold-25975.tar.xz. $ readelf -sW libclang_rt.asan-x86_64.a |grep _asan_extra_spill_area 281: 61 FUNCGLOBAL HIDDEN 172 __asan_extra_spill_area 12: 0 NOTYPE GLOBAL DEFAULT UND __asan_extra_spill_area $ clang -fsanitize=address -fuse-ld=gold i.o $ readelf -sW a.out |grep _asan_extra_spill_area 1357: 004c5b2061 FUNCLOCAL HIDDEN12 __asan_extra_spill_area -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] clang -fsanitze=address prints warning only with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 --- Comment #13 from dilyan.palauzov at aegee dot org --- Is this now reproducible? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] clang -fsanitze=address prints warning only with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 --- Comment #12 from dilyan.palauzov at aegee dot org --- Calling ./chroot-gold-asan from https://mail.aegee.org/dpa/pr25975/pr-gold-25975.tar.xz (39MB), which is the same as calling chroot . ./ld.gold -Llib64 --hash-style=both --eh-frame-hdr -m elf_x86_64 -dynamic-linker ./ld-linux-x86-64.so.2 -o a.out ./crt1.o ./crti.o ./crtbegin.o --whole-archive ./libclang_rt.asan-x86_64.a --no-whole-archive --dynamic-list=./libclang_rt.asan-x86_64.a.syms i.o --no-as-needed -lpthread -lrt -lm -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ./crtend.o ./crtn.o prints: ./ld.gold: warning: Cannot export local symbol '__asan_extra_spill_area' ld.gold is from binutils-gdb.master, commit 607b483327fdfc75fb193870b3c4e7445ce3f64d. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] clang -fsanitze=address prints warning only with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 --- Comment #10 from dilyan.palauzov at aegee dot org --- Does it also work with the attached i.o as input? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25940] ld.bfd, clang’s ubsan, shared libraries, and virtual tables do not work together
https://sourceware.org/bugzilla/show_bug.cgi?id=25940 dilyan.palauzov at aegee dot org changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #6 from dilyan.palauzov at aegee dot org --- Closing, as I think this is a problem of clang: https://bugs.llvm.org/show_bug.cgi?id=45948 In particular, while $ clang -fsanitize=undefined -L. -lz a.c does not work, calling $ clang -fsanitize=undefined -c -o a.o a.c $ clang++ -fsanitize=undefined -L. -lz a.o works! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] clang -fsanitze=address prints warning only with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 --- Comment #8 from dilyan.palauzov at aegee dot org --- Switching to the alternative gold (411ae86dfcf9da4) has not helped. The outputs of clang -fsanitize=address -c -o i.o i.c clang -v -fuse-ld=bfd -fsanitize=address i.o &> bfd.txt clang -v -fuse-ld=lld -fsanitize=address i.o &> lld.txt clang -v -Wl,--debug,all -fuse-ld=gold -fsanitize=address i.o &> gold.txt are attached. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] clang -fsanitze=address prints warning only with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 --- Comment #7 from dilyan.palauzov at aegee dot org --- Created attachment 12532 --> https://sourceware.org/bugzilla/attachment.cgi?id=12532=edit Output of `clang -v -fsanitize=address -fuse-ld=gold -Wl,-debug,all i.o` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] clang -fsanitze=address prints warning only with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 --- Comment #6 from dilyan.palauzov at aegee dot org --- Created attachment 12531 --> https://sourceware.org/bugzilla/attachment.cgi?id=12531=edit Output of `clang -v -fuse-ld=lld -fsanitize=address i.o` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] clang -fsanitze=address prints warning only with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 --- Comment #5 from dilyan.palauzov at aegee dot org --- Created attachment 12530 --> https://sourceware.org/bugzilla/attachment.cgi?id=12530=edit Output of `clang -v -fuse-ld=bfd -fsanitize=address i.o` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] clang -fsanitze=address prints warning only with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 --- Comment #4 from dilyan.palauzov at aegee dot org --- Created attachment 12529 --> https://sourceware.org/bugzilla/attachment.cgi?id=12529=edit Output of `clang -fsanitize=address -c -o i.o i.c` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] clang -fsanitze=address prints warning only with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 dilyan.palauzov at aegee dot org changed: What|Removed |Added Summary|clang -fsanitze=address |clang -fsanitze=address |prints waring only with |prints warning only with |gold|gold -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] clang -fsanitze=address prints waring only with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 dilyan.palauzov at aegee dot org changed: What|Removed |Added Summary|clang -fsanitze=adderss |clang -fsanitze=address |prints waring only with |prints waring only with |gold|gold -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25984] New: Extend the output of --help to print the default for --hash-style
https://sourceware.org/bugzilla/show_bug.cgi?id=25984 Bug ID: 25984 Summary: Extend the output of --help to print the default for --hash-style Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: dilyan.palauzov at aegee dot org CC: ian at airs dot com Target Milestone: --- ld.gold 2.34.50.20200513 1.16 --help prints: > --hash-style [sysv,gnu,both] Dynamic hash style Extend the output of --help to print the default hash style, when --hash-style= is not passed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25979] New: Report default hash-style on --help
https://sourceware.org/bugzilla/show_bug.cgi?id=25979 Bug ID: 25979 Summary: Report default hash-style on --help Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- ld.bfd 2.34.50.20200506 --help prints: --hash-style=STYLE Set hash style to sysv, gnu or both It shall print which hash style is the default (will be used, if --hash-style is not passed) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] clang -fsanitze=adderss prints waring only with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=25975 --- Comment #2 from dilyan.palauzov at aegee dot org --- I think I have it, at least there are some libclang_rt files. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25940] ld.bfd, clang’s ubsan, shared libraries, and virtual tables do not work together
https://sourceware.org/bugzilla/show_bug.cgi?id=25940 --- Comment #5 from dilyan.palauzov at aegee dot org --- I asked at https://sourceware.org/bugzilla/show_bug.cgi?id=25975 why gold prints “/usr/local/bin/ld.gold: warning: Cannot export local symbol '__asan_extra_spill_ area'” when used by clangs’ address sanitizer. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25975] New: clang -fsanitze=adderss prints waring only with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=25975
Bug ID: 25975
Summary: clang -fsanitze=adderss prints waring only with gold
Product: binutils
Version: 2.35 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: dilyan.palauzov at aegee dot org
CC: ian at airs dot com
Target Milestone: ---
I have clang and lld 10.0, ld.bfd 2.34.50.20200506, ld.gold 1.16 /
2.34.50.20200506 and i.c:
#include
#include
int main() {
bool b = 99;
printf("a %i\n", b);
}
The question is, why only the last call emits a warning:
$ clang -fsanitize=address -fuse-ld=bfd -o i i.c
$ clang -fsanitize=address -fuse-ld=lld -o i i.c
$ clang -fsanitize=address -fuse-ld=gold -o i i.c
/usr/local/bin/ld.gold: warning: Cannot export local symbol
'__asan_extra_spill_
area'
See also https://sourceware.org/bugzilla/show_bug.cgi?id=25940.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25940] ld.bfd, clang’s ubsan, shared libraries, and virtual tables do not work together
https://sourceware.org/bugzilla/show_bug.cgi?id=25940
--- Comment #4 from dilyan.palauzov at aegee dot org ---
I created one more file, b.cpp:
extern "C" {
void y();
}
int main() {
y();
}
It differs from b.c only in the file extension and y() is under “extern "C"”.
Doing the iterations with z.cpp and e.cpp, but replacing the executable source
from b.c to b.cpp makes all ubsan warning disappear, except:
input z clang linker gold sanitizer address
/usr/local/bin/ld.gold: warning: Cannot export local symbol
'__asan_extra_spill_area'
To sum up, when a DSO is written in C++ and does class conversions, then the
DSO has at the end undefined symbols “__ubsan_vptr_type_cache” and
“`__ubsan_handle_dynamic_type_cache_miss”. These symbols are resolved by
clang++, when the DSO is linked towards a C++ code, but not resolved by clang
(withouth ++) when the DSO is linked towards C code. Moreover, ld.bfd report
problem a problem at link time, while with gold and lld the report is at
runtime.
With the address sanitizer and clang, gold reports one additional warning,
which cause I cannot figure out.
So why does the linker resolve “__ubsan_vptr_type_cache” and
“`__ubsan_handle_dynamic_type_cache_miss” when it is called from clang++, but
not when called from clang? It is valid to link a DSO with extern "C" exported
functions with a .c code.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25940] ld.bfd, clang’s ubsan, shared libraries, and virtual tables do not work together
https://sourceware.org/bugzilla/show_bug.cgi?id=25940
--- Comment #3 from dilyan.palauzov at aegee dot org ---
libubsan comes from gcc: after compiling and installig clang/llvm, no libubsan
is installed. So it is not possible to link with the wrong libubsan, when
using clang, as no such linking is supposed to be done.
I have installed the LLVMgold.so plugin for clang 10 under
${libdir}/bfd-plugins and I created one more file, e.cpp:
#include
#include
#include
struct x {
std::string x;
};
struct z : virtual x {
z() {
bool b = 99;
printf("a %i\n", b);
}
};
extern "C" {
void y();
}
void y() {
const z x1 = z();
}
It differs from z.cpp only in:
e.cpp: const z x1 = z();
z.cpp: const x x1 = z();
The implication of this difference is, that after compiling e.cpp and z.cpp
into a DSO with
clang++ -fsanitize=address,undefined -shared -fpic -o libz.so z.cpp
clang++ -fsanitize=address,undefined -shared -fpic -o libe.so e.cpp
and then comparing the output of "nm -CDP libz.so" with "nm -CDP libe.so",
only in libz.so:
__asan_report_load8 U
__asan_stack_malloc_2 U
__ubsan_handle_dynamic_type_cache_miss U
__ubsan_vptr_type_cache U
Only in libe.so
__asan_stack_malloc_1 U
and other differences, not related to sanitizers.
Then I call:
#!/usr/local/bin/bash
for i in e z; do
for linker in bfd lld gold; do
for sanitizer in address undefined "address,undefined"; do
echo "input $i clang linker $linker sanitizer $sanitizer"
rm lib$i.so b -f
clang++ -fsanitize=$sanitizer -fuse-ld=$linker -shared -fpic -o
lib$i.so $i.cpp \
&& clang -fsanitize=$sanitizer -fuse-ld=$linker -L. -l$i b.c -o b &&
LD_LIBRARY_PATH=. ./b
echo "input $i gcc linker $linker sanitizer $sanitizer"
rm lib$i.so b -f
g++ -fsanitize=$sanitizer -fuse-ld=$linker -shared -fpic -o
lib$i.so $i.cpp \
&& gcc -fsanitize=$sanitizer -fuse-ld=$linker -L. -l$i b.c -o b &&
LD_LIBRARY_PATH=. ./b
done
done
done
The gcc and llvm linker plugins under libdir/bfd-plugins play no role for the
output, which is:
input e clang linker bfd sanitizer address
a 1
input e gcc linker bfd sanitizer address
a 1
input e clang linker bfd sanitizer undefined
a 1
input e gcc linker bfd sanitizer undefined
a 1
input e clang linker bfd sanitizer address,undefined
a 1
input e gcc linker bfd sanitizer address,undefined
a 1
input e clang linker lld sanitizer address
a 1
input e gcc linker lld sanitizer address
a 1
input e clang linker lld sanitizer undefined
a 1
input e gcc linker lld sanitizer undefined
a 1
input e clang linker lld sanitizer address,undefined
a 1
input e gcc linker lld sanitizer address,undefined
a 1
input e clang linker gold sanitizer address
/usr/local/bin/ld.gold: warning: Cannot export local symbol
'__asan_extra_spill_area'
a 1
input e gcc linker gold sanitizer address
a 1
input e clang linker gold sanitizer undefined
a 1
input e gcc linker gold sanitizer undefined
a 1
input e clang linker gold sanitizer address,undefined
/usr/local/bin/ld.gold: warning: Cannot export local symbol
'__asan_extra_spill_area'
a 1
input e gcc linker gold sanitizer address,undefined
a 1
input z clang linker bfd sanitizer address
a 1
input z gcc linker bfd sanitizer address
a 1
input z clang linker bfd sanitizer undefined
/usr/local/bin/ld.bfd: ./libz.so: undefined reference to
`__ubsan_vptr_type_cache'
/usr/local/bin/ld.bfd: ./libz.so: undefined reference to
`__ubsan_handle_dynamic_type_cache_miss'
clang-10: error: linker command failed with exit code 1 (use -v to see
invocation)
input z gcc linker bfd sanitizer undefined
a 1
input z clang linker bfd sanitizer address,undefined
/usr/local/bin/ld.bfd: ./libz.so: undefined reference to
`__ubsan_vptr_type_cache'
/usr/local/bin/ld.bfd: ./libz.so: undefined reference to
`__ubsan_handle_dynamic_type_cache_miss'
clang-10: error: linker command failed with exit code 1 (use -v to see
invocation)
input z gcc linker bfd sanitizer address,undefined
a 1
input z clang linker lld sanitizer address
a 1
input z gcc linker lld sanitizer address
a 1
input z clang linker lld sanitizer undefined
./b: symbol lookup error: ./libz.so: undefined symbol: __ubsan_vptr_type_cache
input z gcc linker lld sanitizer undefined
a 1
input z clang linker lld sanitizer address,undefined
./b: symbol lookup error: ./libz.so: undefined symbol: __ubsan_vptr_type_cache
input z gcc linker lld sanitizer address,undefined
a 1
input z clang linker gold sanitizer address
/usr/local/bin/ld.gold: warning: Cannot export local symbol
'__asan_extra_spill_area'
a 1
input z gcc linker gold sanitizer address
a 1
input z clang linker gold sanitizer undefined
./b: symbol lookup error: ./libz.so: undefined symbol: __ubsan_vptr_type_cache
input z gcc linker gold sanitizer undefined
a 1
input z cla
[Bug ld/25940] ld.bfd, clang’s ubsan, shared libraries, and virtual tables do not work together
https://sourceware.org/bugzilla/show_bug.cgi?id=25940 --- Comment #2 from dilyan.palauzov at aegee dot org --- Indeed, libubsan is from gcc. Does clang have its own libubsan and do make install of gcc and make install of clang both write libubsan under /usr/local/lib64? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25940] New: ld.bfd, clang’s ubsan, shared libraries, and virtual tables do not work together
https://sourceware.org/bugzilla/show_bug.cgi?id=25940
Bug ID: 25940
Summary: ld.bfd, clang’s ubsan, shared libraries, and virtual
tables do not work together
Product: binutils
Version: 2.35 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
I have ld.bfd 2.34.50.20200506, ld.gold 2.34.50.20200506, gcc/g++ 9.3.1
20200506, ld.lld 10.0.0, clang(++) 10.0.0, z.cpp:
#include
#include
#include
struct x {
std::string x;
};
struct z: virtual x {
z() {
bool b = 99;
printf("a %i\n", b);
}
};
extern "C" {
void y();
}
void y() {
const x x1 = z();
}
and a.c:
void y();
int main() {
y();
}
With --- CLANG ---
> clang++ -shared -fsanitize=address,undefined z.cpp -fpic -o libz.so
> nm -D libz.so|grep san
< U __asan_init
< U __asan_option_detect_stack_use_after_return
< U __asan_register_globals
< U __asan_report_load8
< U __asan_report_store8
< U __asan_stack_malloc_2
< U __asan_unregister_globals
< U __asan_version_mismatch_check_v8
< U __ubsan_handle_dynamic_type_cache_miss
< U __ubsan_handle_load_invalid_value
< U __ubsan_handle_type_mismatch_v1
< U __ubsan_vptr_type_cache
> clang -fsanitize=address,undefined -o b b.c -L. -lz -fuse-ld=bfd
< /usr/local/bin/ld.bfd: ./libz.so: undefined reference to
`__ubsan_vptr_type_cache'
< /usr/local/bin/ld.bfd: ./libz.so: undefined reference to
`__ubsan_handle_dynamic_type_cache_miss'
< clang-10: error: linker command failed with exit code 1 (use -v to see
invocation)
But if I remove the class conversions from z.cpp, then libz.so does not
contains __ubsan_vptr_type_cache as Undefined symbol, while it contains
__ubsan_handle_load_invalid_value, and then the linking clang+ld.bfd does work
> clang -fsanitize=address,undefined -o b b.c -L. -lz -fuse-ld=bfd -lubsan
< (No error, no warning)
> LD_LIBRARY_PATH=. ./b
< a 1
> clang -fsanitize=address,undefined -o b b.c -L. -lz -fuse-ld=gold
< /usr/local/bin/ld.gold: warning: Cannot export local symbol
'__asan_extra_spill_area'
> LD_LIBRARY_PATH=. ./b
< ./b: symbol lookup error: ./libz.so: undefined symbol:
__ubsan_vptr_type_cache
> clang -fsanitize=address,undefined -o b b.c -L. -lz -fuse-ld=gold -lubsan
< /usr/local/bin/ld.gold: warning: Cannot export local symbol
'__asan_extra_spill_area'
> LD_LIBRARY_PATH=. ./b
< a 1
> clang -fsanitize=address,undefined -o b b.c -L. -lz -fuse-ld=lld
< (No error, no warning)
> LD_LIBRARY_PATH=. ./b
< ./b: symbol lookup error: ./libz.so: undefined symbol:
__ubsan_vptr_type_cache
> clang -fsanitize=address,undefined -o b b.c -L. -lz -fuse-ld=lld -lubsan
< (No error, no warning)
> LD_LIBRARY_PATH=. ./b
< a 1
--- GCC ---
> g++ -shared -fsanitize=address,undefined z.cpp -fpic -o libz.so
> nm -D libz.so|grep san
< U __asan_handle_no_return
< U __asan_init
< U __asan_option_detect_stack_use_after_return
< U __asan_register_globals
< U __asan_report_load8
< U __asan_report_store8
< U __asan_stack_malloc_2
< U __asan_unregister_globals
< U __asan_version_mismatch_check_v8
< U __ubsan_handle_dynamic_type_cache_miss
< U __ubsan_handle_pointer_overflow
< U __ubsan_handle_type_mismatch_v1
< U __ubsan_vptr_type_cache
> gcc -fsanitize=address,undefined -o b b.c -L. -lz -fuse-ld=bfd
< (No error, no warning)
> LD_LIBRARY_PATH=. ./b
< a 1
> gcc -fsanitize=address,undefined -o b b.c -L. -lz -fuse-ld=gold
< (No error, no warning)
> LD_LIBRARY_PATH=. ./b
< a 1
> gcc -fsanitize=address,undefined -o b b.c -L. -lz -fuse-ld=lld
< (No error, no warning)
> LD_LIBRARY_PATH=. ./b
< a 1
• Why does clang+ld.bfd produce an error when using ubsan with class
conversions?
• Why do I have to add in clang+ld.bfd -lubsan to get rid of the warning?
• Why does clang+ld.bfd does not produce an error when ubsan does no class
conversions?
• Why does clang+ld.gold produce a warning?
Note that I have LLVMGold.so in /usr/local/lib, but not in
/usr/local/lib/bfd-plugins. It is therefore not used by the linker (and this
LLVMGold.so is for LLVM 8, as I forgot te complice LLVM 10 with the linker
plugin).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gold/25000] New: Document nuances between relocatable output and incremental link
https://sourceware.org/bugzilla/show_bug.cgi?id=25000 Bug ID: 25000 Summary: Document nuances between relocatable output and incremental link Product: binutils Version: 2.33 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: dilyan.palauzov at aegee dot org CC: ian at airs dot com Target Milestone: --- The ld.texi says: '-i' Perform an incremental link (same as option '-r'). '-r' '--relocatable' Generate relocatable output--i.e., generate an output file that can in turn serve as input to 'ld'. This is often called "partial linking". As a side effect, in environments that support standard Unix magic numbers, this option also sets the output file's magic number to 'OMAGIC'. If this option is not specified, an absolute file is produced. When linking C++ programs, this option _will not_ resolve references to constructors; to do that, use '-Ur'. When an input file does not have the same format as the output file, partial linking is only supported if that input file does not contain any relocations. Different output formats can have further restrictions; for example some 'a.out'-based formats do not support partial linking with input files in other formats at all. This option does the same thing as '-i'. So, incremental link, partial link, and relocatable output in ld.bfd are the same. ld.bfd --help confirms: -r, -i, --relocatable Generate relocatable output However, ld.gold --help says: -i Alias for -r -r, -relocatableGenerate relocatable output --incremental Do an incremental link if possible; otherwise, do a full link and prepare output for incremental linking In gold, relocatable output and incremental link are not the same. In particular “ld.gold -r” creates unconditionally relocatable output, while “ld.gold --incremental” does either incremental link or a full link. Please align the terms “incremental link” and “relocatable output” in ld.bfd and ld.gold and describe on "ld.gold --help" why is it possible to create unconditionally relocatable output, but incremental link is only sometimes possible. In particular, articulate on the difference between --incremental and -r. -- 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/24873] gcc -flto objects result in --start-group … --end-group failure to include --as-needed libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=24873 --- Comment #14 from dilyan.palauzov at aegee dot org --- I have removed https://mail.aegee.org/dpa/ld24873/ . -- 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/24873] gcc -flto objects result in --start-group … --end-group failure to include --as-needed libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=24873 --- Comment #8 from dilyan.palauzov at aegee dot org --- Why doesn’t LD -Y/--TRACE-SYMBOL provide useful information about the location of the symbol. Transient LTO files as result of -Y are not useful information. -- 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/24873] gcc -flto objects result in --start-group … --end-group failure to include --as-needed libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=24873 --- Comment #7 from dilyan.palauzov at aegee dot org --- With meson 0.48 and below, the configure phase terminates with Meson encountered an error in file meson.build, line 672, column 1: Native dependency 'check' not found With meson 0.49 the configure phase terminates properly and the link parameters contain double-lm withing start/end-group. With meson 0.51.1 the configure phase terminates properly and the link parameters contain a single -lm in the start/end-group. At https://mail.aegee.org/dpa/ld24873/ I have uploaded my build environment: / contains the source code, /build-0.51.1 contains the compiled and partially linked code, /build-0.51/LIBS contains the libraries, which are mentioned for the linking on the link line. Thus for link-line cc -o test-utils 'test-utils@exe/src_libinput-util.c.o' 'test-utils@exe/test_test-utils.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group libinput.so.10.13.0 liblibinput-util.a libquirks.a /usr/local/lib/libmtdev.so /usr/x86_64-linux-gnu/libudev.so /usr/local/lib/libevdev.so -lm -lrt /usr/local/lib/libwacom.so /usr/local/lib/libcheck.a -ldl /lib64/libsystemd.so -Wl,--end-group '-Wl,-rpath,$ORIGIN/:/usr/x86_64-linux-gnu' -Wl,-rpath-link,/src/wayland/libinput-1.13.4/build-0.51/ -Wl,-rpath-link,/usr/x86_64-linux-gnu The libraries included are libcheck.a, libevdev.so, libmtdev.so, libsystemd.so, libudev.so and libwacom.so. -- 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/24873] gcc -flto objects result in --start-group … --end-group failure to include --as-needed libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=24873 --- Comment #3 from dilyan.palauzov at aegee dot org --- Yes, LTO is involved, but the compiler does not get an explict -flto, so one of the linked libraries, compiled in the past and not contained in the tarball of libinput, uses LTO and the linker uses then LTO plugins. I confirm, that keeping the second -lm and removing the first -lm does link properly. For me is surprizing that the order within --start-group…--end-group does matter. I cannot derive this from the documantation. -- 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/24873] ld.bfd fails if -lm is included only once within --start-group … --end-group
https://sourceware.org/bugzilla/show_bug.cgi?id=24873 --- Comment #1 from dilyan.palauzov at aegee dot org --- As discussed at https://gitlab.freedesktop.org/libinput/libinput/issues/335 … -- 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/24873] New: ld.bfd fails if -lm is included only once within --start-group … --end-group
https://sourceware.org/bugzilla/show_bug.cgi?id=24873 Bug ID: 24873 Summary: ld.bfd fails if -lm is included only once within --start-group … --end-group Product: binutils Version: 2.33 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- With ld.bfd 2.32.51.20190802, as discussed at linking with LINK_ARGS = -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group libinput.so.10.13.0 liblibinput-util.a libquirks.a /usr/local/lib/libmtdev.so /usr/x86_64-linux-gnu/libudev.so /usr/local/lib/libevdev.so -lm -lrt /usr/local/lib/libwacom.so /usr/local/lib/libcheck.a -ldl -lm /lib64/libsystemd.so -Wl,--end-group '-Wl,-rpath,$$ORIGIN/:/usr/x86_64-linux-gnu' -Wl,-rpath-link,/src/wayland/libinput-1.13.4/build-0.49/:/usr/x86_64-linux-gnu thus with two -lm within --start-group … --end-group does work, while linking with LINK_ARGS = -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group libinput.so.10.13.0 liblibinput-util.a libquirks.a /usr/local/lib/libmtdev.so /usr/x86_64-linux-gnu/libudev.so /usr/local/lib/libevdev.so -lm -lrt /usr/local/lib/libwacom.so /usr/local/lib/libcheck.a -ldl /lib64/libsystemd.so -Wl,--end-group '-Wl,-rpath,$$ORIGIN/:/usr/x86_64-linux-gnu' -Wl,-rpath-link,/src/wayland/libinput-1.13.4/build-0.51/ -Wl,-rpath-link,/usr/x86_64-linux-gnu thus with one -lm within --start-group … --end-group, fails with ld.bfd, but works when I append to the line -fuse-ld=gold or -lm. My understanding for --start-group … --end-group is that this is a loop, which works in such a way, that there is no need to repeat things listed in the loop body. -- 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/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 --- Comment #5 from dilyan.palauzov at aegee dot org --- The descriptions of --no-undefined talks about regular object files, while --allow-shlib-undefined is about shared libraries as opposed to regular object files. -z undefs is about regular object files, both from executable and shared library. As for -z ..., the documentation of the other noX and X options is together, consider joining there the documentation for nodefs and defs. Honestly when linking I do not see why shall we talk about regular object files. Linking two object files, when the first file contains unresolved symbols and the second file defines that symbols, deserves no warning. The documentation of -z defs and --no-undefined says that the inverse is -z undefs, but the documentation of -z undefs says only -z defs is the inverse. Please clarify how --no-undefined and --allow-shlib-undefined are related: is the second complete subset of the former? Write down the behavior of ld.gold, when the specifics about ld.bfd are mentioned. What is a non-symbolic shared library? -- 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/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 --- Comment #2 from dilyan.palauzov at aegee dot org --- Both linkers use the same file for their documentation, ld.texi . Either the file shall describe how the linkers differ, or ld.gold shall provide its own documentation. -- 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/24613] New: ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 Bug ID: 24613 Summary: ld --help for -z defs and --no-undefined Product: binutils Version: 2.33 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- With ld.gold und ld.bfd 2.32.51.20190429, ld.gold --help prints: --no-undefined Report undefined symbols (even with --shared) -z defs Report undefined symbols (even with --shared) which means, that --no-undefined and -z defs is the same, as the description is the same. ld.bfd --help prints for the same --no-undefined Do not allow unresolved references in object files -z defs Report unresolved symbols in object files which suggests, that the two directives do different things. Please align the description of ld.bfd --help for “-z defs” and “--no-undefined” to be the same. -- 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/24440] binutils/wrstabs.c:1476:25: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
https://sourceware.org/bugzilla/show_bug.cgi?id=24440 dilyan.palauzov at aegee dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #2 from dilyan.palauzov at aegee dot org --- Moved to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90036 . -- 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/24440] New: binutils/wrstabs.c:1476:25: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
https://sourceware.org/bugzilla/show_bug.cgi?id=24440 Bug ID: 24440 Summary: binutils/wrstabs.c:1476:25: error: ‘%s’ directive argument is null [-Werror=format-overflow=] Product: binutils Version: 2.33 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- Compiling most recent binutils (git/master - commit b05971a652c35ed72d3c95290e18) with gcc 8.3.1 20190330fails with: make[4]: Entering directory '/root/binutils/binutils' gcc -DHAVE_CONFIG_H -I. -I/git/binutils-gdb/binutils -I. -I/git/binutils-gdb/binutils -I../bfd -I/git/binutils-gdb/binutils/.. /bfd -I/git/binutils-gdb/binutils/../include -DLOCALEDIR="\"/usr/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulat ion -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -O2 -pipe -g -MT wrstabs.o -MD -M P -MF .deps/wrstabs.Tpo -c -o wrstabs.o /git/binutils-gdb/binutils/wrstabs.c /git/binutils-gdb/binutils/wrstabs.c: In function ‘stab_start_class_type’: /git/binutils-gdb/binutils/wrstabs.c:1476:25: error: ‘%s’ directive argument is null [-Werror=format-overflow=] sprintf (vtable, "~%%%s", vstring); ^~ cc1: all warnings being treated as errors make[4]: *** [Makefile:1061: wrstabs.o] Error 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/24406] -Wl,--wrap= incompatible with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=24406 --- Comment #6 from dilyan.palauzov at aegee dot org --- Reported for gold at https://sourceware.org/bugzilla/show_bug.cgi?id=24415 . -- 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/24415] New: - -Wl,--wrap= incompatible with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=24415
Bug ID: 24415
Summary: - -Wl,--wrap= incompatible with -flto
Product: binutils
Version: 2.33 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: dilyan.palauzov at aegee dot org
CC: ian at airs dot com
Target Milestone: ---
This is t.c:
---
#include
#include
ssize_t __wrap_read(int fd, void *buffer, size_t count) {
printf("%s\n", (char*)buffer);
return fd + count;
}
int main() {
int i = read(1, "abc", 5);
printf("%i\n", i);
}
---
I have gcc 8.3.1 20190331, clang 8.0.0, lld 8.0.0, ld.bfd 2.32.51.20190401 with
the patch from https://sourceware.org/ml/binutils/2019-04/msg00011.html, and
ld.gold (GNU Binutils 2.32.51.20190319) 1.16.
This works (compiles and links):
clang t.c -Wl,--wrap=read -O3 -fuse-ld=lld -flto
clang t.c -Wl,--wrap=read -O2 -fuse-ld=lld -flto
clang t.c -Wl,--wrap=read -O1 -fuse-ld=lld -flto
clang t.c -Wl,--wrap=read -O1 -fuse-ld=bfd -flto
clang t.c -Wl,--wrap=read -O2 -fuse-ld=bfd -flto
clang t.c -Wl,--wrap=read -O3 -fuse-ld=bfd -flto
clang t.c -Wl,--wrap=read -O3 -fuse-ld=gold -flto
clang t.c -Wl,--wrap=read -O2 -fuse-ld=gold -flto
clang t.c -Wl,--wrap=read -O1 -fuse-ld=gold -flto
gcc t.c -Wl,--wrap=read -O3 -fuse-ld=bfd -flto
gcc t.c -Wl,--wrap=read -O2 -fuse-ld=bfd -flto
gcc t.c -Wl,--wrap=read -O1 -fuse-ld=bfd -flto
This does not work (does not link):
gcc t.c -Wl,--wrap=read -O1 -fuse-ld=gold -flto
gcc t.c -Wl,--wrap=read -O2 -fuse-ld=gold -flto
gcc t.c -Wl,--wrap=read -O3 -fuse-ld=gold -flto
Bug for ld.bfd:
https://sourceware.org/bugzilla/show_bug.cgi?id=24406
Bug for GCC:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643 (origin)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89930 (duplicate)
--
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/24406] -Wl,--wrap= incompatible with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=24406 --- Comment #5 from dilyan.palauzov at aegee dot org --- With the patch applied this works: clang -flto -fuse-ld=bfd -Wl,--wrap=read -O3 t.c gcc -flto -fuse-ld=bfd -Wl,--wrap=read -O3 t.c gcc -flto -fuse-ld=bfd -Wl,--wrap=read -O2 t.c gcc -flto -fuse-ld=bfd -Wl,--wrap=read -O1 t.c This does not work: gcc -flto -fuse-ld=gold -Wl,--wrap=read -O3 t.c gcc -flto -fuse-ld=gold -Wl,--wrap=read -O2 t.c gcc -flto -fuse-ld=gold -Wl,--wrap=read -O1 t.c -- 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/24406] -Wl,--wrap= incompatible with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=24406 --- Comment #4 from dilyan.palauzov at aegee dot org --- With the patch applied “clang -flto -fuse-ld=bfd -Wl,--wrap=read t.c” does work. -- 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/24406] -Wl,--wrap= incompatible with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=24406 --- Comment #2 from dilyan.palauzov at aegee dot org --- This works: clang -flto -fuse-ld=lld -Wl,--wrap=read t.c with ld.LLD 8.0.0. -- 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/24406] -Wl,--wrap= incompatible with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=24406 --- Comment #1 from dilyan.palauzov at aegee dot org --- Reported the same at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89930 for GCC with the note “since clang+gold works, gcc+gold should also work.” -- 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/24406] New: -Wl,--wrap= incompatible with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=24406
Bug ID: 24406
Summary: -Wl,--wrap= incompatible with -flto
Product: binutils
Version: 2.32
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
This is t.c:
#include
#include
ssize_t __wrap_read(int fd, void *buffer, size_t count) {
printf("%s\n", (char*)buffer);
return fd + count;
}
int main() {
int i = read(1, "abc", 5);
printf("%i\n", i);
}
I have gcc 8.3.1 20190311, ld.bfd 2.32.51.20190319, ld.gold 1.16
2.32.51.20190319 and clang 8.0.0.
This works
clang -flto -fuse-ld=gold -Wl,--wrap=read t.c
gcc -fuse-ld=bfd -Wl,--wrap=read t.c
gcc -fuse-ld=gold -Wl,--wrap=read t.c
clang -fuse-ld=bfd -Wl,--wrap=read t.c
clang -fuse-ld=gold -Wl,--wrap=read t.c
This fails
clang -flto -fuse-ld=bfd -Wl,--wrap=read t.c
gcc -flto -fuse-ld=gold -Wl,--wrap=read t.c
gcc -flto -fuse-ld=bfd -Wl,--wrap=read t.c
--
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/21420] Compiling emacs 25.2 with ld.bdf fails (segmentation fault)
https://sourceware.org/bugzilla/show_bug.cgi?id=21420 dilyan.palauzov at aegee dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |OBSOLETE --- Comment #5 from dilyan.palauzov at aegee dot org --- With emacs 26.1, gcc (8.2.1 or 7.4.1) and most recent linkers, this does not seem to be anymore the case. In particular, the stripped binaries produced by ld.bfd ane smaller: With gcc 7.4.1 20181222 and linkers 2.31.51.20190103: 39536744bytes build-bfd/src/emacs 5394936bytes build-bfd/src/temacs 39545000bytes build-gold/src/emacs 5403192bytes build-gold/src/temacs With gcc 8.2.1 20190101 and linkers 2.31.51.20190103: 40253520bytes build-bfd/src/emacs 6100896bytes build-bfd/src/temacs 40265872bytes build-gold/src/emacs 6113248bytes build-gold/src/temacs -- 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/23812] Explicitly mentioned libraries by -lx are not in the DT_NEEDED list
https://sourceware.org/bugzilla/show_bug.cgi?id=23812 --- Comment #6 from dilyan.palauzov at aegee dot org --- While ld.bfd ≠ ld.gold, ld.bfd has a manual, that in applicable to ld.gold . However --debug is not in the manual of ld.bfd. Please write a manual of ld.gold, that describes what is different from ld.bfd. -- 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/23812] Explicitly mentioned libraries by -lx are not in the DT_NEEDED list
https://sourceware.org/bugzilla/show_bug.cgi?id=23812 dilyan.palauzov at aegee dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from dilyan.palauzov at aegee dot org --- Alright, I managed to fix it. It wasn’t LTO’s fault. Rather the distribution put files from libc on locations, where libc’s “make install” does not overwrite, so at the end the linker loaded files from old distribution’s linker files… and it loaded libBrokenLocale.a, as I have manually removed only the .so files. It is very hard to replace libc coming from a distribution with a self-compiled one. -- 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/23812] Explicitly mentioned libraries by -lx are not in the DT_NEEDED list
https://sourceware.org/bugzilla/show_bug.cgi?id=23812 --- Comment #2 from dilyan.palauzov at aegee dot org --- gcc /src/glibc228/test-prg7044.c -v -fuse-ld=gold -Wl,-t -Wl,--no-as-needed -lc -lBrokenLocale -lpthread -lcrypt -ldl -lgcc_s -lnsl - lutil -lnss_dns -lnss_compat -lmvec -lresolv -lnss_db -lm -lnss_files -lrt -lnss_hesiod -lanl -o /src/glibc228/test-prg7044 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../configure --enable-threads=posix --enable-nls --disable-multilib --enable-interpreter --with-system-zlib --enable-libgcj-multifile --enable-languages=all --enable-targets=all --with-system-unwind --without-x --with-linker-hash-style=gnu --enable-shared --with-build-config='bootstrap-lto bootstrap-O3' Thread model: posix gcc version 7.3.1 20181013 (GCC) COLLECT_GCC_OPTIONS='-v' '-fuse-ld=gold' '-o' '/src/glibc228/test-prg7044' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/cc1 -quiet -v -imultiarch x86_64-linux-gnu /src/glibc228/test-prg7044.c -quiet -dumpbase test-prg7044.c -mtune=generic -march=x86-64 -auxbase test-prg7044 -version -fuse-ld=gold -o /tmp/ccIyVftj.s GNU C11 (GCC) version 7.3.1 20181013 (x86_64-pc-linux-gnu) compiled by GNU C version 7.3.1 20181013, GMP version 6.1.2, MPFR version 4.0.0, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include /usr/local/include /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C11 (GCC) version 7.3.1 20181013 (x86_64-pc-linux-gnu) compiled by GNU C version 7.3.1 20181013, GMP version 6.1.2, MPFR version 4.0.0, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 8ff192ae53ef780b032a40b890e7c233 COLLECT_GCC_OPTIONS='-v' '-fuse-ld=gold' '-o' '/src/glibc228/test-prg7044' '-mtune=generic' '-march=x86-64' /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/bin/as -v --64 -o /tmp/cceyuoHT.o /tmp/ccIyVftj.s GNU assembler version 2.31.51 (x86_64-pc-linux-gnu) using BFD version (GNU Binutils) 2.31.51.20181019 COMPILER_PATH=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/libexec/gcc/x86_64-pc-linux-gnu/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/bin/ LIBRARY_PATH=/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../x86_64-linux-gnu/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/lib/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-fuse-ld=gold' '-o' '/src/glibc228/test-prg7044' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/collect2 -plugin /usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so -plugin-opt=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper -plugin-opt=-fresolution=/tmp/ccwBxCWt.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -fuse-ld=gold -o /src/glibc228/test-prg7044 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/crtbegin.o -L/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1 -L/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../x86_64-linux-gnu -L/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/lib -L/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../.. /tmp/cceyuoHT.o -t --no-as-needed -lc -lBrokenLocale -lpthread -lcrypt -ldl -lgcc_s -lnsl -lutil -lnss_dns -lnss_compat -lmvec -lresolv -lnss_db -lm -lnss_files -lrt -lnss_hesiod -lanl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/crtend.o /usr/lib/../lib64/crtn.o /usr/lib/../lib64/crt1.o /usr/lib/../li
[Bug ld/23811] New: Explicitly mentioned libraries by -lx are not in the DT_NEEDED list
https://sourceware.org/bugzilla/show_bug.cgi?id=23811
Bug ID: 23811
Summary: Explicitly mentioned libraries by -lx are not in the
DT_NEEDED list
Product: binutils
Version: 2.32 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
With binutils 2.31.51.20181019, for a program
#include
#include
int main(void) {
printf ("Your new glibc installation seems to be ok.\n");
exit (0);
}
calling “gcc /src/glibc228/input-file.c -lc -lBrokenLocale -lpthread -lcrypt
-ldl -lgcc_s -lnsl -lutil -lnss_dns -lnss_compat -lmvec -lresolv -lnss_db -lm
-lnss_files -lrt -lnss_hesiod -lanl -o /src/glibc228/output-file” does not put
BrokenLocale in the output of ldd.
According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87710 this is not a
gcc bug. With clang 6 the problem also appears, as with using gold or adding
-Wl,--no-as-needed.
See https://sourceware.org/bugzilla/show_bug.cgi?id=23807 for details.
--
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/23812] New: Explicitly mentioned libraries by -lx are not in the DT_NEEDED list
https://sourceware.org/bugzilla/show_bug.cgi?id=23812
Bug ID: 23812
Summary: Explicitly mentioned libraries by -lx are not in the
DT_NEEDED list
Product: binutils
Version: 2.32 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: dilyan.palauzov at aegee dot org
CC: ian at airs dot com
Target Milestone: ---
With binutils 2.31.51.20181019, for a program
#include
#include
int main(void) {
printf ("Your new glibc installation seems to be ok.\n");
exit (0);
}
calling “gcc /src/glibc228/input-file.c -fuse-ld=gold -lc -lBrokenLocale
-lpthread -lcrypt -ldl -lgcc_s -lnsl -lutil -lnss_dns -lnss_compat -lmvec
-lresolv -lnss_db -lm -lnss_files -lrt -lnss_hesiod -lanl -o
/src/glibc228/output-file” does not put BrokenLocale in the output of ldd.
According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87710 this is not a
gcc bug. With clang 6 the problem also appears, as with using ld.bfd or adding
-Wl,--no-as-needed.
See https://sourceware.org/bugzilla/show_bug.cgi?id=23807 for details.
https://sourceware.org/bugzilla/show_bug.cgi?id=23811 is the same bug report,
but for ld.bfd.
--
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/23413] Builing gcc --with-build-config=bootstrap-lto\ bootstrap-O3 and gold fails
https://sourceware.org/bugzilla/show_bug.cgi?id=23413 --- Comment #5 from dilyan.palauzov at aegee dot org --- Please align the default settings of ld.gold to match those of ld.bfd. The defaults of ld.gold and ld.bdf in this regard (defaults for -L) shall be the same, except there are complelling reasons and it is insisted, that the defaults are different. Having different defaults leads to linkers which are not interchangable and to lost time for the users, which is not in the common interest. -- 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/23413] Builing gcc --with-build-config=bootstrap-lto\ bootstrap-O3 and gold fails
https://sourceware.org/bugzilla/show_bug.cgi?id=23413 --- Comment #3 from dilyan.palauzov at aegee dot org --- I have libisl and libmpc only in /usr/local/lib, libgmp in /usr/local/lib and /usr/lib/x86_64-linux-gnu , and libz in /usr/local/lib and /lib/x86_64-linux-gnu. -- 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/23413] Builing gcc --with-build-config=bootstrap-lto\ bootstrap-O3 and gold fails
https://sourceware.org/bugzilla/show_bug.cgi?id=23413 --- Comment #2 from dilyan.palauzov at aegee dot org --- In fact I have libisl, libmpc -- 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/23413] Builing gcc --with-build-config=bootstrap-lto\ bootstrap-O3 and gold fails
https://sourceware.org/bugzilla/show_bug.cgi?id=23413 --- Comment #1 from dilyan.palauzov at aegee dot org --- binutils is linked with export CONFIG_SITE="a" export CFLAGS="-O3 -pipe" export CXXFLAGS="-O3 -pipe" export LDFLAGS="-Wl,-O1,-s -fuse-ld=gold" /git/binutils-gdb/configure --enable-threads --with-system-zlib --with-system-readline --with-python=/usr/local/bin/python3 --enable-compressed-debug-sections=gold,ld --enable-gold=default make -j2 && make install && make distclean && rm -rf b* e* g* i* l* o* r* sim Why gold says /usr/local/x86_64-pc-linux-gnu/bin/ld: error: cannot find -lisl /usr/local/x86_64-pc-linux-gnu/bin/ld: error: cannot find -lmpc /usr/local/x86_64-pc-linux-gnu/bin/ld: error: cannot find -lmpfr /usr/local/x86_64-pc-linux-gnu/bin/ld: error: cannot find -lgmp /usr/local/x86_64-pc-linux-gnu/bin/ld: error: cannot find -lz but ld.bfd continues despite this, I cannot say. -- 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/23413] New: Builing gcc --with-build-config=bootstrap-lto\ bootstrap-O3 and gold fails
https://sourceware.org/bugzilla/show_bug.cgi?id=23413 Bug ID: 23413 Summary: Builing gcc --with-build-config=bootstrap-lto\ bootstrap-O3 and gold fails Product: binutils Version: 2.32 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: dilyan.palauzov at aegee dot org CC: ian at airs dot com Target Milestone: --- Created attachment 11128 --> https://sourceware.org/bugzilla/attachment.cgi?id=11128=edit Output of make when gold is the default linker while building gcc 7.3 Building gcc-7.3.1+ (88621ae81401f55d7a8c2c7ce1d6bf2b8d91ce1e) with export CONFIG_SITE="a" gcc.git/configure --enable-threads=posix --enable-nls --disable-multilib --enable-interpreter --with-system-zlib --enable-libgcj-multifile --enable-languages=all --enable-targets=all --with-system-unwind --without-x --with-linker-hash-style=gnu --enable-shared --with-build-config=bootstrap-lto\ bootstrap-O3 && make and having as default linker GNU gold (GNU Binutils 2.31.51.20180711) 1.16 fails at stage 2 with the attached text. With GNU ld (GNU Binutils) 2.31.51.20180711 as default linker the build continues beyond this step (enters stage 3 and I have not waited until the build ends). -- 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/23385] Clarify defaults on ld --help
https://sourceware.org/bugzilla/show_bug.cgi?id=23385 --- Comment #3 from dilyan.palauzov at aegee dot org --- And this: --eh-frame-hdr Create .eh_frame_hdr section --no-eh-frame-hdr Do not create .eh_frame_hdr section -- 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/23385] Clarify defaults on ld --help
https://sourceware.org/bugzilla/show_bug.cgi?id=23385 --- Comment #2 from dilyan.palauzov at aegee dot org --- Here too clary the defaults for mutually exclusing options: --accept-unknown-input-arch Accept input files whose architecture cannot be determined --no-accept-unknown-input-arch Reject input files whose architecture is unknown --as-needed Only set DT_NEEDED for following dynamic libs if used --no-as-needed Always set DT_NEEDED for dynamic libraries mentioned on the command line --copy-dt-needed-entriesCopy DT_NEEDED links mentioned inside DSOs that follow --no-copy-dt-needed-entries Do not copy DT_NEEDED links mentioned inside DSOs that follow --print-gc-sections List removed unused sections on stderr --no-print-gc-sections Do not list removed unused sections --allow-shlib-undefined Allow unresolved references in shared libraries --no-allow-shlib-undefined Do not allow unresolved references in shared libs --relax Reduce code size by using target specific optimizations --no-relax Do not use relaxation techniques to reduce code size -- 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/23386] New: Clarify defaults on gold --help
https://sourceware.org/bugzilla/show_bug.cgi?id=23386 Bug ID: 23386 Summary: Clarify defaults on gold --help Product: binutils Version: 2.32 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: dilyan.palauzov at aegee dot org CC: ian at airs dot com Target Milestone: --- gold --help prints: --hash-style [sysv,gnu,both] Dynamic hash style -> write what the default is --strip-debug-gdb Strip debug symbols that are unused by gdb (at least versions <= 7.4) -> Update this for newer gdb version -x, --discard-all Delete all local symbols -X, --discard-localsDelete all temporary local symbols --discard-none Keep all local symbols Compare here the output of ld.bfd --help: -x, --discard-all Discard all local symbols -X, --discard-localsDiscard temporary local symbols (default) --discard-none Don't discard any local symbols So for ld.bfd -X is the default, clarify what is the default for ld.gold --compress-debug-sections [none,zlib,zlib-gnu,zlib-gabi] Compress .debug_* sections in the output file -> Write what the default is. -- 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/23385] Clarify defaults on ld --help
https://sourceware.org/bugzilla/show_bug.cgi?id=23385 --- Comment #1 from dilyan.palauzov at aegee dot org --- Also for --hash-style state what is the default. -- 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/23385] New: Clarify defaults on ld --help
https://sourceware.org/bugzilla/show_bug.cgi?id=23385 Bug ID: 23385 Summary: Clarify defaults on ld --help Product: binutils Version: 2.32 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- ld --help prints: -z execstackMark executable as requiring executable stack -z noexecstack Mark executable as not requiring executable stack -z combrelocMerge dynamic relocs into one section and sort -z nocombreloc Don't merge dynamic relocs into one section -z common Generate common symbols with STT_COMMON type -z nocommon Generate common symbols with STT_OBJECT type -z text Treat DT_TEXTREL in shared object as error -z notext Don't treat DT_TEXTREL in shared object as error -z textoff Don't treat DT_TEXTREL in shared object as error -z dynamic-undefined-weak Make undefined weak symbols dynamic -z nodynamic-undefined-weak Do not make undefined weak symbols dynamic Write in brackets what is the default of the mutually exclusive options, as this is done for -z relro, -X, --(no-)gc-sections. -- 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/23358] New: ld --help|grep separate-code -- clarify default
https://sourceware.org/bugzilla/show_bug.cgi?id=23358 Bug ID: 23358 Summary: ld --help|grep separate-code -- clarify default Product: binutils Version: 2.32 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- $(ld.bfd --help|grep sepa) shows: -z separate-codeCreate separate code program header -z noseparate-code Don't create separate code program header (default) On x86_64 ./configure implies --enable-separate-code and "-z separate-code" is the default. Update lexsup.c to honour DEFAULT_LD_Z_SEPARATE_CODE or alike when printing "default" for (no)seprate-code on $(ld --help). -- 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/23357] LD debug info cannot be read by valgrind
https://sourceware.org/bugzilla/show_bug.cgi?id=23357 --- Comment #4 from dilyan.palauzov at aegee dot org --- Relevant for valgrind is: commit f6aec96dce1ddbd8961a3aa8a2925db2021719bb (HEAD) Author: H.J. Lu Date: Tue Feb 27 11:34:20 2018 -0800 ld: Add --enable-separate-code This patch adds --enable-separate-code to ld configure to turn on -z separate-code by default and enables it by default for Linux/x86. This avoids mixing code pages with data to improve cache performance as well as security. To reduce x86-64 executable and shared object sizes, the maximum page size is reduced from 2MB to 4KB when -z separate-code is turned on by default. Note: -z max-page-size= can be used to set the maximum page size. We compared SPEC CPU 2017 performance before and after this change on Skylake server. There are no any significant performance changes. Everything is mostly below +/-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/23357] LD debug info cannot be read by valgrind
https://sourceware.org/bugzilla/show_bug.cgi?id=23357 --- Comment #3 from dilyan.palauzov at aegee dot org --- Created attachment 3 --> https://sourceware.org/bugzilla/attachment.cgi?id=3=edit Binary created with ld 2.30 -- 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/23357] LD debug info cannot be read by valgrind
https://sourceware.org/bugzilla/show_bug.cgi?id=23357 --- Comment #2 from dilyan.palauzov at aegee dot org --- Created attachment 2 --> https://sourceware.org/bugzilla/attachment.cgi?id=2=edit Binary created with ld 2.31.51.20180630 -- 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/23357] LD debug info cannot be read by valgrind
https://sourceware.org/bugzilla/show_bug.cgi?id=23357 --- Comment #1 from dilyan.palauzov at aegee dot org --- Created attachment 1 --> https://sourceware.org/bugzilla/attachment.cgi?id=1=edit Binary linked with gold -- 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/23357] New: LD debug info cannot be read by valgrind
https://sourceware.org/bugzilla/show_bug.cgi?id=23357
Bug ID: 23357
Summary: LD debug info cannot be read by valgrind
Product: binutils
Version: 2.32 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
Created attachment 0
--> https://sourceware.org/bugzilla/attachment.cgi?id=0=edit
The object file in the experiments.
I gcc (GCC) 7.3.1 20180629 compiled with
mkdir build && cd build && ../configure --enable-threads=posix --enable-nls
--disable-multilib --enable-interpreter --with-system-zlib
--enable-libgcj-multifile --enable-languages=all --enable-targets=all
--with-system-unwind --without-x --with-linker-hash-style=gnu --enable-shared
--with-build-config=bootstrap-lto\ bootstrap-O3 && make install
binutils 2.31.51.20180630 compiled with
/git/binutils-gdb/configure --enable-threads --with-system-zlib
--with-system-readline --with-python=/usr/local/bin/python3
--enable-compressed-debug-sections=gold,ld --enable-gold
and this file:
#include
int main() {
printf("a\n");
int i = 7 /0;
printf("b\n");
return 0;
}
which I compile with 'gcc -g -c -o t.o t.c'.
Then I link the file with bfd and gold separately:
gcc -fuse-ld=gold -o t-gold t.o
gcc -fuse-ld=bfd -o t-bfd t.o
t.o, t-gold and t-bfd are uploaded.
Running under gdb shows for both t-binaries cases troubles in t.c:5.
I have valgrind-3.14.0.GIT-f008d35bb3-20180629X.
"valgrind ./t-gold" shows:
Process terminating with default action of signal 8 (SIGFPE)
Integer divide by zero at address 0x100905BADE
at 0x400579: main (t.c:5)
but "valgrind ./t-bfd" prints:
Process terminating with default action of signal 8 (SIGFPE)
Integer divide by zero at address 0x1008F5BADE
at 0x401149: ??? (in /root/T/t-bfd)
by 0x4A44B44: (below main) (libc-start.c:287)
Installing a ld 2.30 under /usr/local/x86_64-pc-linux-gnu/bin/ld.bfd, doing
'gcc -fuse-ld=bfd -o t-bfd2.30 t.o' and then 'valgrind ./t-bfd2.30' prints
Process terminating with default action of signal 8 (SIGFPE)
Integer divide by zero at address 0x100905FADE
at 0x4004F9: main (t.c:5)
This means that valgrind cannot read debug information when most current ld is
used, but can read the information when gold or ld 2.30 are used. The fact
that gdb can read the information in all cases does not prove that the problem
is in valgrind, it could be also in the common libbdf.
Please verify that the debug information generated by ld is correct and help at
https://bugs.kde.org/show_bug.cgi?id=395682 to find what the problem with
valgrind is.
--
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/22823] bfd/libbfd.h:268:4: error: cast between incompatible function types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to ‘bfd_boolean (*)(bfd *, bfd *)’ {aka ‘int (*)(st
https://sourceware.org/bugzilla/show_bug.cgi?id=22823
--- Comment #3 from dilyan.palauzov at aegee dot org ---
This shifts the errors few lines further:
make[4]: Entering directory '/home/d/binutils/bfd'
/bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I/git/binutils-gdb/bfd -I. -I/git/binutils-gdb/bfd
-I/git/binutils-gdb/bfd/../include -DHAVE_all_vecs
-DBINDIR='"/usr/local/bin"' -W -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wshadow -Wstack-usage=262144 -Werror -O3 -pipe -MT binary.lo -MD -MP -MF
.deps/binary.Tpo -c -o binary.lo /git/binutils-gdb/bfd/binary.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/git/binutils-gdb/bfd -I.
-I/git/binutils-gdb/bfd -I/git/binutils-gdb/bfd/../include -DHAVE_all_vecs
-DBINDIR=\"/usr/local/bin\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wshadow -Wstack-usage=262144 -Werror -O3 -pipe -MT binary.lo -MD -MP -MF
.deps/binary.Tpo -c /git/binutils-gdb/bfd/binary.c -o binary.o
In file included from /git/binutils-gdb/bfd/binary.c:38:
/git/binutils-gdb/bfd/libbfd.h:305:4: error: cast between incompatible function
types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to
‘bfd_boolean (*)(bfd *, char **, bfd_size_type *, const char **)’ {aka ‘int
(*)(struct bfd *, char **, long unsigned int *, const char **)’}
[-Werror=cast-function-type]
((bfd_boolean (*) (bfd *, char **, bfd_size_type *, const char **)) \
^
./bfd.h:7519:3: note: in expansion of macro
‘_bfd_noarchive_construct_extended_name_table’
NAME##_construct_extended_name_table, \
^~~~
/git/binutils-gdb/bfd/binary.c:364:3: note: in expansion of macro
‘BFD_JUMP_TABLE_ARCHIVE’
BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
^~
/git/binutils-gdb/bfd/libbfd.h:308:4: error: cast between incompatible function
types from ‘void (*)(bfd *)’ {aka ‘void (*)(struct bfd *)’} to ‘void (*)(bfd *,
const char *, char *)’ {aka ‘void (*)(struct bfd *, const char *, char *)’}
[-Werror=cast-function-type]
((void (*) (bfd *, const char *, char *)) bfd_void)
^
./bfd.h:7520:3: note: in expansion of macro ‘_bfd_noarchive_truncate_arname’
NAME##_truncate_arname, \
^~~~
/git/binutils-gdb/bfd/binary.c:364:3: note: in expansion of macro
‘BFD_JUMP_TABLE_ARCHIVE’
BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
^~
/git/binutils-gdb/bfd/libbfd.h:310:4: error: cast between incompatible function
types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to
‘bfd_boolean (*)(bfd *, unsigned int, struct orl *, unsigned int, int)’ {aka
‘int (*)(struct bfd *, unsigned int, struct orl *, unsigned int, int)’}
[-Werror=cast-function-type]
((bfd_boolean (*) (bfd *, unsigned int, struct orl *, unsigned int, int)) \
^
./bfd.h:7521:3: note: in expansion of macro ‘_bfd_noarchive_write_armap’
NAME##_write_armap, \
^~~~
/git/binutils-gdb/bfd/binary.c:364:3: note: in expansion of macro
‘BFD_JUMP_TABLE_ARCHIVE’
BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
^~
/git/binutils-gdb/bfd/libbfd.h:314:4: error: cast between incompatible function
types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to
‘bfd_boolean (*)(bfd *, bfd *)’ {aka ‘int (*)(struct bfd *, struct bfd *)’}
[-Werror=cast-function-type]
((bfd_boolean (*) (bfd *, bfd *)) bfd_false)
^
./bfd.h:7523:3: note: in expansion of macro ‘_bfd_noarchive_write_ar_hdr’
NAME##_write_ar_hdr, \
^~~~
/git/binutils-gdb/bfd/binary.c:364:3: note: in expansion of macro
‘BFD_JUMP_TABLE_ARCHIVE’
BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
^~
/git/binutils-gdb/bfd/libbfd.h:316:4: error: cast between incompatible function
types from ‘void * (*)(bfd *)’ {aka ‘void * (*)(struct bfd *)’} to ‘bfd *
(*)(bfd *, bfd *)’ {aka ‘struct bfd * (*)(struct bfd *, struct bfd *)’}
[-Werror=cast-function-type]
((bfd *(*) (bfd *, bfd *)) bfd_nullvoidptr)
^
./bfd.h:7524:3: note: in expansion of macro
‘_bfd_noarchive_openr_next_archived_file’
NAME##_openr_next_archived_file, \
^~~~
/git/binutils-gdb/bfd/binary.c:364:3: note: in expansion of macro
‘BFD_JUMP_TABLE_ARCHIVE’
BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
^~
/git/binutils-gdb/bfd/libbfd.h:318:4: error: cast between incompatible function
types from ‘void * (*)(bfd *)’ {aka ‘void * (*)(struct bfd *)’} to ‘bfd *
(*)(bfd *, symindex)’ {aka ‘struct bfd * (*)(struct bfd *, long unsigned int)’}
[-Werror=cast-function-type]
((bfd *(*) (bfd *, symindex)) bfd_nullvoidptr)
^
./bfd.h:7525:3: note: in expansion of macro ‘_bfd_noarchive_get_elt_at_index’
NAME##_get_elt_at_index, \
^~~~
/git/binutils-gdb/bfd/binary.c:364:3: note: in expansion of macro
‘BFD_JUMP_TABLE_ARCHIVE’
BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
^~
/git/binutils-gdb/bfd/libbfd.h:417:4: error: cast between incompatible function
types from ‘void (*)(bfd *)’ {aka ‘void (*)(struct bfd *)’} to ‘void (*)(bfd *,
void *, asymbol *, bfd_print_symb
[Bug binutils/22823] New: bfd/libbfd.h:268:4: error: cast between incompatible function types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to ‘bfd_boolean (*)(bfd *, bfd *)’ {aka ‘int (
https://sourceware.org/bugzilla/show_bug.cgi?id=22823
Bug ID: 22823
Summary: bfd/libbfd.h:268:4: error: cast between incompatible
function types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int
(*)(struct bfd *)’} to ‘bfd_boolean (*)(bfd *, bfd *)’
{aka ‘int (*)(struct bfd *, struct bfd *)’}
Product: binutils
Version: 2.31 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
Most recent gcc 8.0.1 20180209 does not compile most recent binutils
(15b23f3612ffa19b):
make[4]: Entering directory '/home/d/binutils/bfd'
/bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I/git/binutils-gdb/bfd -I. -I/git/binutils-gdb/bfd
-I/git/binutils-gdb/bfd/../include -DHAVE_all_vecs
-DBINDIR='"/usr/local/bin"' -W -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wshadow -Wstack-usage=262144 -Werror -O3 -pipe -MT binary.lo -MD -MP -MF
.deps/binary.Tpo -c -o binary.lo /git/binutils-gdb/bfd/binary.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/git/binutils-gdb/bfd -I.
-I/git/binutils-gdb/bfd -I/git/binutils-gdb/bfd/../include -DHAVE_all_vecs
-DBINDIR=\"/usr/local/bin\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wshadow -Wstack-usage=262144 -Werror -O3 -pipe -MT binary.lo -MD -MP -MF
.deps/binary.Tpo -c /git/binutils-gdb/bfd/binary.c -o binary.o
In file included from /git/binutils-gdb/bfd/binary.c:38:
/git/binutils-gdb/bfd/libbfd.h:268:4: error: cast between incompatible function
types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to
‘bfd_boolean (*)(bfd *, bfd *)’ {aka ‘int (*)(struct bfd *, struct bfd *)’}
[-Werror=cast-function-type]
((bfd_boolean (*) (bfd *, bfd *)) bfd_true)
^
./bfd.h:7463:3: note: in expansion of macro
‘_bfd_generic_bfd_copy_private_bfd_data’
NAME##_bfd_copy_private_bfd_data, \
^~~~
/git/binutils-gdb/bfd/binary.c:362:3: note: in expansion of macro
‘BFD_JUMP_TABLE_COPY’
BFD_JUMP_TABLE_COPY (_bfd_generic),
^~~
/git/binutils-gdb/bfd/libbfd.h:270:4: error: cast between incompatible function
types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to
‘bfd_boolean (*)(bfd *, struct bfd_link_info *)’ {aka ‘int (*)(struct bfd *,
struct bfd_link_info *)’} [-Werror=cast-function-type]
((bfd_boolean (*) (bfd *, struct bfd_link_info *)) bfd_true)
^
./bfd.h:7464:3: note: in expansion of macro
‘_bfd_generic_bfd_merge_private_bfd_data’
NAME##_bfd_merge_private_bfd_data, \
^~~~
/git/binutils-gdb/bfd/binary.c:362:3: note: in expansion of macro
‘BFD_JUMP_TABLE_COPY’
BFD_JUMP_TABLE_COPY (_bfd_generic),
^~~
/git/binutils-gdb/bfd/libbfd.h:274:4: error: cast between incompatible function
types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to
‘bfd_boolean (*)(bfd *, asection *, bfd *, asection *)’ {aka ‘int (*)(struct
bfd *, struct bfd_section *, struct bfd *, struct bfd_section *)’}
[-Werror=cast-function-type]
((bfd_boolean (*) (bfd *, asection *, bfd *, asection *)) bfd_true)
^
./bfd.h:7466:3: note: in expansion of macro
‘_bfd_generic_bfd_copy_private_section_data’
NAME##_bfd_copy_private_section_data, \
^~~~
/git/binutils-gdb/bfd/binary.c:362:3: note: in expansion of macro
‘BFD_JUMP_TABLE_COPY’
BFD_JUMP_TABLE_COPY (_bfd_generic),
^~~
/git/binutils-gdb/bfd/libbfd.h:276:4: error: cast between incompatible function
types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to
‘bfd_boolean (*)(bfd *, asymbol *, bfd *, asymbol *)’ {aka ‘int (*)(struct bfd
*, struct bfd_symbol *, struct bfd *, struct bfd_symbol *)’}
[-Werror=cast-function-type]
((bfd_boolean (*) (bfd *, asymbol *, bfd *, asymbol *)) bfd_true)
^
./bfd.h:7467:3: note: in expansion of macro
‘_bfd_generic_bfd_copy_private_symbol_data’
NAME##_bfd_copy_private_symbol_data, \
^~~~
/git/binutils-gdb/bfd/binary.c:362:3: note: in expansion of macro
‘BFD_JUMP_TABLE_COPY’
BFD_JUMP_TABLE_COPY (_bfd_generic),
^~~
/git/binutils-gdb/bfd/libbfd.h:278:4: error: cast between incompatible function
types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to
‘bfd_boolean (*)(bfd *, bfd *)’ {aka ‘int (*)(struct bfd *, struct bfd *)’}
[-Werror=cast-function-type]
((bfd_boolean (*) (bfd *, bfd *)) bfd_true)
^
./bfd.h:7468:3: note: in expansion of macro
‘_bfd_generic_bfd_copy_private_header_data’
NAME##_bfd_copy_private_header_data, \
^~~~
/git/binutils-gdb/bfd/binary.c:362:3: note: in expansion of macro
‘BFD_JUMP_TABLE_COPY’
BFD_JUMP_TABLE_COPY (_bfd_generic),
^~~
/git/binutils-gdb/bfd/libbfd.h:272:4: error: cast between incompatible function
types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to
‘bfd_boolean
[Bug gas/22810] New: ld.bfd,gold,gas --help|grep compress
https://sourceware.org/bugzilla/show_bug.cgi?id=22810
Bug ID: 22810
Summary: ld.bfd,gold,gas --help|grep compress
Product: binutils
Version: 2.31 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
ld.bfd --help prints:
--compress-debug-sections=[none|zlib|zlib-gnu|zlib-gabi]
Compress DWARF debug sections using zlib
Default: zlib-gabi
ld.gold --help prints:
--compress-debug-sections [none,zlib,zlib-gnu,zlib-gabi]
Compress .debug_* sections in the output file
as --help prints:
--compress-debug-sections[={none|zlib|zlib-gnu|zlib-gabi}]
compress DWARF debug sections using zlib [default]
--nocompress-debug-sections
don't compress DWARF debug sections
Gold and gas shall print like ld.bfd, when compression is enabled by default,
which compression method is used, none being a compression method.
I think for ld.bfd things are tweaked ideally, so gold and as shall adopt this
form. Maybe the line "Default: zlib-gabi" can be replaced by a suffix "
[zlib-gabi]" on the previous line.
For as, provided that --compress-debug-sections=none is equivalent to
--no-compress-debug-sections, the latter could be hidden from the output of as
--help.
--
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/21423] ./configure --enable-plugins
https://sourceware.org/bugzilla/show_bug.cgi?id=21423 --- Comment #2 from dilyan.palauzov at aegee dot org --- Reported to gcc https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80514 -- 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/21420] Compiling emacs 25.2 with ld.bdf fails (segmentation fault)
https://sourceware.org/bugzilla/show_bug.cgi?id=21420 --- Comment #2 from dilyan.palauzov at aegee dot org --- (In reply to H.J. Lu from comment #1) > Did ld.bfd ever work with those options? I don't know. -- 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/21423] New: ./configure --enable-plugins
https://sourceware.org/bugzilla/show_bug.cgi?id=21423 Bug ID: 21423 Summary: ./configure --enable-plugins Product: binutils Version: 2.29 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- I read in config/plugins.m4 that -- plugins can be enabled only if either dlfcn.h or windows.h is present -- plugins are enabled, except --disable-plugins is provided Under these circumstances, where --enable-plugins is the default, ./configure -help shall print "disable-plugins" to show the use, what action she has to make, in order to enforce that option. This is the convention for reading ./configure --help, in order to understand what is the default, and for tweaking which features, an additional argument is necessary. This is unfortunately not the default behaviour of gold/configure , so running `binutils.git/configure` inconsistently disables plugin support in gold and enables plugin support in ld.bfd. Related to https://sourceware.org/bugzilla/show_bug.cgi?id=15599 and https://sourceware.org/bugzilla/show_bug.cgi?id=12402 . However, it is irrelevant, whether ld/configure.ac includes config/plugins.m4 . The fact that ./configure --help prints "--enable-plugins" means, that "--enable-plugins" has to be provided in order to enable plugins. I tried ./configure --disable-plugins and ld --plugin shows now "unrecognized option". -- 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/21382] New: --as-needed cannot be combined with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=21382 Bug ID: 21382 Summary: --as-needed cannot be combined with -flto Product: binutils Version: 2.29 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- Created attachment 9991 --> https://sourceware.org/bugzilla/attachment.cgi?id=9991=edit Sample With the attached package I do ./configure and make clean && make LDFLAGS="-Wl,--as-needed" && ./m -- works, prints x make clean && CFLAGS="-flto" make && ./m -- works, prints x make clean && make CFLAGS="-flto" LDFLAGS="-Wl,--as-needed" && ./m -- does not work, prints x-0.libs/lt-m: symbol lookup error: x-0/.libs/libx.so.0: undefined symbol: x Why doesn't --as-needed work with LTO? It happens when I use GNU ld (GNU Binutils) 2.28.51.20170411 with either GCC 7.0.1 20170411 or GCC 6.3.1 20170329. As of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80407 it is not gcc bug and does not happen with gold. -- 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/21096] gcc7 warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=21096 --- Comment #6 from dilyan.palauzov at aegee dot org --- The second patch eliminates all warnings. -- 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/21096] gcc7 warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=21096 --- Comment #4 from dilyan.palauzov at aegee dot org --- It works, but there is one more warning: make[4]: Entering directory '/home/d/binutils/opcodes' /bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/git/binutils-gdb/opcodes -I. -I/git/binutils-gdb/opcodes -I../bfd -I/git/binutils-gdb/opcodes/../include -I/git/binutils-gdb/opcodes/../bfd-W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -g -O2 -MT tic6x-dis.lo -MD -MP -MF .deps/tic6x-dis.Tpo -c -o tic6x-dis.lo /git/binutils-gdb/opcodes/tic6x-dis.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/git/binutils-gdb/opcodes -I. -I/git/binutils-gdb/opcodes -I../bfd -I/git/binutils-gdb/opcodes/../include -I/git/binutils-gdb/opcodes/../bfd -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -g -O2 -MT tic6x-dis.lo -MD -MP -MF .deps/tic6x-dis.Tpo -c /git/binutils-gdb/opcodes/tic6x-dis.c -o tic6x-dis.o /git/binutils-gdb/opcodes/tic6x-dis.c: In function ‘print_insn_tic6x’: /git/binutils-gdb/opcodes/tic6x-dis.c:706:32: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=] snprintf (func_unit_buf, 7, " .%c%u%s%s", func_unit_char, ^~~~ /git/binutils-gdb/opcodes/tic6x-dis.c:706:4: note: ‘snprintf’ output between 5 and 8 bytes into a destination of size 7 snprintf (func_unit_buf, 7, " .%c%u%s%s", func_unit_char, ^ func_unit_side, (func_unit_cross ? "X" : ""), data_str); ~~~ cc1: all warnings being treated as errors make[4]: *** [Makefile:1003: tic6x-dis.lo] Error 1 make[4]: Target 'all-am' not remade because of errors. -- 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/21096] New: gcc7 warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=21096 Bug ID: 21096 Summary: gcc7 warnings Product: binutils Version: 2.29 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- When I compile bingutils-gdb with gcc7 I get the following warnings: In file included from /git/binutils-gdb/bfd/coff-i386.c:614:0, from /git/binutils-gdb/bfd/pei-i386.c:45: /git/binutils-gdb/bfd/coffcode.h: In function ‘coff_write_object_contents’: /git/binutils-gdb/bfd/coffcode.h:3775:46: error: ‘%lu’ directive output may be truncated writing between 1 and 20 bytes into a region of size 8 [-Werror=format-truncation=] snprintf (s_name_buf, SCNNMLEN + 1, "/%lu", (unsigned long) string_size); ^~~ /git/binutils-gdb/bfd/coffcode.h:3775:44: note: directive argument in the range [4, 18446744073709551614] snprintf (s_name_buf, SCNNMLEN + 1, "/%lu", (unsigned long) string_size); ^~ /git/binutils-gdb/bfd/coffcode.h:3775:8: note: format output between 3 and 22 bytes into a destination of size 9 snprintf (s_name_buf, SCNNMLEN + 1, "/%lu", (unsigned long) string_size); ^~~~ cc1: all warnings being treated as errors make[2]: *** [Makefile:1688: pei-i386.lo] Error 1 /git/binutils-gdb/bfd/elf32-nds32.c: In function ‘nds32_elf_pick_relax’: /git/binutils-gdb/bfd/elf32-nds32.c:14976:27: error: ‘%08lx’ directive output may be truncated writing between 8 and 16 bytes into a region of size 9 [-Werror=format-truncation=] snprintf (code, 9, "%08lx", insn); ^ /git/binutils-gdb/bfd/elf32-nds32.c:14976:26: note: using the range [1, 18446744073709551615] for directive argument snprintf (code, 9, "%08lx", insn); ^~~ /git/binutils-gdb/bfd/elf32-nds32.c:14976:7: note: format output between 9 and 17 bytes into a destination of size 9 snprintf (code, 9, "%08lx", insn); ^ cc1: all warnings being treated as errors make[2]: *** [Makefile:1688: elf32-nds32.lo] Error 1 /git/binutils-gdb/opcodes/aarch64-opc.c: In function ‘print_register_offset_address’: /git/binutils-gdb/opcodes/aarch64-opc.c:2967:29: error: ‘%li’ directive output may be truncated writing between 1 and 20 bytes into a region of size 12 [-Werror=format-truncation=] snprintf (tb, sizeof (tb), ", %s #%" PRIi64, shift_name, ^ /git/binutils-gdb/opcodes/aarch64-opc.c:2967:36: note: format string is defined here snprintf (tb, sizeof (tb), ", %s #%" PRIi64, shift_name, /git/binutils-gdb/opcodes/aarch64-opc.c:2967:29: note: using the range [1, -9223372036854775808] for directive argument snprintf (tb, sizeof (tb), ", %s #%" PRIi64, shift_name, ^ /git/binutils-gdb/opcodes/aarch64-opc.c:2967:2: note: format output between 6 and 25 bytes into a destination of size 16 snprintf (tb, sizeof (tb), ", %s #%" PRIi64, shift_name, ^~~~ opnd->shifter.amount); ~ /git/binutils-gdb/opcodes/aarch64-opc.c: In function ‘print_register_list’: /git/binutils-gdb/opcodes/aarch64-opc.c:2868:22: error: ‘%li’ directive output may be truncated writing between 1 and 20 bytes into a region of size 7 [-Werror=format-truncation=] snprintf (tb, 8, "[%" PRIi64 "]", opnd->reglist.index); ^~~~ /git/binutils-gdb/opcodes/aarch64-opc.c:2868:24: note: format string is defined here snprintf (tb, 8, "[%" PRIi64 "]", opnd->reglist.index); /git/binutils-gdb/opcodes/aarch64-opc.c:2868:22: note: using the range [1, -9223372036854775808] for directive argument snprintf (tb, 8, "[%" PRIi64 "]", opnd->reglist.index); ^~~~ /git/binutils-gdb/opcodes/aarch64-opc.c:2868:5: note: format output between 4 and 23 bytes into a destination of size 8 snprintf (tb, 8, "[%" PRIi64 "]", opnd->reglist.index); ^~ cc1: all warnings being treated as errors make[2]: *** [Makefile:1003: aarch64-opc.lo] Error 1 make[1]: *** [Makefile:1046: all-recursive] Error 1 make: *** [Makefile:693: all] Error 2 -- 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/21034] New: binutils/stabs.c:2705: if (**pp == '; ' || *pp == '\0')
https://sourceware.org/bugzilla/show_bug.cgi?id=21034 Bug ID: 21034 Summary: binutils/stabs.c:2705: if (**pp == ';' || *pp == '\0') Product: binutils Version: 2.29 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- I think gcc 7 is right here: gcc -DHAVE_CONFIG_H -I. -I/git/binutils-gdb/binutils -I. -I/git/binutils-gdb/binutils -I../bfd -I/git/binutils-gdb/binutils/../bfd -I/git/binutils-gdb/binutils/../include -DLOCALEDIR="\"/usr/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -MT stabs.o -MD -MP -MF .deps/stabs.Tpo -c -o stabs.o /git/binutils-gdb/binutils/stabs.c /git/binutils-gdb/binutils/stabs.c: In function ‘parse_stab_members’: /git/binutils-gdb/binutils/stabs.c:2705:31: error: comparison between pointer and zero character constant [-Werror=pointer-compare] if (**pp == ';' || *pp == '\0') ^~ /git/binutils-gdb/binutils/stabs.c:2705:27: note: did you mean to dereference the pointer? if (**pp == ';' || *pp == '\0') ^ cc1: all warnings being treated as errors make: *** [Makefile:962: stabs.o] Error 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 binutils/20343] Document how to use LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=20343
--- Comment #11 from dilyan.palauzov at aegee dot org ---
diff --git a/binutils/doc/binutils.texi b/binutils/doc/binutils.texi
index 0a2c4c6ab4..d7b3657aa0 100644
--- a/binutils/doc/binutils.texi
+++ b/binutils/doc/binutils.texi
@@ -534,9 +534,17 @@ default for @sc{gnu} @command{ar}. @command{ar} does not
support any of the oth
which is the default for AIX @command{ar}.
The optional command line switch @option{--plugin} @var{name} causes
-@command{ar} to load the plugin called @var{name} which adds support
-for more file formats. This option is only available if the toolchain
-has been built with plugin support enabled.
+@command{ar} to load the plugin called @var{name} which adds support for more
+file formats, including object files with link-time optimization information.
+This option is only available if the toolchain has been built with plugin
+support enabled. If @option{--plugin} is not provided, @command{ar} iterates
+over the files in $@{libdir@}/bfd-plugins in alphabetic order and the first
+plugin that claims the object in question is used. Please note, that the
+implicit search path is not identical to the one used by @command{ld}
+@option{-plugin}. To make @command{ar} consider implicitly the linker plugin,
+copy it to $@{libdir@}/bfd-plugins. For GCC the plugin is
+@file{liblto_plugin.so.0.0.0}, for Clang - @file{LLVMgold.so}. The GCC plugin
+is backwards compatible, so it is sufficient to have just the newest one.
The optional command line switch @option{--target} @var{bfdname}
specifies that the archive members are in an object code format
@@ -1009,7 +1017,14 @@ Display only defined symbols for each object file.
@cindex load plugin
Load the plugin called @var{name} to add support for extra target
types. This option is only available if the toolchain has been built
-with plugin support enabled.
+with plugin support enabled. If @option{--plugin} is not provided,
+@command{nm} iterates over the files in $@{libdir@}/bfd-plugins in
alphabetical
+order and the first plugin that claims the object is used. Please note, that
+the plugin path is not identical to the one used by @command{ld}
+@option{-plugin}. To make @command{nm} consider implicitly the linker plugin,
+copy it to $@{libdir@}/bfd-plugins. For GCC the plugin is
@file{liblto_plugin.so.0.0.0}, for Clang - @file{LLVMgold.so}. The
+GCC plugin is backwards compatible, so it is sufficient to have just the
newest
+one.
@item --size-sort
Sort symbols by size. For ELF objects symbol sizes are read from the
diff --git a/ld/ld.texinfo b/ld/ld.texinfo
index 29c2131a2b..ce2137c209 100644
--- a/ld/ld.texinfo
+++ b/ld/ld.texinfo
@@ -828,6 +828,16 @@ the linker may make more use of this option. Also
currently there is
no difference in the linker's behaviour for different non-zero values
of this option. Again this may change with future releases.
+@kindex -plugin @var{linker-plugin}
+@item -plugin @var{linker-plugin}
+Involve a plugin in the linking process. This parameter is automatically
added
+by the complier, when using link time optimization, and contains the absolute
+file name the the plugin, where the installation process has put it. Note,
that
+the path is different from the place, where
+@command{ar}/@command{nm}/@command{ranlib} search implicitly for the linker
+plugin. All gcc linker plugins are backward compatible, it is sufficient to
+have just the newest one.
+
@kindex --push-state
@cindex push state governing input file handling
@item --push-state
--
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/20958] New: yywrap in binutils/syslex.l and ld/ldlex.l
https://sourceware.org/bugzilla/show_bug.cgi?id=20958
Bug ID: 20958
Summary: yywrap in binutils/syslex.l and ld/ldlex.l
Product: binutils
Version: 2.28 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
The most recent flex v2.6.2-19-g6bea32e generates code like
#define yywrap yywrap
#define yyalloc yyalloc
and from that moment on 'yywrap' is defined, hence
#ifndef yywrap
static int yywrap (void) { return 1;}
#endif
is discarded and the compilation fails.
This patch helps (but does not consider the same effect in binutils/(arlex.l,
deflex.l, gas/config/bfin-lex.l, gas/itbl-lex.l and gdb/ada-lex.l. I find also
#ifdef yywrap
extern int yywrap (void);
#endif in ld/ldlex.h is unnecessary.
diff --git a/binutils/syslex.l b/binutils/syslex.l
index 836a64cf93..25be30305e 100644
--- a/binutils/syslex.l
+++ b/binutils/syslex.l
@@ -1,4 +1,4 @@
-%option noinput nounput
+%option noinput nounput noyywrap
%{
/* Copyright (C) 2001-2016 Free Software Foundation, Inc.
@@ -36,10 +36,6 @@
#define YY_NO_UNPUT
#endif
-#ifndef yywrap
-static int yywrap (void) { return 1; }
-#endif
-
extern int yylex (void);
%}
%%
diff --git a/ld/ldlex.l b/ld/ldlex.l
index cd21c58e3d..2b229cfcd6 100644
--- a/ld/ldlex.l
+++ b/ld/ldlex.l
@@ -1,4 +1,4 @@
-%option nounput
+%option nounput noyywrap
%{
@@ -87,9 +87,6 @@ static void lex_warn_invalid (char *where, char *what);
#define RTOKEN(x) { yylval.token = x; return x; }
/* Some versions of flex want this. */
-#ifndef yywrap
-int yywrap (void) { return 1; }
-#endif
%}
%a 4000
--
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/20343] Document how to use LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=20343 --- Comment #9 from dilyan.palauzov at aegee dot org --- When the bfd-plugins directory looks like: me@home:/usr/local/lib/bfd-plugins# ls -l total 4 lrwxrwxrwx 1 root staff 14 Jul 21 15:11 LLVMgold.so -> ../LLVMgold.so lrwxrwxrwx 1 root staff 71 Jul 10 17:56 liblto_plugin.so.0.0.0 -> /usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.1.1/liblto_plugin.so.0.0.0* How does "nm t.o" decide, if it shall open liblto_plugin or LLVMgold to proceed the .o file? Why does ld proceed in a different way? -- 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/20404] New: gold/configure --help shall print "
https://sourceware.org/bugzilla/show_bug.cgi?id=20404
Bug ID: 20404
Summary: gold/configure --help shall print "
Product: binutils
Version: 2.28 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: dilyan.palauzov at aegee dot org
CC: ian at airs dot com
Target Milestone: ---
Provided that gold/configure always turns on "--enable-relro", contrary to
ld/configure, as gold/configure.tgt and ld/configure.tgt differ, gold/configure
--help shall print
--disable-relrodisable -z relro in ELF linker by default
to indicate, that by not specifying anything, relro will be enabled implicitly
in the compiled gold. Currently gold/configure --help prints "--enable-relro
enable -z relro in ELF linker by default" which indicates the opposite.
Please consider adjusting the output of ld.gold --help as follows.
diff --git a/gold/configure.ac b/gold/configure.ac
index de3b630..742af37 100644
--- a/gold/configure.ac
+++ b/gold/configure.ac
@@ -118,8 +118,8 @@ AM_CONDITIONAL(PLUGINS, test "$plugins" = "yes")
ac_default_ld_z_relro=unset
# Provide a configure time option to override our default.
AC_ARG_ENABLE(relro,
- AS_HELP_STRING([--enable-relro],
- [enable -z relro in ELF linker by default]),
+ AS_HELP_STRING([--disable-relro],
+ [disable -z relro in ELF linker by default]),
[case "${enableval}" in
yes) ac_default_ld_z_relro=1 ;;
no) ac_default_ld_z_relro=0 ;;
--
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/20346] Modify "gold --help" to show if "-z relro" is enabled by default
https://sourceware.org/bugzilla/show_bug.cgi?id=20346 --- Comment #2 from dilyan.palauzov at aegee dot org --- When is it sufficient to provide a patch to an enhancement report, when it is sufficient to send a patch to binutils@ (or gdb-patches@) and when is it necessary to fill a bug report with patch attached and at the same time send a patch over the mailing list? I am asking, because in this case apart from providing a patch in the bug report, I am supposed to send it to a mailing list; in case of https://sourceware.org/ml/gdb-patches/2015-07/msg00396.html just sending a patch to gdb-patches@ wasn't enough to get it integrated; so in both cases apparently both actions need to be performed. -- 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/20343] Document how to use LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=20343 --- Comment #7 from dilyan.palauzov at aegee dot org --- The part with bfd/plugin.c was a false alarm. The problem was, that I had the change below, which was supposed to fix these warnings, when I compile binutils with -flto (cf. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611): /git/binutils-gdb/libiberty/make-relative-prefix.c: In function 'make_relative_prefix_1.constprop': /git/binutils-gdb/libiberty/make-relative-prefix.c:228:1: error: stack usage might be unbounded [-Werror=stack-usage=] make_relative_prefix_1 (const char *progname, const char *bin_prefix, ^ lto1: all warnings being treated as errors Nevertheless, there is no documentation to state, that the linker plugin shall be installed in bfd-plugins/. index fe639d1..dba3429 100644 --- a/libiberty/make-relative-prefix.c +++ b/libiberty/make-relative-prefix.c @@ -256,7 +256,7 @@ make_relative_prefix_1 (const char *progname, const char *bin_prefix, #ifdef HAVE_HOST_EXECUTABLE_SUFFIX len += strlen (HOST_EXECUTABLE_SUFFIX); #endif - nstore = (char *) alloca (len); + nstore = (char *) malloc (len); startp = endp = temp; while (1) @@ -304,6 +304,7 @@ make_relative_prefix_1 (const char *progname, const char *bin_prefix, else endp++; } + free(nstore); } } -- 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/20343] Document how to use LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=20343
--- Comment #6 from dilyan.palauzov at aegee dot org ---
I had --enable-plugins.
"strace ar csr ... &|grep bfd" prints
openat(AT_FDCWD, "../bin/../lib/bfd-plugins",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
hence if it works, depends on the current directory. In
bfd/plugin.c:load_plugin() I have on line 337
BINDIR=/usr/local/bin
then plugin_dir is evaluated to /usr/local/bin/../lib/bfd-plugins and p (result
of make_relative_prefix()) is
${HOME}/binutils/binutils/../bin/../lib/bfd-plugins. Afterwards plugin_dir is
discarded and the plugins are searched in the relative dir, stored in p.
How are the plugins supposed to be always found in the relative directories?
--
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/20346] New: Modify "gold --help" to show if "-z relro" is enabled by default
https://sourceware.org/bugzilla/show_bug.cgi?id=20346
Bug ID: 20346
Summary: Modify "gold --help" to show if "-z relro" is enabled
by default
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: dilyan.palauzov at aegee dot org
CC: ian at airs dot com
Target Milestone: ---
Please apply the following snippet, so that "gold --help" prints whether "-z
relro" is enabled by default.
diff --git a/gold/options.h b/gold/options.h
index 23c9658..bfed05c 100644
--- a/gold/options.h
+++ b/gold/options.h
@@ -1337,8 +1337,13 @@ class General_options
N_("Mark DSO to indicate that needs immediate $ORIGIN "
"processing at runtime"), NULL);
DEFINE_bool(relro, options::DASH_Z, '\0', DEFAULT_LD_Z_RELRO,
- N_("Where possible mark variables read-only after relocation"),
+#if DEFAULT_LD_Z_RELRO
+ N_("Where possible mark variables read-only after relocation
(default)"),
N_("Don't mark variables read-only after relocation"));
+#else
+ N_("Where possible mark variables read-only after relocation"),
+ N_("Don't mark variables read-only after relocation (default)"));
+#endif
DEFINE_bool(text, options::DASH_Z, '\0', false,
N_("Do not permit relocations in read-only segments"),
N_("Permit relocations in read-only segments (default)"));
--
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/20343] Document how to use LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=20343
--- Comment #3 from dilyan.palauzov at aegee dot org ---
The bfd-plugins directory is not documented.
Doing "gcc -c t.c" "strace nm --plugin=liblto_plugin.so.0.0.0 t.o" does not
show that the bfd-plugins directory is checked, nor does "strace ar csr
--plugin liblto_plugin.so.0.0.o libt.a t.o" check it.
I use binutils 2.26.51.20160709 with ./configure --prefix=/usr/local. I guess
the bfd-plugins directory has to be somewhere under /usr/local
(/usr/local/lib/bfd-plugins or /usr/local/x86_64-pc-linux-gnu/lib/bfd-plugins),
but strace does not show anything under local, except
execve("/usr/local/{ar,nm}")
Why is here:
open("/lib/x86_64-linux-gnu/tls/x86_64/liblto_plugin.so.0.0.o",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/tls/liblto_plugin.so.0.0.o", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/x86_64/liblto_plugin.so.0.0.o", O_RDONLY|O_CLOEXEC)
= -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/liblto_plugin.so.0.0.o", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/tls/x86_64/liblto_plugin.so.0.0.o",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/tls/liblto_plugin.so.0.0.o",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/x86_64/liblto_plugin.so.0.0.o",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/liblto_plugin.so.0.0.o", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
used "x86_64-linux-gnu" instead of "x86_64-pc-linux-gnu"
--
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/20343] New: Document how to use LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=20343 Bug ID: 20343 Summary: Document how to use LTO Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- Please document what the user has to do, in order to use LTO with ld, gold, nm, ar, ranlib in regards to the -?-plugin option. In particular, * when is 'compiler -print-prog-name=...' called to find the plugin, * if it is not called by nm, ar, ranlib, how to the latter find the linker plugin * how can different plugins coexist (for gcc and clang, and for different versions of gcc) * how is the directory bfd-plugins supposed to be used * in which binutils versions have the aforementioned behaviours changed -- 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/20321] New: Segmentation fault with plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=20321
Bug ID: 20321
Summary: Segmentation fault with plugin
Product: binutils
Version: 2.27 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
I use ld 2.26.51.20160701 ./configure'd with --enable-plugins
--with-system-zlib --with-expat --with-python --disable-tui
--with-system-readline --enable-compressed-debug-sections=all --enable-gold
When I try to compile this file, called Z.c:
int main ()
{
;
return 0;
}
with gcc -pipe -O3 -fno-fat-lto-objects -flto -Wl,-O1,-s
-Wl,-plugin,/usr/local/lib/bfd-plugins/liblto_plugin.so Z.c
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core
dumped
compilation terminated.
gdb -quiet -ex 'bt f' /usr/local/bin/ld core
Reading symbols from /usr/local/bin/ld...done.
[New LWP 6862]
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by
`/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.0.0/../../../../x86_64-pc-linux-gnu/bi'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0042811d in get_symbols (handle=0x95fda0, nsyms=1, syms=0x0,
def_ironly_exp=9) at /git/binutils-gdb/ld/plugin.c:669
669 if (syms[n].def != LDPK_UNDEF)
#0 0x0042811d in get_symbols (handle=0x95fda0, nsyms=1, syms=0x0,
def_ironly_exp=9) at /git/binutils-gdb/ld/plugin.c:669
blhe = 0x1
owner_sec = 0x7f94de66b710
res = 32660
input = 0x95fda0
abfd = 0x95ee00
n = 0
__PRETTY_FUNCTION__ = "get_symbols"
#1 0x004285ad in get_symbols_v2 (handle=0x95fda0, nsyms=1, syms=0x0)
at /git/binutils-gdb/ld/plugin.c:787
No locals.
#2 0x7f94ddeca491 in write_resolution () at
../.././lto-plugin/lto-plugin.c:490
info = 0x961030
symtab = 0x961040
syms =
i = 0
f = 0xb659c0
#3 all_symbols_read_handler () at ../.././lto-plugin/lto-plugin.c:657
i =
num_lto_args =
lto_argv = 0xb669b0
linker_output_str = 0x0
lto_arg_ptr = 0xb669b0
__PRETTY_FUNCTION__ = "all_symbols_read_handler"
#4 0x0042941f in plugin_call_all_symbols_read () at
/git/binutils-gdb/ld/plugin.c:1231
rv = LDPS_OK
curplug = 0x92a0c0
#5 0x00418560 in lang_process () at /git/binutils-gdb/ld/ldlang.c:6850
added = {
head = 0x9271d0,
tail = 0x93cd60
}
files = {
head = 0x927230,
tail = 0x92a2e0
}
inputfiles = {
head = 0x9271d0,
tail = 0x95e678
}
#6 0x0041ca08 in main (argc=43, argv=0x7ffe199c9838) at
/git/binutils-gdb/ld/ldmain.c:415
emulation = 0x7ffe199ca382 "elf_x86_64"
start_time = 0
start_sbrk = 0x926000 ""
This is with gcc 7.0.0 20160627.
The same happens with gcc 5.4.1 20160630:
/usr/local/gcc5/bin/gcc -pipe -O3 -fno-fat-lto-objects -Wl,-O1,-s
-Wl,-plugin,/usr/local/gcc5/libexec/gcc/x86_64-unknown-linux-gnu/5.4.1/liblto_plugin.so
Z.c
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core
dumped
compilation terminated.
gdb -quiet -ex 'bt f' /usr/local/bin/ld core
Reading symbols from /usr/local/bin/ld...done.
[New LWP 6939]
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `/usr/local/bin/ld -plugin
/usr/local/gcc5/libexec/gcc/x86_64-unknown-linux-gnu/'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0042811d in get_symbols (handle=0x131fd40, nsyms=1, syms=0x0,
def_ironly_exp=9) at /git/binutils-gdb/ld/plugin.c:669
669 if (syms[n].def != LDPK_UNDEF)
#0 0x0042811d in get_symbols (handle=0x131fd40, nsyms=1, syms=0x0,
def_ironly_exp=9) at /git/binutils-gdb/ld/plugin.c:669
blhe = 0x1
owner_sec = 0x7fb39c640710
res = 32691
input = 0x131fd40
abfd = 0x131eda0
n = 0
__PRETTY_FUNCTION__ = "get_symbols"
#1 0x004285ad in get_symbols_v2 (handle=0x131fd40, nsyms=1, syms=0x0)
at /git/binutils-gdb/ld/plugin.c:787
No locals.
#2 0x7fb39be9f468 in write_resolution () at
../.././lto-plugin/lto-plugin.c:476
info = 0x1320fd0
symtab = 0x1320fe0
syms =
i = 0
f = 0x14fd830
#3 all_symbols_read_handler () at ../.././lto-plugin/lto-plugin.c:643
i =
num_lto_args =
lto_argv = 0x14fa0e0
lto_arg_ptr = 0x14fa0e0
__PRETTY_FUNCTION__ = "all_symbols_read_handler"
#4 0x0042941f in plugin_call_all_symbo
[Bug gold/20108] New: gcctestdir/ld: internal error in write_info_blocks, at /git/binutils-gdb/gold/incremental.cc:1651
https://sourceware.org/bugzilla/show_bug.cgi?id=20108 Bug ID: 20108 Summary: gcctestdir/ld: internal error in write_info_blocks, at /git/binutils-gdb/gold/incremental.cc:1651 Product: binutils Version: 2.27 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: dilyan.palauzov at aegee dot org CC: ian at airs dot com Target Milestone: --- I use gcc 6.1.1 20160517, binutils 2.26.51.20160517 and CFLAGS="-pipe -O3" CXXFLAGS="-pipe -O3" LDFLAGS="-Wl,-O1,-z,relro,-s". Doing make check in gold prints: make[2]: 'ehdr_start_test_1' is up to date. make[2]: 'ehdr_start_test_2' is up to date. make[2]: 'ehdr_start_test_3' is up to date. make[2]: 'ehdr_start_test_5' is up to date. cp -f two_file_test_1_v1_ndebug.o two_file_test_tmp_2.o `echo g++ -W -Wall-Wstack-usage=262144 -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -pipe -O3 -fno-use-linker-plugin -Wl,-O1,-z,relro,-s -o incremental_test_2 | sed -e 's/-Wp,-D_FORTIFY_SOURCE=[0-9][0-9]*//'` -Wl,--incremental-full,--incremental-patch=100 -Wl,-z,norelro -Bgcctestdir/ two_file_test_tmp_2.o two_file_test_1b_ndebug.o two_file_test_2_ndebug.o two_file_test_main_ndebug.o gcctestdir/ld: internal error in write_info_blocks, at /git/binutils-gdb/gold/incremental.cc:1651 collect2: error: ld returned 1 exit status Makefile:6506: recipe for target 'incremental_test_2' failed make[2]: *** [incremental_test_2] Error 1 make[2]: Leaving directory '/root/binutils/gold/testsuite' Makefile:5043: recipe for target 'check-am' failed make[1]: *** [check-am] Error 2 make[1]: Leaving directory '/root/binutils/gold/testsuite' Makefile:5047: recipe for target 'check' failed make: *** [check] Error 2 -- 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/20006] New: Linking gcc and gold with ld.bfd with compressed debug sections fails on final close
https://sourceware.org/bugzilla/show_bug.cgi?id=20006 Bug ID: 20006 Summary: Linking gcc and gold with ld.bfd with compressed debug sections fails on final close Product: binutils Version: 2.27 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- When I compile binutils-gdb.git(3e2e34f86) with "/git/binutils-gdb/configure --enable-plugins --with-system-zlib --enable-gold --with-expat --with-python --disable-tui --with-system-readline && make && make install" and then compile gcc.git(a9ad7efd6e2b255) with "./configure --enable-host-shared --enable-threads=posix --enable-targets=all --enable-nls --with-linker-hash-style=gnu --with-system-zlib --disable-multilib --enable-languages=c,c++,jit,lto && make && make install" everything is fine. If I pass however to binutils/configure "--enable-compressed-debug-sections=all": /git/binutils-gdb/configure --enable-plugins --with-system-zlib --enable-gold --with-expat --with-python --disable-tui --with-system-readline --enable-compressed-debug-sections=all && make && make install and try to recompile gcc with the same options, I get at stage1: make[3]: Leaving directory '/git/gcc/host-x86_64-pc-linux-gnu/libdecnumber' make[3]: Entering directory '/git/gcc/host-x86_64-pc-linux-gnu/gcc' g++ -std=gnu++98 -no-pie -g -DIN_GCC -fPIC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-z,relro,-O1 -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-array-notation.o c/c-fold.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-cilkplus.o c-family/array-notation-common.o c-family/cilk.o c-family/c-ubsan.o i386-c.o glibc-c.o \ cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/pic/libiberty.a ../libdecnumber/libdecnumber.a -lisl -lmpc -lmpfr -lgmp -rdynamic -ldl -lz cc1: final close failed: Invalid operation collect2: error: ld returned 1 exit status ../.././gcc/c/Make-lang.in:71: recipe for target 'cc1' failed make[3]: *** [cc1] Error 1 make[3]: Leaving directory '/git/gcc/host-x86_64-pc-linux-gnu/gcc' Makefile:4391: recipe for target 'all-stage1-gcc' failed make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory '/git/gcc' Makefile:20572: recipe for target 'stage1-bubble' failed make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory '/git/gcc' Makefile:913: recipe for target 'all' failed make: *** [all] Error 2 In fact, I cannot even link gold, when gas and ld.bfd are using compression: make -k make[4]: Leaving directory '/home/d/binutils/gold/testsuite' make[4]: Entering directory '/home/d/binutils/gold' g++ -W -Wall-Wstack-usage=262144 -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=dwp -pipe -O3 -static-libstdc++ -static-libgcc -Wl,-z,relro,-O1 -o dwp dwp.o libgold.a ../libiberty/libiberty.a -ldl -lz -ldl dwp: final close failed: Invalid operation collect2: error: ld returned 1 exit status Makefile:803: recipe for target 'dwp' failed make[4]: *** [dwp] Error 1 g++ -W -Wall-Wstack-usage=262144 -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=ld-new -pipe -O3 -static-libstdc++ -static-libgcc -Wl,-z,relro,-O1 -o ld-new main.o i386.o x86_64.o sparc.o powerpc.o arm.o arm-reloc-property.o tilegx.o mips.o aarch64.o aarch64-reloc-property.o s390.o libgold.a ../libiberty/libiberty.a-ldl -lz -ldl ld-new: final close failed: Invalid operation collect2: error: ld returned 1 exit status Makefile:809: recipe for target 'ld-new' failed make[4]: *** [ld-new] Error 1 g++ -W -Wall-Wstack-usage=262144 -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=incremental-dump -pipe -O3 -static-libstdc++ -static-libgcc -Wl,-z,relro,-O1 -o incremental-dump incremental-dump.o i386.o x86_64.o sparc.o powerpc.o arm.o arm-reloc-property.o tilegx.o mips.o aarch64.o aarch64-reloc-property.o s390.o libgold.a ../libiberty/libiberty.a -ldl -lz -ldl incremental-dump: final close failed: Invalid operation collect2: error: ld re
[Bug gold/19815] New: build incremental-dump only on "make check"
https://sourceware.org/bugzilla/show_bug.cgi?id=19815 Bug ID: 19815 Summary: build incremental-dump only on "make check" Product: binutils Version: 2.27 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: dilyan.palauzov at aegee dot org CC: ian at airs dot com Target Milestone: --- Please alter gold/Makefile.am as follows: change "noinst_PROGRAMS = ld-net incremental-dump" to " noinst_PROGRAMS = ld-new check_PROGRAMS = incremental-dump ", so that incremental-dump is built only on "make check". check_* stuff does not get installed. change "SUBDIRS = po testsuite" => "SUBDIRS = . po testsuite" to ensure, that when doing "make check" the files in the gold/ directory are build before switching to the testsuite directory (which requires built ../incremental-dump). -- 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/19788] New: gcc 6.0, bfd/aoutx.h and -Werror=strict-aliasing
https://sourceware.org/bugzilla/show_bug.cgi?id=19788 Bug ID: 19788 Summary: gcc 6.0, bfd/aoutx.h and -Werror=strict-aliasing Product: binutils Version: 2.27 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- Compiling bfd with gcc 6.0.0 20160308 prints: make[4]: Entering directory '/binutils/bfd' /bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/git/binutils-gdb/bfd -I. -I/git/binutils-gdb/bfd -I/git/binutils-gdb/bfd/../include -DHAVE_x86_64_elf64_vec -DHAVE_i386_elf32_vec -DHAVE_iamcu_elf32_vec -DHAVE_x86_64_elf32_vec -DHAVE_i386_aout_linux_vec -DHAVE_i386_pei_vec -DHAVE_x86_64_pei_vec -DHAVE_l1om_elf64_vec -DHAVE_k1om_elf64_vec -DHAVE_elf64_le_vec -DHAVE_elf64_be_vec -DHAVE_elf32_le_vec -DHAVE_elf32_be_vec -DHAVE_plugin_vec -DBINDIR='"/usr/local/bin"' -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -pipe -O3 -fno-fat-lto-objects -flto -MT aout32.lo -MD -MP -MF .deps/aout32.Tpo -c -o aout32.lo /git/binutils-gdb/bfd/aout32.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/git/binutils-gdb/bfd -I. -I/git/binutils-gdb/bfd -I/git/binutils-gdb/bfd/../include -DHAVE_x86_64_elf64_vec -DHAVE_i386_elf32_vec -DHAVE_iamcu_elf32_vec -DHAVE_x86_64_elf32_vec -DHAVE_i386_aout_linux_vec -DHAVE_i386_pei_vec -DHAVE_x86_64_pei_vec -DHAVE_l1om_elf64_vec -DHAVE_k1om_elf64_vec -DHAVE_elf64_le_vec -DHAVE_elf64_be_vec -DHAVE_elf32_le_vec -DHAVE_elf32_be_vec -DHAVE_plugin_vec -DBINDIR=\"/usr/local/bin\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -pipe -O3 -fno-fat-lto-objects -flto -MT aout32.lo -MD -MP -MF .deps/aout32.Tpo -c /git/binutils-gdb/bfd/aout32.c -o aout32.o In file included from /git/binutils-gdb/bfd/aout32.c:24:0: /git/binutils-gdb/bfd/aoutx.h: In function 'aout_32_write_syms': /git/binutils-gdb/bfd/aoutx.h:1871:4: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] H_PUT_16 (abfd, aout_symbol (g)->desc, nsp.e_desc); ^~~~ /git/binutils-gdb/bfd/aoutx.h:1872:4: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] H_PUT_8 (abfd, aout_symbol (g)->other, nsp.e_other); ^~~ /git/binutils-gdb/bfd/aoutx.h:1873:4: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] H_PUT_8 (abfd, aout_symbol (g)->type, nsp.e_type); ^~~ /git/binutils-gdb/bfd/aoutx.h: In function 'aout_32_get_symbol_info': /git/binutils-gdb/bfd/aoutx.h:2504:7: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] int type_code = aout_symbol (symbol)->type & 0xff; ^~~ /git/binutils-gdb/bfd/aoutx.h:2515:7: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] ret->stab_other = (unsigned) (aout_symbol (symbol)->other & 0xff); ^~~ /git/binutils-gdb/bfd/aoutx.h:2516:7: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] ret->stab_desc = (unsigned) (aout_symbol (symbol)->desc & 0x); ^~~ /git/binutils-gdb/bfd/aoutx.h: In function 'aout_32_print_symbol': /git/binutils-gdb/bfd/aoutx.h:2537:9: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] (unsigned) (aout_symbol (symbol)->desc & 0x), ^ /git/binutils-gdb/bfd/aoutx.h:2538:9: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] (unsigned) (aout_symbol (symbol)->other & 0xff), ^ /git/binutils-gdb/bfd/aoutx.h:2539:9: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] (unsigned) (aout_symbol (symbol)->type)); ^ /git/binutils-gdb/bfd/aoutx.h:2549:4: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] (unsigned) (aout_symbol (symbol)->desc & 0x), ^ /git/binutils-gdb/bfd/aoutx.h:2550:4: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] (unsigned) (aout_symbol (symbol)->other & 0xff), ^ /git/binutils-gdb/bfd/aoutx.h:2551:4: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] (unsigned) (aout_symbol (symbol)->type & 0xff)); ^ cc1: all warnings being treated as errors Makefile:1640: recipe for target 'aout32.lo' failed make[4]: *** [aout32.lo] Error 1 make[4]: Leaving directory '/binutils/bfd' -- You are receiving this mail because: You are on the CC list for the bug. __
[Bug binutils/19478] New: GCC 6.0 Warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=19478
Bug ID: 19478
Summary: GCC 6.0 Warnings
Product: binutils
Version: 2.27 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
When compiling binutils GCC 6.0 states:
/git/binutils-gdb/gold/dirsearch.cc:125:1: error:
‘{anonymous}::Dir_caches::~Dir_caches()’ defined but not used
[-Werror=unused-function]
Dir_caches::~Dir_caches()
^~
cc1plus: all warnings being treated as errors
make[4]: *** [dirsearch.o] Error 1
/git/binutils-gdb/gold/arm.cc:4519:1: error: ‘std::__cxx11::string
{anonymous}::Reloc_stub::Key::name() const’ defined but not used
[-Werror=unused-function]
Reloc_stub::Key::name() const
^~
cc1plus: all warnings being treated as errors
make[4]: *** [arm.o] Error 1
make[4]: Target 'all-am' not remade because of errors.
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-gold] Error 2
/git/binutils-gdb/gdb/linux-record.c: In function ‘record_linux_sockaddr’:
/git/binutils-gdb/gdb/linux-record.c:115:9: error: statement is indented as if
it were guarded by... [-Werror=misleading-indentation]
return -1;
^~
/git/binutils-gdb/gdb/linux-record.c:109:7: note: ...this ‘if’ clause, but it
is not
if (record_debug)
^~
/git/binutils-gdb/gdb/linux-record.c: In function ‘record_linux_msghdr’:
/git/binutils-gdb/gdb/linux-record.c:153:9: error: statement is indented as if
it were guarded by... [-Werror=misleading-indentation]
return -1;
^~
/git/binutils-gdb/gdb/linux-record.c:146:7: note: ...this ‘if’ clause, but it
is not
if (record_debug)
^~
/git/binutils-gdb/gdb/linux-record.c:191:17: error: statement is indented as if
it were guarded by... [-Werror=misleading-indentation]
return -1;
^~
/git/binutils-gdb/gdb/linux-record.c:183:15: note: ...this ‘if’ clause, but it
is not
if (record_debug)
^~
/git/binutils-gdb/gdb/linux-record.c: In function ‘record_linux_system_call’:
/git/binutils-gdb/gdb/linux-record.c:986:21: error: statement is indented as if
it were guarded by... [-Werror=misleading-indentation]
return -1;
^~
/git/binutils-gdb/gdb/linux-record.c:980:19: note: ...this ‘if’ clause, but it
is not
if (record_debug)
^~
cc1: all warnings being treated as errors
make[2]: *** [linux-record.o] Error 1
/git/binutils-gdb/gdb/ada-lang.c: In function ‘ada_evaluate_subexp’:
/git/binutils-gdb/gdb/ada-lang.c:11423:9: error: statement is indented as if it
were guarded by... [-Werror=misleading-indentation]
arg1 = unwrap_value (arg1);
^~~~
/git/binutils-gdb/gdb/ada-lang.c:11421:7: note: ...this ‘else’ clause, but it
is not
else
^~~~
cc1: all warnings being treated as errors
make[2]: *** [ada-lang.o] Error 1
/git/binutils-gdb/gdb/c-typeprint.c: In function ‘c_type_print_base’:
/git/binutils-gdb/gdb/c-typeprint.c:1308:3: error: statement is indented as if
it were guarded by... [-Werror=misleading-indentation]
for (i = 0; i < TYPE_TYPEDEF_FIELD_COUNT (type); i++)
^~~
/git/binutils-gdb/gdb/c-typeprint.c:1305:8: note: ...this ‘if’ clause, but it
is not
if (TYPE_NFIELDS (type) != 0 || TYPE_NFN_FIELDS (type) != 0)
^~
cc1: all warnings being treated as errors
make[2]: *** [c-typeprint.o] Error 1
/git/binutils-gdb/gdb/inflow.c: In function ‘child_terminal_ours_1’:
/git/binutils-gdb/gdb/inflow.c:416:5: error: statement is indented as if it
were guarded by... [-Werror=misleading-indentation]
{
^
/git/binutils-gdb/gdb/inflow.c:413:3: note: ...this ‘if’ clause, but it is not
if (tinfo->run_terminal != NULL || gdb_has_a_terminal () == 0)
^~
cc1: all warnings being treated as errors
make[2]: *** [inflow.o] Error 1
make[2]: Target 'all' not remade because of errors.
make[1]: *** [all-gdb] Error 2
make[1]: Target 'all-host' not remade because of errors.
make: *** [all] Error 2
--
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
