[Bug backends/23902] varlocs dwarf_cfi_addrframe: unknown error (missing ebl abi_cfi hook)
https://sourceware.org/bugzilla/show_bug.cgi?id=23902 --- Comment #8 from Mark Wielaard --- (In reply to Mark Wielaard from comment #3) > (In reply to Kurt Roeckx from comment #2) > > PS: All arches except amd64 have "Unwinding not supported for this > > architecture" in run-backtrace-data.sh, which I find a bit surprising. > > Yes, that is surprising, run-backtrace-data.sh really should just say that > it is only supported on x86_64/amd64. Currently it "abuses" the "Unwinding > not supported for this architecture" message to get a SKIP on any other arch. I pushed the following commit which should hopefully make this skip message more clear: commit 63160fceaaac2f9bd13da7abf929907a5f723aab Author: Mark Wielaard Date: Wed Nov 28 13:58:31 2018 +0100 tests: Improve backtrace-data SKIP message. The backtrace-data testcase is x86_64 linux only because it uses its own set_initial_registers and scans its own /proc/pid/maps file. The SKIP message it gave on other platforms was misleading. It said "Unwinding not supported for this architecture". Change it to "x86_64 linux only test" to be less confusing. Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/23914] Add --disable-werror to ./configure support (example trigger: CFLAGS=-Og
https://sourceware.org/bugzilla/show_bug.cgi?id=23914 --- Comment #3 from Mark Wielaard --- (In reply to Sergei Trofimovich from comment #2) > Gentoo allows users to control CC and CFLAGS and thus the space for getting > a warning is wide. People frequently use things like -Wcast-qual or other > high signal-to-noise flags for their purposes. If they do and don't care about the warnings, then why don't they simply add -Wno-error too? > My favourite example is > ./configure CFLAGS="-g -Wall" # works today without failures > or even ./configure CC=clang CFLAGS="-g -Weverything" but elfutils does not > seem to support clang. Yes, -Wall is one of the warnings we explicitly enable. See config/eu.am for the full list. Some have configure checks to make sure the compiler actually supports it. And some sadly have to be disabled for some specific source files. If you have concrete warning flags you would like to see enabled by default please do submit them, but we do like to enable them only once the code base is clean. Then we enable them by default and will always catch whenever new code produces a warning (because of -Werror). An -Weverything flag seems silly, some warnings don't really mix, some are for style issues. IMHO warnings are only interesting if you can take some action to correct the code. clang support would be nice, but clang doesn't support various GNU C extensions, there is a configure check for it though, so as soon as clang actually support -std=gnu99 it should work. > Real-world examples used by people: > > 1. CFLAGS="-g -Wall -Wcast-qual" > > In file included from gelf_xlate.c:166: > version_xlate.h: In function 'elf_cvt_Verdef': > version_xlate.h:74:31: error: cast discards 'const' qualifier from pointer > target type [-Werror=cast-qual] > dsrc = (GElf_Verdef *) ((char *) src + def_offset); > ^ There are a lot of cast-qual warnings. It might make sense to clean them up. But it might be hard since in some cases we support overlapping src/dest buffers which might be marked "wrongly" in the external API. > 2. CFLAGS="-g -O2 -Wstack-protector" > > CC readelf.o > readelf.c: In function 'open_input_section': > readelf.c:581:1: error: stack protector not protecting local variables: > variable length buffer [-Werror=stack-protector] >open_input_section (int fd) >^~ That in itself wouldn't warn. I assume you are using -fstack-protector[-all|strong] too. The warning is correct. We do already support -Wstack-usage. But it is disabled for a couple of files. readelf.c is one of them (see src/Makefile.am). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/23919] bfd doesn't handle ELF compressed data alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=23919 --- Comment #8 from Dmitry V. Levin --- When we backported these fixes to our 2_31 based branch, we got a surprising regression in gold/testsuite: $ cat gold/testsuite/debug_msg.sh.log Did not find expected error in debug_msg_so.err: debug_msg.so: error: undefined reference to 'undef_fn1()' Actual error output below: gcctestdir/ld: internal error in read_header_prolog, at dwarf_reader.cc:1678 collect2: error: ld returned 1 exit status FAIL debug_msg.sh (exit status: 1) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/23919] bfd doesn't handle ELF compressed data alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=23919 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #9 from H.J. Lu --- This change triggered gcctestdir/collect-ld: warning: gdb_index_test_cdebug_gabi.o: section .debug_str contains incorrectly aligned strings; the alignment of those strings won't be preserved gcctestdir/collect-ld: warning: gdb_index_test_3.o: section .debug_str contains incorrectly aligned strings; the alignment of those strings won't be preserved gcctestdir/collect-ld: error: treating warnings as errors collect2: error: ld returned 1 exit status make[3]: *** [gdb_index_test_3] Error 1 in gold tests. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/23919] bfd doesn't handle ELF compressed data alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=23919 --- Comment #10 from Mark Wielaard --- (In reply to cvs-com...@gcc.gnu.org from comment #6) > The master branch has been updated by H.J. Lu : > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=131a5a648d314cd15811158150573cb40eb3abd0 > > commit 131a5a648d314cd15811158150573cb40eb3abd0 > Author: H.J. Lu > Date: Tue Nov 27 06:02:36 2018 -0800 > > Initialize *uncompressed_align_pow_p to 0 > > Initialize *uncompressed_align_pow_p to 0 since *uncompressed_align_pow_p > is passed to bfd_is_section_compressed_with_header as uninitialized, > > PR binutils/23919 > * compress.c (bfd_is_section_compressed_with_header): Initialize > *uncompressed_align_pow_p to 0. I think this is correct, the uncompressed_align_pow_p wasn't set explicitly when the compressed section was gnu-zlib, in which case the alignment has to be assumed to be always 1. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/23919] bfd doesn't handle ELF compressed data alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=23919 --- Comment #11 from Mark Wielaard --- (In reply to H.J. Lu from comment #9) > This change triggered > > gcctestdir/collect-ld: warning: gdb_index_test_cdebug_gabi.o: section > .debug_str contains incorrectly aligned strings; the alignment of those > strings won't be preserved > gcctestdir/collect-ld: warning: gdb_index_test_3.o: section .debug_str > contains incorrectly aligned strings; the alignment of those strings won't > be preserved > gcctestdir/collect-ld: error: treating warnings as errors > collect2: error: ld returned 1 exit status > make[3]: *** [gdb_index_test_3] Error 1 > > in gold tests. I think this comes from do_add_input_section in gold/merge.cc. It decompresses the section, but doesn't use ch_addralign, but this->addralign(), when calculating the alignment constraint. -- You are receiving this mail because: You are on the CC list for the bug.
