[Bug binutils/29489] dlltool is not deterministic
https://sourceware.org/bugzilla/show_bug.cgi?id=29489 --- Comment #3 from Nick Clifton --- Created attachment 14284 --> https://sourceware.org/bugzilla/attachment.cgi?id=14284&action=edit Proposed Patch Hi Mike, Thanks - that makes things clearer. Please could you try out the uploaded patch to see if it does what you expect. (Note - I do not have a cygwin/mingw test environment, so I have not been able to test the patch thoroughly). Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29494] Trailing jump table leads to "Error: unaligned opcodes detected in executable segment" on ARM thumb
https://sourceware.org/bugzilla/show_bug.cgi?id=29494 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Angus, Hmmm, this is a tricky one. The easiest solution for us would be to have gcc always ensure that the end of the jump table is aligned to a 2-byte boundary. (It does this if the table is in the middle of the code, so why not at the end as well ?) Since that is unlikely to happen ... the next easiest thing to do would be to downgrade the error message to a warning message. But users will still complain, even if they are now getting working binaries. The problem is - how can the assembler determine that this is the last byte of a code section, and that it is an offset byte and not an instruction. Not a simple task. Also we really need a generic solution since there is no reason why this should just be an ARM specific problem. Hmmm - do we know if .cfi_endproc will always appear at the end of a function ? If so then maybe that pseudo-op could be extended to align the end of the function up to the next suitable boundary ? I think that I need to think on this some more... Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
Issue 47637 in oss-fuzz: binutils:fuzz_nm: Crash in filter_symbols
Updates: Labels: Deadline-Approaching Comment #2 on issue 47637 by sheriffbot: binutils:fuzz_nm: Crash in filter_symbols https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47637#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - 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.
Issue 49882 in oss-fuzz: binutils:fuzz_disas_ext-bfd_arch_i386: Abrt in i386_dis_printf
Updates: Labels: -restrict-view-commit Comment #3 on issue 49882 by sheriffbot: binutils:fuzz_disas_ext-bfd_arch_i386: Abrt in i386_dis_printf https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49882#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/29075] objdump -S does not support debuginfod
https://sourceware.org/bugzilla/show_bug.cgi?id=29075 --- Comment #19 from Aaron Merey --- (In reply to Nick Clifton from comment #18) > > and try to keep any additional debuginfod support > > contained in objdump. > > That would be my preference too. If possible it might be best to put most of > the new code into binutils/dwarf.c since that is turning into a sort of > bfd-free library for the DWARF needs of the binutils tools. So any > improvements > might help other tools like readelf or addr2line. Hi Nick, I've been experimenting with trying to get things working using just the existing call to bfd_find_nearest_line_discriminator in objdump.c. Passing the bfd object of the separate debuginfo instead of the bfd of the parent file seems to work unless a .gnu_debugaltlink file exists. In this case the bfd library tries to reopen this file in read_alt_indirect_stirng and read_alt_indirect_ref but fails to find it since it isn't aware of debuginfod. One solution to this that avoids adding debuginfod support to libbfd as well as implementing a new find_nearest_line in binutils/dwarf.c is to add a _bfd_elf_find_nearest_line_with_gnu_debugaltlink that is based on _bfd_elf_find_nearest_line but it includes an additional bfd* parameter for the debugaltlink file. Since the file is manually specified libbfd doesn't have to search for it. I think this solution is the simplest way to fully implement debuginfod support for objdump -S and it can be used by addr2line and readelf as well. WDYT? -- You are receiving this mail because: You are on the CC list for the bug.
