[Bug binutils/28791] [z80-unknown-elf-as]: new unexpected overflow warning in v2.37
https://sourceware.org/bugzilla/show_bug.cgi?id=28791 --- Comment #8 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a58b0053f4c4b4f0089f3985a41d0deac4c59ea4 commit a58b0053f4c4b4f0089f3985a41d0deac4c59ea4 Author: Nick Clifton Date: Mon Mar 21 11:33:59 2022 + z80 assembler: Fix new unexpected overflow warning in v2.37 PR 28791 * config/tc-z80.c (emit_data_val): Do not warn about overlarge constants generated by bit manipulation operators. * testsuite/gas/z80/pr28791.s: New test source file. * testsuite/gas/z80/pr28791.d: New test driver file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28791] [z80-unknown-elf-as]: new unexpected overflow warning in v2.37
https://sourceware.org/bugzilla/show_bug.cgi?id=28791 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #9 from Nick Clifton --- Patch applied. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28867] Mingw to generate bogus.o on French locale
https://sourceware.org/bugzilla/show_bug.cgi?id=28867 --- Comment #9 from Nick Clifton --- (In reply to Eric Pouech from comment #8) Hi Eric, > -<203> DW_AT_decl_column : 49 > +<203> DW_AT_decl_column : 15 > just to say I don't grasp where this modification in dwarf's column comes > from > (AFAICT fail.s has column information which is consistent with fail.o) > > I have no evidence that this variation in the .o files has any relationship > with the failure (or hasn't)... but since we can't grasp anything serious, > it may be worth checking ;-) Sorry - I think that that is a red herring. > maybe, it does ring some bell to you? Not really. I think that we are looking at three possibilities here: * A bug in the compiler used to build the assembler that you are using, so that it mis-behaves in a subtle manner. Since I am probably using a different compiler to build my sources, this might explain why I cannot reproduce the bug. * A hardware failure on your test machine (a bad memory chip maybe ?) Pretty unlikely I know, but it would explain why only you seem to have these problems. If true though, I would expect you to be encountering problems with other, unrelated programs. * An uninitialised memory bug in the assembler sources, such that a random value is being used somewhere. Different host environments tend to initialise memory differently, so this might explain why it works for me (eg because on my host, allocated memory is always initialised to zero, even if not specifically requested). I am not sure what to suggest now. You could try running the assembler under a tool like valgrind and see if that shows up anything. Or compile the assembler with address sanitization and/or undefined behaviour sanitization enabled and then see if something is detected. There are also memory testers that you can run to see if your memory banks are behaving correctly. Might be worth a shot, even if it is just for peace of mind. Sorry - I am not sure what else I can do. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28978] [2.36 Regression] O(n²) when parsing DWARF2 info
https://sourceware.org/bugzilla/show_bug.cgi?id=28978 --- Comment #1 from Steinar H. Gunderson --- Created attachment 14028 --> https://sourceware.org/bugzilla/attachment.cgi?id=14028&action=edit Proposed patch I've taken a stab at a fix. I wonder if it's overly conservative, ie., we will never need the fallback, but it should at least be reasonably safe. I've verified that the slowdown disappears when applying it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28867] Mingw to generate bogus.o on French locale
https://sourceware.org/bugzilla/show_bug.cgi?id=28867 --- Comment #10 from Eric Pouech --- > Not really. I think that we are looking at three possibilities here: > > * A bug in the compiler used to build the assembler that you > are using, so that it mis-behaves in a subtle manner. Since > I am probably using a different compiler to build my sources, > this might explain why I cannot reproduce the bug. > > * A hardware failure on your test machine (a bad memory chip maybe ?) > Pretty unlikely I know, but it would explain why only you seem to > have these problems. If true though, I would expect you to be > encountering problems with other, unrelated programs. > > * An uninitialised memory bug in the assembler sources, such that a > random value is being used somewhere. Different host environments > tend to initialise memory differently, so this might explain why > it works for me (eg because on my host, allocated memory is always > initialised to zero, even if not specifically requested). when it broke, I tried several recompilation (of the .o file, of the whole directory of the .o file, of the whole tree), with the same results each time. anyway, since I cannot reproduce *today* either the issue, feel free to close the bug either, it's a real issue that has been fixed by one of the updates (good) or the sequence that triggers is still unknown (but keeping the bug open will not help here) thanks for your time Eric -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28978] [2.36 Regression] O(n²) when parsing DWARF2 info
https://sourceware.org/bugzilla/show_bug.cgi?id=28978 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=30cbd32aec30b4bc13427bbd87c4c63c739d4578 commit 30cbd32aec30b4bc13427bbd87c4c63c739d4578 Author: Steiner H Gunderson Date: Mon Mar 21 14:29:12 2022 + Reduce O(n2) performance overhead when parsing DWARF unit information. PR 28978 * dwarf2.c (scan_unit_for_symbols): When performing second pass, check to see if the function or variable being processed is the same as the previous one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28978] [2.36 Regression] O(n²) when parsing DWARF2 info
https://sourceware.org/bugzilla/show_bug.cgi?id=28978 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com Last reconfirmed||2022-03-21 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||nickc at redhat dot com --- Comment #3 from Nick Clifton --- Hi Steinar, Thanks for the patch - I have gone ahead and applied it. I am not sure if the list reversal will have much affect on the performance of the code, since although it will increase the chance of a early match for the start of the scan, it will reduce the chance near the end of the scan. It does however leave open the possibility of starting the lookup_func_by_offset and lookup_var_by_offset functions at the list entry that was last successfully matched. If the scan reaches the end, then it can be restarted at the beginning of the list, but the probability is that, for ordered code, a match will be found sooner rather than later. Would you care to have a go at implementing this ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28867] Mingw to generate bogus.o on French locale
https://sourceware.org/bugzilla/show_bug.cgi?id=28867 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |NOTABUG --- Comment #11 from Nick Clifton --- Closing. For now... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28978] [2.36 Regression] O(n²) when parsing DWARF2 info
https://sourceware.org/bugzilla/show_bug.cgi?id=28978
--- Comment #4 from Steinar H. Gunderson ---
Thanks for applying!
I'm not sure if I understand what you mean. From what I can see, the reversal
is completely, 100% necessary for this patch to do its job. If not, you'll have
a miss every single time as I understand it.
E.g.: Say you have 1000 functions. When we get to the Nth
DW_TAG_{subprogram,entry_point,inlined_subroutine}, we will want them to find
function 0, 1, 2, 3, 4, etc. respectively in the list (since that's the order
they are read in). But since we only have _previous_ pointers, and
unit->function_table points to the _last_ function, it will start at 999 and
search backwards until it finds 0. There's no way for us to say “OK, last one I
saw was number 500, so let me find the pointer to 501”, because we only have a
pointer to 499. This is why I reverse the list -- so that the pointer goes to
the one we want.
>From what I can see, reversing the list takes us from a 0% hit rate to a 100%
hit rate. I'm not even sure whether lookup_func_by_offset() is needed at all
anymore (it should really never be called after the patch, if I understand
correctly), but I don't know all the logic in the function, so I left it in for
safety.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/28978] [2.36 Regression] O(n²) when parsing DWARF2 info
https://sourceware.org/bugzilla/show_bug.cgi?id=28978 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Nick Clifton --- (In reply to Steinar H. Gunderson from comment #4) > I'm not sure if I understand what you mean. From what I can see, the > reversal is completely, 100% necessary for this patch to do its job. If not, > you'll have a miss every single time as I understand it. Oh my brain is so slow! Yes you are right - the reversal is completely necessary. Sorry for the confusion. > From what I can see, reversing the list takes us from a 0% hit rate to a > 100% hit rate. I'm not even sure whether lookup_func_by_offset() is needed > at all anymore (it should really never be called after the patch, if I > understand correctly), but I don't know all the logic in the function, so I > left it in for safety. OK, then lets leave it here for now. If the issue comes up again in the future we can look into optimizing the lookup functions. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28986] New: RISC-V Binutils Lacks Support for ELF symbol table reloc info
https://sourceware.org/bugzilla/show_bug.cgi?id=28986 Bug ID: 28986 Summary: RISC-V Binutils Lacks Support for ELF symbol table reloc info Product: binutils Version: 2.37 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: john.leidel at gmail dot com Target Milestone: --- Created attachment 14030 --> https://sourceware.org/bugzilla/attachment.cgi?id=14030&action=edit driver.c, patchlib.c, makefile and run script for the bug Tested platforms: RISC-V RV64G Binutils 2.36.1 & 2.37; Ubuntu 21.04 & 21.10, respectively. Platform: SiFive HiFive Unmatched We are porting a parallel runtime library that requires us to provide support for "patching" existing system functions such as mmap/munmap/etc with user-defined functions. The process of which requires that we dlopen a new library, walks its symbol table, gather info on each symbol, then reloc the new functions into the existing runtime environment. This process requires that we use the r_info indices into the PTR in order to lookup all the provided functionality from a shared library. It appears that this information is not currently implemented for the RISC-V target. RISC-V contains the necessary macros in libdl that provide the DT_JMPREL and DT_PLTRELSZ references. However, attempted to access the contents of each DT_PLTRELSZ index causes a segmentation as these appear to not be implemented currently. The attached bug and associated makefile provide two source files. The "driver.c" is the actual code that attempts to dlopen and patch an existing function. The patchlib.c provides a sample function (patch_calloc) that should patch the existing `calloc` function call. The attached tgz includes both files, a makefile and a run script. The lack of the r_info struct being implemented induces a segmentation fault in the program as follows: $> gdb ./a.out (gdb) r ./libpatchlib.so patch_calloc 0x002aacbe in visit_symbols (inf=0x0, dlpi_addr=183251935232, table=0x8a0, table_size=456, strtab=0x568, symtab=0x2c8, dl_name=0x3fc878 "(anonymous dl @ 0x2aa000)") at driver.c:87 87 elf_sym = (char*)strtab + symtab[ELF64_R_SYM(reloc->r_info)].st_name; -- You are receiving this mail because: You are on the CC list for the bug.
Issue 43035 in oss-fuzz: binutils:fuzz_dlltool: Timeout in fuzz_dlltool
Updates: Labels: Deadline-Approaching Comment #2 on issue 43035 by sheriffbot: binutils:fuzz_dlltool: Timeout in fuzz_dlltool https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43035#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 42630 in oss-fuzz: binutils:fuzz_objdump_safe: Out-of-memory in fuzz_objdump_safe
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #3 on issue 42630 by sheriffbot: binutils:fuzz_objdump_safe: Out-of-memory in fuzz_objdump_safe https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=42630#c3 This bug has exceeded our disclosure deadline. 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.
Issue 42639 in oss-fuzz: binutils:fuzz_bfd: Heap-buffer-overflow in bfd_getl32
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #3 on issue 42639 by sheriffbot: binutils:fuzz_bfd: Heap-buffer-overflow in bfd_getl32 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=42639#c3 This bug has exceeded our disclosure deadline. 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.
Issue 42662 in oss-fuzz: binutils:fuzz_disas_ext-bfd_arch_arm: Index-out-of-bounds in print_insn_thumb32
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #3 on issue 42662 by sheriffbot: binutils:fuzz_disas_ext-bfd_arch_arm: Index-out-of-bounds in print_insn_thumb32 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=42662#c3 This bug has exceeded our disclosure deadline. 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.
Issue 42668 in oss-fuzz: binutils:fuzz_addr2line: Heap-buffer-overflow in bfd_getl32
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #3 on issue 42668 by sheriffbot: binutils:fuzz_addr2line: Heap-buffer-overflow in bfd_getl32 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=42668#c3 This bug has exceeded our disclosure deadline. 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.
Issue 42740 in oss-fuzz: binutils:fuzz_addr2line: Heap-buffer-overflow in bfd_getl16
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #3 on issue 42740 by sheriffbot: binutils:fuzz_addr2line: Heap-buffer-overflow in bfd_getl16 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=42740#c3 This bug has exceeded our disclosure deadline. 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.
Issue 42739 in oss-fuzz: binutils:fuzz_dwarf: Indirect-leak in _objalloc_alloc
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #3 on issue 42739 by sheriffbot: binutils:fuzz_dwarf: Indirect-leak in _objalloc_alloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=42739#c3 This bug has exceeded our disclosure deadline. 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.
Issue 43790 in oss-fuzz: binutils:fuzz_as: Null-dereference READ in htab_find_slot
Updates: Labels: -restrict-view-commit Comment #5 on issue 43790 by sheriffbot: binutils:fuzz_as: Null-dereference READ in htab_find_slot https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43790#c5 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.
Issue 45735 in oss-fuzz: binutils:fuzz_as: Unexpected-exit in xexit
Updates: Labels: -restrict-view-commit Comment #3 on issue 45735 by sheriffbot: binutils:fuzz_as: Unexpected-exit in xexit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45735#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 gprofng/28972] gprofng libraries should be installed under $(pkglibdir)
https://sourceware.org/bugzilla/show_bug.cgi?id=28972 --- Comment #1 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=6c924cf21caae1d6f277d281eb276b2bab2ef4ba commit 6c924cf21caae1d6f277d281eb276b2bab2ef4ba Author: Vladimir Mezentsev Date: Thu Mar 17 09:57:28 2022 -0700 Install gprofng libraries under $(pkglibdir) gprofng/ChangeLog 2022-03-21 Vladimir Mezentsev PR gprofng/28972 * gprofng/libcollector/Makefile.am: Rename lib_LTLIBRARIES to pkglib_LTLIBRARIES. Add install-data-local. * gprofng/src/Makefile.am: Likewise. * gprofng/src/envsets.cc (putenv_libcollector_ld_misc): New location of the gprofng libraries. * gprofng/configure.ac: Removed an unused GPROFNG_LIBDIR. * gprofng/Makefile.am: Removed an unused GPROFNG_LIBDIR. Add install-data-local. * gprofng/configure: Regenerate. * gprofng/Makefile.in: Likewise. * gprofng/doc/Makefile.in: Likewise. * gprofng/gp-display-htmllibcollector/Makefile.in: Likewise. * gprofng/libcollector/Makefile.in: Likewise. * gprofng/src/Makefile.in: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/28972] gprofng libraries should be installed under $(pkglibdir)
https://sourceware.org/bugzilla/show_bug.cgi?id=28972 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |2.39 Resolution|--- |FIXED --- Comment #2 from H.J. Lu --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28893] binutils-2.37: PGO build with Clang results in configure error: AR with --plugin and rc is required for LTO build
https://sourceware.org/bugzilla/show_bug.cgi?id=28893 Sam James changed: What|Removed |Added CC||sam at gentoo dot org, ||toolchain at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
