[Bug gas/16908] #line directives are ignored inside macros
https://sourceware.org/bugzilla/show_bug.cgi?id=16908 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Jan Beulich : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=969b9a36506bfb386f8ce30f88f1a6a6ebbaca6e commit 969b9a36506bfb386f8ce30f88f1a6a6ebbaca6e Author: Jan Beulich Date: Tue Dec 13 09:11:53 2022 +0100 gas: re-work line number tracking for macros and their expansions The PR gas/16908 workaround aimed at uniformly reporting line numbers to reference macro invocation sites. As mentioned in a comment this may be desirable for small macros, but often isn't for larger ones. As a first step improve diagnostics to report both locations, while aiming at leaving generated debug info unaltered. Note that macro invocation context is lost for any diagnostics issued only after all input was processed (or more generally for any use of as_*_where(), as the functions can't know whether the passed in location is related to [part of] the present stack of locations). To maintain the intended workaround behavior for PR gas/16908, a new as_where() is introduced to "look through" macro invocations, while the existing as_where() is renamed (and used in only very few places for now). Down the road as_where() will likely want to return a list of (file,line) pairs. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29851] -Wl,-z,ibtplt emits MPX jumps
https://sourceware.org/bugzilla/show_bug.cgi?id=29851 --- Comment #7 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1bf337caba91963123dcbef48c8364b1e6f9c380 commit 1bf337caba91963123dcbef48c8364b1e6f9c380 Author: H.J. Lu Date: Tue Dec 6 13:34:38 2022 -0800 gold: Remove BND from 64-bit x86-64 IBT PLT Since MPX support has been removed from x86-64 psABI, remove BND from 64-bit IBT PLT by using 32-bit IBT PLT. PR gold/29851 * x86_64.cc (Output_data_plt_x86_64_ibt<32>::first_plt_entry): Renamed to ... (Output_data_plt_x86_64_ibt::first_plt_entry): This. (Output_data_plt_x86_64_ibt<64>::first_plt_entry): Removed. (Output_data_plt_x86_64_ibt::do_fill_first_plt_entry): Drop the size == 32 check. (Output_data_plt_x86_64_ibt<32>::plt_entry): Renamed to ... (Output_data_plt_x86_64_ibt::plt_entry): This. (Output_data_plt_x86_64_ibt<64>::plt_entry): Removed. (Output_data_plt_x86_64_ibt<32>::aplt_entry): Renamed to ... (Output_data_plt_x86_64_ibt::aplt_entry): This. (Output_data_plt_x86_64_ibt<64>::aplt_entry): Removed. (Output_data_plt_x86_64_ibt::do_fill_plt_entry): Drop the size == 32 check. (Output_data_plt_x86_64_ibt::fill_aplt_entry): Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 54249 in oss-fuzz: binutils:fuzz_addr2line: Heap-use-after-free in _bfd_mips_elf_generic_reloc
Updates: Labels: -restrict-view-commit Comment #3 on issue 54249 by sheriffbot: binutils:fuzz_addr2line: Heap-use-after-free in _bfd_mips_elf_generic_reloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=54249#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug binutils/29866] Build stuck at "checking for ELF support in BFD..." for x86_64-w64-mingw32 host at canadian compilation
https://sourceware.org/bugzilla/show_bug.cgi?id=29866
--- Comment #2 from cqwrteur ---
(In reply to Alan Modra from comment #1)
> This is in libctf configure. For me, I see the following in
> libctf/config.log:
> configure:14586: checking for ELF support in BFD
> configure:14606: ./libtool --quiet --mode=link x86_64-w64-mingw32-gcc -o
> conftest.exe -I/home/alan/src/binutils-gdb/libctf/../include -I../bfd
> -I/home/alan/src/binutils-gdb/libctf/../bfd -g -O2 -L../bfd
> -L../libiberty -L../zlib -Wl,--stack,12582912 conftest.c -lbfd -liberty -lz
> >&5
> configure:14606: $? = 0
> configure:14614: result: yes
>
> So the bug report is really asking "Why does my compiler hang?", and there
> isn't any way for me to answer that.
>
> My conftest.c for the test is:
> /* confdefs.h */
> #define PACKAGE_NAME "libctf"
> #define PACKAGE_TARNAME "libctf"
> #define PACKAGE_VERSION "1.2.0"
> #define PACKAGE_STRING "libctf 1.2.0"
> #define PACKAGE_BUGREPORT ""
> #define PACKAGE_URL ""
> #define STDC_HEADERS 1
> #define HAVE_SYS_TYPES_H 1
> #define HAVE_SYS_STAT_H 1
> #define HAVE_STDLIB_H 1
> #define HAVE_STRING_H 1
> #define HAVE_MEMORY_H 1
> #define HAVE_STRINGS_H 1
> #define HAVE_INTTYPES_H 1
> #define HAVE_STDINT_H 1
> #define HAVE_UNISTD_H 1
> #define __EXTENSIONS__ 1
> #define _ALL_SOURCE 1
> #define _GNU_SOURCE 1
> #define _POSIX_PTHREAD_SEMANTICS 1
> #define _TANDEM_SOURCE 1
> #define PACKAGE "libctf"
> #define VERSION "1.2.0"
> #define LT_OBJDIR ".libs/"
> #define _FILE_OFFSET_BITS 64
> #define HAVE_STDLIB_H 1
> #define HAVE_UNISTD_H 1
> #define HAVE_SYS_PARAM_H 1
> #define HAVE_GETPAGESIZE 1
> /* end confdefs.h. */
> #include
>#include
>#include "bfd.h"
>#include "elf-bfd.h"
> int
> main ()
> {
> (void) bfd_section_from_elf_index (NULL, 0);
>return 0;
> ;
> return 0;
> }
>
> The previous failed test in the log will give you your confdefs.h, which may
> be different to mine. If you run your conftest.c through your compiler by
> hand and it hangs, then you likely have a problem with your compiler rather
> than there being a libctf configure problem.
it is just hanging for no reason
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/29866] Build stuck at "checking for ELF support in BFD..." for x86_64-w64-mingw32 host at canadian compilation
https://sourceware.org/bugzilla/show_bug.cgi?id=29866 --- Comment #3 from cqwrteur --- checking for ELF support in BFD... libtool: link: Could not determine host path corresponding to -- You are receiving this mail because: You are on the CC list for the bug.
