[Bug gold/17169] gold: many_sections_define.h test fails: argument list too long error
https://sourceware.org/bugzilla/show_bug.cgi?id=17169 Mike Frysinger changed: What|Removed |Added CC||ian at airs dot com Component|binutils|gold Summary|argument list too long |gold: |error |many_sections_define.h test ||fails: argument list too ||long error Assignee|unassigned at sourceware dot org |ccoutant at gmail dot com --- Comment #2 from Mike Frysinger --- prob easy to rewrite with a shell loop, if desired -- You are receiving this mail because: You are on the CC list for the bug.
Issue 41490 in oss-fuzz: binutils:fuzz_addr2line: Timeout in fuzz_addr2line
Updates: Labels: Deadline-Approaching Comment #3 on issue 41490 by sheriffbot: binutils:fuzz_addr2line: Timeout in fuzz_addr2line https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41490#c3 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.
[Bug binutils/28917] New: ar: r does not replace objects specified multiple times on the command line
https://sourceware.org/bugzilla/show_bug.cgi?id=28917 Bug ID: 28917 Summary: ar: r does not replace objects specified multiple times on the command line Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: vapier at gentoo dot org Target Milestone: --- testing current tree (216722984fec8aa76e2d97d7b8fcc2fb1608825b). seems to reproduce across many diff targets & config options, so i don't think they're related. $ cd binutils # Adding files one-at-a-time works correctly. $ rm -f x.a $ ./ar vrc x.a ar.o a - ar.o $ ./ar vrc x.a ar.o r - ar.o $ ./ar vrc x.a ar.o r - ar.o $ ./ar t x.a ar.o # Adding files many-at-a-time works incorrectly. $ rm -f x.a $ ./ar vrc x.a ar.o ar.o a - ar.o a - ar.o $ ar t x.a ar.o ar.o this came up because newlib uses archive-insertion-order to control overriding of common objects (i.e. C files) with machine-specific objects (i.e. asm files). it used to add objects one directory at a time, but i switched it to add them all at once (with machine objects appearing last). now we have duplicate objects in the archive. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28917] ar: r does not replace objects specified multiple times on the command line
https://sourceware.org/bugzilla/show_bug.cgi?id=28917
--- Comment #1 from Mike Frysinger ---
ugh, this appears to be undocumented behavior. i can't find anything in the
man page or manual discussing this, and the commit history predates git.
--- a/binutils/ar.c
+++ b/binutils/ar.c
@@ -1493,8 +1493,7 @@
/* For compatibility with existing ar programs, we
permit the same file to be added multiple times. */
if (FILENAME_CMP (normalize (*files_to_move, arch),
- normalize (bfd_get_filename (current), arch)) == 0
- && current->arelt_data != NULL)
+ normalize (bfd_get_filename (current), arch)) == 0)
{
bool replaced;
if (newer_only)
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/28915] dwarf2.c doesn't correctly parse DW_UT_skeleton
https://sourceware.org/bugzilla/show_bug.cgi?id=28915 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28841] ld: Customize output section type
https://sourceware.org/bugzilla/show_bug.cgi?id=28841 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=cf53a97bedd257aa6612129e4bdf8618f6a038cd commit cf53a97bedd257aa6612129e4bdf8618f6a038cd Author: Alan Modra Date: Tue Feb 22 09:20:31 2022 +1030 Re: ld: Support customized output section type "DO NOT EDIT!" says the comment at the top of bfd-in2.h. Move the new type field where it belongs. PR ld/28841 * section.c (struct bfd_section): Add type. Formatting. (BFD_FAKE_SECTION): Formatting. * bfd-in2.h: Regenerate. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28915] New: dwarf2.c doesn't correctly parse DW_UT_skeleton
https://sourceware.org/bugzilla/show_bug.cgi?id=28915
Bug ID: 28915
Summary: dwarf2.c doesn't correctly parse DW_UT_skeleton
Product: binutils
Version: 2.39 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: jakub at redhat dot com
Target Milestone: ---
In https://bugzilla.redhat.com/show_bug.cgi?id=2052228 ld reports weird
/usr/bin/ld: /usr/bin/ld: DWARF error: could not find abbrev number 62
diagnostics. The object file in question uses -gsplit-dwarf and
readelf -wi
obj/third_party/swiftshader/src/Reactor/swiftshader_subzero/IceTargetLoweringX8664.o
Contents of the .debug_info section:
Compilation Unit @ offset 0x0:
Length:0x2d (32-bit)
Version: 5
Unit Type: DW_UT_skeleton (4)
Abbrev Offset: 0x0
Pointer Size: 8
DWO ID:0xaff01133f289df3e
<0><14>: Abbrev Number: 1 (DW_TAG_skeleton_unit)
<15> DW_AT_ranges : 0xc
<19> DW_AT_low_pc : 0x0
<21> DW_AT_stmt_list : 0x0
<25> DW_AT_dwo_name: (indirect string, offset: 0x39):
obj/third_party/swiftshader/src/Reactor/swiftshader_subzero/IceTargetLoweringX8664.dwo
<29> DW_AT_comp_dir: (indirect string, offset: 0x0):
/builddir/build/BUILD/chromium-98.0.4758.80/out/Headless
<2d> DW_AT_GNU_pubnames: 1
<2d> DW_AT_addr_base : 0x8
62 is equal to 0x3e, i.e. the first byte of DWO ID.
So, this seems to be a bug in bfd/dwarf2.c (parse_comp_unit) which for
DW_UT_type does:
if (unit_type == DW_UT_type)
{
/* Skip type signature. */
info_ptr += 8;
/* Skip type offset. */
info_ptr += offset_size;
}
but should at least also:
else if (unit_type == DW_UT_skeleton || unit_type == DW_UT_split_compile)
/* Skip DWO ID. */
info_ptr += 8;
at minimum.
Minimal reproducer would be something like:
cat > test.c <<\EOF
int foo (void);
int
main ()
{
return foo ();
}
EOF
gcc -gdwarf-5 -gsplit-dwarf -o test{,.c}
The above will just avoid interpreting bytes in the DWO ID as abbrev number
followed by its attribute values etc., for reallly supporting split DWARF more
work would be needed (actually reading the DWO ID, read DW_AT_dwo_name and
DW_AT_comp_dir in the DW_TAG_skeleton_unit, try to find the dwo file and read
it in addition to the skeleton stuff (some sections remain in the .o file like
.debug_addr, others are in the dwo file and others are in both).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #37 from Torbjörn SVENSSON --- (In reply to Fred Eisele from comment #35) > Created attachment 13990 [details] > This patch handles long paths, relative paths, and paths containing '.' and > '..' on WIN32 I think the conversion from slash to backslash should be done after the call to MultiByteToWideChar to ensure that it's not part of a multi-byte sequence of, for example, a UTF-8 encoded string. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/15133] ar: x should support setting of output folder
https://sourceware.org/bugzilla/show_bug.cgi?id=15133 Mike Frysinger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Summary|Archive "ar" tool should|ar: x should support |support setting of output |setting of output folder |folder | URL||https://sourceware.org/git/ ||?p=binutils-gdb.git;a=commi ||t;h=197245e341aeb1b5da8ee5f ||be5d6c49de650fb89 Target Milestone|--- |2.34 --- Comment #1 from Mike Frysinger --- ar now supports --output as of binutils-2.34 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=197245e341aeb1b5da8ee5fbe5d6c49de650fb89 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/12283] bfd/doc doesn't support parallel build
https://sourceware.org/bugzilla/show_bug.cgi?id=12283 Mike Frysinger changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||vapier at gentoo dot org --- Comment #1 from Mike Frysinger --- not sure preciously what you're highlighting, but i think this is resolved with the recent rewrites in bfd/doc/local.mk -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/14539] ar can't generate correct archive
https://sourceware.org/bugzilla/show_bug.cgi?id=14539 Mike Frysinger changed: What|Removed |Added Resolution|--- |NOTABUG CC||vapier at gentoo dot org Status|NEW |RESOLVED --- Comment #1 from Mike Frysinger --- i am by no means a fortran expert, so if i misunderstand how it works, feel free to correct & reopen the fact that this linking works: > gfortran test_a.o lib_a.a -o a.exe implies that the `use refs_a` is a "weak reference". that means the linker is not required to pull in objects from an archive (.a) to satisfy such symbols alone. this is how the linker has always behaved, and is always going to behave. if you want to force linking in all the objects from the archive, you can use the --whole-archive option like: gfortran test_a.o -Wl,--whole-archive lib_a.a -Wl,--no-whole-archive -o a.exe from ar's pov, it is working correctly: it created an archive with an object. it has nothing else to do. from ld's pov, it is working correctly: the symbol is already satisfied, and there's no objects it needs to pull out of the .a to satisfy missing symbols. -- You are receiving this mail because: You are on the CC list for the bug.
