[Bug binutils/29312] Stack overflow in demangle_const() and demangle_path_maybe_open_generics(), cxxfilt
https://sourceware.org/bugzilla/show_bug.cgi?id=29312 --- Comment #7 from joseph at codesourcery dot com --- On Fri, 1 Jul 2022, nickc at redhat dot com wrote: > Good news: The bug has already been reported: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105039 > > Bad news: The patch that fixes the problem has not been reviewed or > applied to the gcc sources. It was approved on Sunday: https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597275.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprof/28962] libcollector: Error: invalid attempt to declare external version name as default in symbol `posix_spawn@@GLIBC_2.15
https://sourceware.org/bugzilla/show_bug.cgi?id=28962 --- Comment #1 from joseph at codesourcery dot com --- Code defining versioned symbols should use the symver attribute to define those symbols when available (when compiling with GCC 10 and later), instead of inline asm, to be compatible with LTO (it probably can't work very reliably with LTO when built with older compilers). (Note: I haven't tested whether using the attribute actually helps here, but I expect it to be necessary.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27519] GNU AS does not support SUBSPL syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=27519 --- Comment #1 from joseph at codesourcery dot com --- You should use the ".syntax unified" directive. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/27299] git hooks should not require ISO-8859-15 encoding in git logs
https://sourceware.org/bugzilla/show_bug.cgi?id=27299 --- Comment #1 from joseph at codesourcery dot com --- If you don't want that check then set no-rh-character-range-check = true in the hooks configuration (the file project.config on ref refs/meta/config), a feature added at my request when updating the version of the hooks used by GCC as I didn't think that character set check would be appropriate for GCC. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/23731] Building from git issues Ubuntu
https://sourceware.org/bugzilla/show_bug.cgi?id=23731 --- Comment #4 from joseph at codesourcery dot com --- The purpose of "missing" as explained in the automake manual isn't to replace the missing tools, just to give a more informative error message about them being missing. -- 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/23567] much larger static binaries compared to a few months ago
https://sourceware.org/bugzilla/show_bug.cgi?id=23567 --- Comment #9 from joseph at codesourcery dot com --- I believe the security reason for separate-code is the risk that rodata could contain byte patterns that can be used as a Spectre gadget if branch predication state is manipulated so that an address in rodata is speculated as the target of a branch (this of course only helps if the processor checks page permissions before speculative execution). -- 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/22962] [RISCV] add abi subdirectories support to ld
https://sourceware.org/bugzilla/show_bug.cgi?id=22962 --- Comment #10 from joseph at codesourcery dot com --- Again, the quoted error is about a search that uses -rpath-link paths but *not* -L paths. GCC uses the right -L paths automatically, but LIBPATH_SUFFIX settings in binutils are needed to get the right -rpath-link paths used automatically. -- 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/22962] [RISCV] add abi subdirectories support to ld
https://sourceware.org/bugzilla/show_bug.cgi?id=22962 --- Comment #6 from joseph at codesourcery dot com --- STARTFILE_PREFIX_SPEC may be needed for the reasons I described in <https://gcc.gnu.org/ml/gcc/2016-12/msg00013.html> - the combination of sysroot suffixes with MULTILIB_OSDIRNAMES. It wouldn't however help with the issue described in this bug, which relates to ld's attempt to emulate dynamic linker search rules to find indirect shared library dependencies (shared libraries listed in DT_NEEDED of a shared library linked against, but not directly named in -l options). See elf32.em: /* We need to find this file and include the symbol table. We want to search for the file in the same way that the dynamic linker will search. That means that we want to use rpath_link, rpath, then the environment variable LD_LIBRARY_PATH (native only), then the DT_RPATH/DT_RUNPATH entries (native only), then the linker script LIB_SEARCH_DIRS. We do not search using the -L arguments. Not using -L arguments, and avoiding a need for explicit -rpath-link, means that default library directories not called just "lib" should have corresponding LIBPATH_SUFFIX settings. If a distribution uses library directories that are not the default ones used by GCC and glibc to install each multilib, then it should have corresponding binutils changes to adjust the default search paths. The GCC support for Debian-style multiarch directory arrangements is upstream, but that for binutils and glibc isn't. -- 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/19356] unwind stack failed if stack including syscall on armv7
https://sourceware.org/bugzilla/show_bug.cgi?id=19356 --- Comment #3 from joseph at codesourcery dot com --- If the .os file for syscall that was linked into libc.so did not have unwind info or had correct unwind info, but libc.so applies unwind info from another function to syscall, then the bug is in ld. -- 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 gas/19109] Cannot configure default flag_compress_debug
https://sourceware.org/bugzilla/show_bug.cgi?id=19109 --- Comment #11 from joseph at codesourcery dot com --- On Mon, 12 Oct 2015, sch...@linux-m68k.org wrote: > I'd expect the option's default to be os-dependent, not arch-dependent. I agree, as I said in <https://sourceware.org/ml/binutils/2014-12/msg00154.html>. -- 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 gas/18826] REL vs RELA relocations by default in the ARM backend
https://sourceware.org/bugzilla/show_bug.cgi?id=18826 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- In principle BFD supports mixed REL / RELA relocations in a single input object file. I think the tic6x back end supports it, for example (or at least was meant to, but it's a while since I did anything with that back end), and some MIPS cases may support it. I don't think the ARM back end has such support (although I think it's strictly required by the EABI - that is, valid EABI-conforming objects may mix REL and RELA). I don't know if mixing REL and RELA on *output* is supported at all by 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 gas/18198] On ARM, instruction and data endianness cannot differ
https://sourceware.org/bugzilla/show_bug.cgi?id=18198 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- The way this works is that you assemble with -EB (both instructions and data big-endian) and then link with --be8 (which reverses the endianness of instructions back to little-endian, using the EABI mapping symbols to distinguish instructions and data and to tell which instructions are ARM and which are Thumb). GCC knows to pass --be8 when linking (without -r) for v7-A processors for big-endian. -- 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/17531] readelf crashes on fuzzed samples
https://sourceware.org/bugzilla/show_bug.cgi?id=17531 --- Comment #69 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Mon, 12 Jan 2015, cvs-commit at gcc dot gnu.org wrote: (xcalloc2): New function. Like xcalloc, but checks for overflow. * dwarf.h (xcalloc2): Prototype. This should not be needed. xcalloc calls calloc, which should check for overflow itself. I see libiberty has a broken version of calloc, but since calloc is a C89 function no modern system should be using libiberty's version. If we wish to allow for systems with broken calloc, libiberty's configure should detect such systems (based on a blacklist of broken systems) and substitute a working calloc. (On the other hand, all the allocation macros in libiberty.h that do multiplications do need replacing by versions that check for overflow - that is, the existing macros need to be made to check for overflow, rather than having separate checking and non-checking versions.) -- 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/14768] Checklist: Binutils Migration To Git
http://sourceware.org/bugzilla/show_bug.cgi?id=14768 --- Comment #17 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Fri, 30 Aug 2013, hp at sourceware dot org wrote: * Git migrations and work-flow offered for remaining projects (like newlib and cgen). That should be in the form: document in detail how the migration worked, so that if the newlib community chooses to move to git, it has the benefit of documentation of the process when replicating it to move to its own git repository. * (related:) Do not set in stone this git repo as binutils+gdb in any documentation changes and names assuming we agree that other projects may be added. Rather, I say the repository should be exactly 6(b) from http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html (subject to confirming the exact set of directories with only Attic contents in CVS whose history gets converted). (c), (d), (e), (f), (g) and each of the three parts of (h) should, if someone in their respective communities wishes to convert them away from CVS, be converted independently to separate repositories (based on shared toplevel code only when it's actually used); (a) may be convenient to avoid shared files diverging, but is not required. (I do not definitively assert whether (c) newlib and (d) winsup should be separate or a single repository; that's for the relevant communities to work out. I am confident that all the other divisions make sense.) -- 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/14768] Checklist: Binutils Migration To Git
http://sourceware.org/bugzilla/show_bug.cgi?id=14768 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-10-25 22:06:51 UTC --- My past messages to the various lists discuss the relevant issues. I still think a combined binutils+gdb git repository (without any of the other pieces from the src repository) is probably the best trade-off. http://sourceware.org/ml/gdb/2011-10/msg00134.html is one of my more recent messages on this subject (you'll find plenty more relevant information in that thread and in the other threads on the subject over the past several years on both binutils and GDB project list). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/13125] readelf exits 0 when DWARF information requested but none present
http://sourceware.org/bugzilla/show_bug.cgi?id=13125 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-08-24 15:25:49 UTC --- I've certainly used readelf in scripts to process lots of ELF files, some of which may have debug info and some of which may not, the idea being to process what debug info there is. In my view, it's an error if the input is not an ELF file, but if it's ELF then empty output and success is the appropriate result if it simply doesn't have that particular sort of debug info. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/4966] linker incorrectly prepends sysroot to absolute path
--- Additional Comments From joseph at codesourcery dot com 2008-04-03 03:36 --- Subject: Re: linker incorrectly prepends sysroot to absolute path Thank you for your message. I am away from my email from 3 to 7 April. Messages sent before 3 April will be read before I go away; messages sent during that period will be read after I return. If you need a response before my return, please contact Nathan Sidwell [EMAIL PROTECTED]. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4966 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
