[Bug ld/31644] [Regression] libstdc++prettyprinters/debug.[cc|cxx11.cc] failing to build - linker error
https://sourceware.org/bugzilla/show_bug.cgi?id=31644 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2024-04-16 --- Comment #3 from H.J. Lu --- I can't reproduce it on Linux/x86-64. If it still fails with master branch, please find a testcase which can be reproduced on Linux/x86-64. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31644] [Regression] libstdc++prettyprinters/debug.[cc|cxx11.cc] failing to build - linker error
https://sourceware.org/bugzilla/show_bug.cgi?id=31644 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- Note also the jenkins does not keep around the .log files from the testsuite is it is not very useful info except something failed ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31644] [Regression] libstdc++prettyprinters/debug.[cc|cxx11.cc] failing to build - linker error
https://sourceware.org/bugzilla/show_bug.cgi?id=31644 Sam James changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=114724 CC||hjl.tools at gmail dot com, ||sam at gentoo dot org --- Comment #1 from Sam James --- -> ccing hj -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31644] New: [Regression] libstdc++prettyprinters/debug.[cc|cxx11.cc] failing to build - linker error
https://sourceware.org/bugzilla/show_bug.cgi?id=31644 Bug ID: 31644 Summary: [Regression] libstdc++prettyprinters/debug.[cc|cxx11.cc] failing to build - linker error Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: carlos.seo at linaro dot org Target Milestone: --- The following tests are failing to build: === libstdc++ tests === Running libstdc++:libstdc++-prettyprinters/prettyprinters.exp ... UNRESOLVED: libstdc++-prettyprinters/debug.cc compilation failed to produce executable UNRESOLVED: libstdc++-prettyprinters/debug_cxx11.cc compilation failed to produce executable Possible culprit, according to the post-commit CI is: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=c0419c024bf922128131671e40de0aed736e38ed CI logs: https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/binutils/sha1/c0419c024bf922128131671e40de0aed736e38ed/tcwg_gnu_native_check_gcc/master-aarch64/details.txt https://ci.linaro.org/job/tcwg_gnu_native_check_gcc--master-aarch64-build/1047/artifact/artifacts -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31527] gdb is not working for UNC path
https://sourceware.org/bugzilla/show_bug.cgi?id=31527 Nick Clifton changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Nick Clifton --- Hi Simon, Thanks for the revised patch. It looks a lot better to me now and so I have gone ahead and checked it in. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31527] gdb is not working for UNC path
https://sourceware.org/bugzilla/show_bug.cgi?id=31527 --- Comment #15 from Sourceware Commits --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9dd918142787246ea7ed53494d9cbc6b51486133 commit 9dd918142787246ea7ed53494d9cbc6b51486133 Author: Nick Clifton Date: Mon Apr 15 16:42:15 2024 +0100 Remove dependency upon shlwapi library when building BFD for Windows/MinGW environments. PR 31527 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31540] objcopy, ELF_SECTION_IN_SEGMENT_1 section to segment mapping seems wrong
https://sourceware.org/bugzilla/show_bug.cgi?id=31540 --- Comment #7 from vijay Shankar --- (In reply to Nick Clifton from comment #6) > Right - well the patch looks good to me, and did not trigger any problems, > so I have gone ahead and checked it in. Thanks Nick. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31540] objcopy, ELF_SECTION_IN_SEGMENT_1 section to segment mapping seems wrong
https://sourceware.org/bugzilla/show_bug.cgi?id=31540 --- Comment #5 from Sourceware Commits --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ccbf42ec88f3e8bbb74dbdc1d6c9da3a9d805cff commit ccbf42ec88f3e8bbb74dbdc1d6c9da3a9d805cff Author: Vijay Shankar Date: Mon Apr 15 16:27:21 2024 +0100 When mapping sections to segments ensure that we do not add sections whose VMA->LMA relationship does not match the relationship of earlier sections in the segment. PR 31540 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31540] objcopy, ELF_SECTION_IN_SEGMENT_1 section to segment mapping seems wrong
https://sourceware.org/bugzilla/show_bug.cgi?id=31540 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Nick Clifton --- Right - well the patch looks good to me, and did not trigger any problems, so I have gone ahead and checked it in. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31540] objcopy, ELF_SECTION_IN_SEGMENT_1 section to segment mapping seems wrong
https://sourceware.org/bugzilla/show_bug.cgi?id=31540 --- Comment #4 from vijay Shankar --- > Can you confirm that the patch fixes the problem you initially reported ? Yes, can confirm that the patch does fix the issue Here's section to segment mapping with and without patch without change --SEGMAP-- LOAD: .eh_frame --SEGMAP-- LOAD: .text --SEGMAP-- LOAD: .data .bss .tbss .sdata --SEGMAP-- TLS: .tbss --SEGMAP-- STACK: ./objcopy: stVzY0CU: section `.data' can't be allocated in segment 0 LOAD: .tbss .data .bss .sdata ./objcopy: stVzY0CU: section `.bss' can't be allocated in segment 0 LOAD: .tbss .data .bss .sdata with change --SEGMAP-- LOAD: .eh_frame --SEGMAP-- LOAD: .text --SEGMAP-- LOAD: .data .bss .sdata --SEGMAP-- TLS: .tbss --SEGMAP-- STACK: -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31540] objcopy, ELF_SECTION_IN_SEGMENT_1 section to segment mapping seems wrong
https://sourceware.org/bugzilla/show_bug.cgi?id=31540 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED CC||nickc at redhat dot com Ever confirmed|0 |1 Last reconfirmed||2024-04-15 Assignee|unassigned at sourceware dot org |nickc at redhat dot com --- Comment #3 from Nick Clifton --- (In reply to vijay Shankar from comment #2) > I have a patch suggestion for this issue I am running the patch through my test farm and so far it is looking good. Can you confirm that the patch fixes the problem you initially reported ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31527] gdb is not working for UNC path
https://sourceware.org/bugzilla/show_bug.cgi?id=31527 Simon Cook changed: What|Removed |Added Attachment #15460|0 |1 is obsolete|| --- Comment #14 from Simon Cook --- Created attachment 15464 --> https://sourceware.org/bugzilla/attachment.cgi?id=15464=edit V2 Patch to fix issue, and cover more path variants I've thought about this more over the weekend, and refactored this a bit more to make it more robust, and more accurately cover relative paths when the current working directory isn't a DOS path. I've updated the comments to explain the methodology, but essentially these conversions are done based on the input string: - \\?\ -> don't touch, already in form - \\xyz\... -> \\?\UNC\xyz\... (keeping a single \ after UNC to keep it a valid input) - C:\xyz... -> \\?\C:\... - test.o, ../test.o, etc. -> check current working directory for correct prefix, such that if e.g. CWD is C:\ we end up with \\?\C:\test.o, or \\server\share\ becomes \\?\UNC\server\share\test.o I've done some more testing with a small program feeding various strings into _bfd_real_fopen both when running from local disk and network share and I think the output is now correct in all cases. I did think could this be simplified as it feels like I'm repeating myself, but the side effect of the early tests being on char strings and the later tests being on wchar_t strings as provided by Windows is a bit unfortunate. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 65819 in oss-fuzz: binutils:fuzz_disassemble: ASSERT: value <= 0x4 && aarch64_get_qualifier_standard_value (qualifier) == value
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #4 on issue 65819 by sheriffbot: binutils:fuzz_disassemble: ASSERT: value <= 0x4 && aarch64_get_qualifier_standard_value (qualifier) == value https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65819#c4 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 66024 in oss-fuzz: binutils:fuzz_objdump_safe: Timeout in fuzz_objdump_safe
Updates: Labels: Deadline-Approaching Comment #2 on issue 66024 by sheriffbot: binutils:fuzz_objdump_safe: Timeout in fuzz_objdump_safe https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=66024#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.
Re: Objcopy seems to consider tbss part of PTLOAD
Raised bugzilla for the same :https://sourceware.org/bugzilla/show_bug.cgi?id=31540updated with suggested patch.Thank you.
[Bug binutils/31540] objcopy, ELF_SECTION_IN_SEGMENT_1 section to segment mapping seems wrong
https://sourceware.org/bugzilla/show_bug.cgi?id=31540
--- Comment #2 from vijay Shankar ---
I have a patch suggestion for this issue
added check to copy_private_bfd_data so that sections with inconsistent
relation between vma and lma go to re-write im not sure how this will affect
other cases maybe linker scripts? waiting on experts opinion on this change.
alternative way would be to exclude tbss from PT_LOAD by adding checks in
releavent places ( ELF_SECTION_IN_SEGMENT_1, make_mapping ).
diff --git a/bfd/elf.c b/bfd/elf.c
index c305b40e..b45e1eee 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -8394,7 +8394,7 @@ copy_private_bfd_data (bfd *ibfd, bfd *obfd)
/* Check to see if any sections in the input BFD
covered by ELF program header have changed. */
Elf_Internal_Phdr *segment;
- asection *section, *osec;
+ asection *section, *osec, *prev;
unsigned int i, num_segments;
Elf_Internal_Shdr *this_hdr;
const struct elf_backend_data *bed;
@@ -8425,7 +8425,7 @@ copy_private_bfd_data (bfd *ibfd, bfd *obfd)
|| segment->p_type == PT_DYNAMIC))
goto rewrite;
- for (section = ibfd->sections;
+ for (section = ibfd->sections,prev=section;
section != NULL; section = section->next)
{
/* We mark the output section so that we know it comes
@@ -8440,16 +8440,21 @@ copy_private_bfd_data (bfd *ibfd, bfd *obfd)
{
/* FIXME: Check if its output section is changed or
removed. What else do we need to check? */
+ /* make sure this sections vma and lma relation is
+same as previous section otherwise it needs a
+rewrite */
if (osec == NULL
|| section->flags != osec->flags
|| section->lma != osec->lma
|| section->vma != osec->vma
|| section->size != osec->size
|| section->rawsize != osec->rawsize
- || section->alignment_power != osec->alignment_power)
+ || section->alignment_power != osec->alignment_power
+ || section->lma - section->vma != prev->lma - prev->vma)
goto rewrite;
}
}
+ prev = section;
}
/* Check to see if any output section do not come from the
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/31540] objcopy, ELF_SECTION_IN_SEGMENT_1 section to segment mapping seems wrong
https://sourceware.org/bugzilla/show_bug.cgi?id=31540
--- Comment #1 from vijay Shankar ---
I have a patch suggestion for this issue
added check to copy_private_bfd_data so that sections with inconsistent
relation between vma and lma go to re-write im not sure how this will affect
other cases maybe linker scripts? waiting on experts opinion on this change.
alternative way would be to exclude tbss from PT_LOAD by adding checks in
releavent places ( ELF_SECTION_IN_SEGMENT_1, make_mapping ).
diff --git a/bfd/elf.c b/bfd/elf.c
index c305b40e..b45e1eee 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -8394,7 +8394,7 @@ copy_private_bfd_data (bfd *ibfd, bfd *obfd)
/* Check to see if any sections in the input BFD
covered by ELF program header have changed. */
Elf_Internal_Phdr *segment;
- asection *section, *osec;
+ asection *section, *osec, *prev;
unsigned int i, num_segments;
Elf_Internal_Shdr *this_hdr;
const struct elf_backend_data *bed;
@@ -8425,7 +8425,7 @@ copy_private_bfd_data (bfd *ibfd, bfd *obfd)
|| segment->p_type == PT_DYNAMIC))
goto rewrite;
- for (section = ibfd->sections;
+ for (section = ibfd->sections,prev=section;
section != NULL; section = section->next)
{
/* We mark the output section so that we know it comes
@@ -8440,16 +8440,21 @@ copy_private_bfd_data (bfd *ibfd, bfd *obfd)
{
/* FIXME: Check if its output section is changed or
removed. What else do we need to check? */
+ /* make sure this sections vma and lma relation is
+same as previous section otherwise it needs a
+rewrite */
if (osec == NULL
|| section->flags != osec->flags
|| section->lma != osec->lma
|| section->vma != osec->vma
|| section->size != osec->size
|| section->rawsize != osec->rawsize
- || section->alignment_power != osec->alignment_power)
+ || section->alignment_power != osec->alignment_power
+ || section->lma - section->vma != prev->lma - prev->vma)
goto rewrite;
}
}
+ prev = section;
}
/* Check to see if any output section do not come from the
--
You are receiving this mail because:
You are on the CC list for the bug.
