[Bug binutils/29009] Add pei-risc64 support for native EFI support
https://sourceware.org/bugzilla/show_bug.cgi?id=29009 Mircea Gherzan changed: What|Removed |Added CC||mgherzan at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29987] bfd/archive.c:1447: undefined reference to `filename_ncmp'
https://sourceware.org/bugzilla/show_bug.cgi?id=29987 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Vladimir Mezentsev : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c2a5d74050ea9d7897b4122ef57c627d395683b3 commit c2a5d74050ea9d7897b4122ef57c627d395683b3 Author: Vladimir Mezentsev Date: Thu Jan 12 12:51:48 2023 -0800 gprofng: PR29987 bfd/archive.c:1447: undefined reference to `filename_ncmp' gprofng/ChangeLog 2023-01-12 Vladimir Mezentsev PR gprofng/29987 * configure.ac: Remove dependencies on libbfd and libiberty. * gprofng/src/Makefile.am: Likewise. * configure: Rebuild. * Makefile.in: Rebuild. * src/Makefile.in: Rebuild. * doc/Makefile.in: Rebuild. * gp-display-html/Makefile.in: Rebuild. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993 --- Comment #5 from Frank Ch. Eigler --- I have not previously looked into the annotation notes in great detail, so am working from a tyro understanding of https://fedoraproject.org/wiki/Toolchain/Watermark . Please excuse my naivite with the following: - The "merging the notes, following rules must be observed" list of that wiki page is lacking rationale. Any transformation that meets the specifications set in the previous paragraphs should be fine. - For example, "Preserve any NT_GNU_BUILD_ATTRIBUTE_FUNC notes" can't be right. Previous to --merge-notes, there are millions of these "func" notes in libxul.so, but after, only a few dozen. (Yes, it turns out there are hundreds of thousands of merges occurring, so that inner loop does likely run many more than 16 iterations.) - For example, "Preserve the ordering of the notes" can't be that serious if the previous prose indicates entries cannot be assumed to be sorted by address, nor can the special version tags be assumed to be at the front. So, as for a more efficient merging algorithm, I would explore something like this: 1) First pass: load all the notes of the bfd, sort them by start-address, grouping them into separate lists (by attribute "owner", "value", "type"). This is so that each list consists of exactly those entries that could be merged, based on the entries' address ranges. 2) For each of those note group lists: 2a) Create an output list for the new merged notes in this group. 2b) Iterate entries by address. 2b1) Copy the current entry into the output list. We'll merge others into this one. 2b2) If the next entry adjoins/overlaps this entry, merge the start/end range of the new entry. Try this again for subsequent entries until finding one that does not adjoin/overlap. Mark that next entry as the next one for iteration at step 2b) 3) Write the output lists into the output elf file, replacing the previous .gnu.build.attributes. This should be O(N log N) time algorithm for sorting by address, then O(N) for the actual merging process. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29994] ld fails to generate NOTE segment (with Build ID) on aarch64 if -z execstack or -z noexecstack
https://sourceware.org/bugzilla/show_bug.cgi?id=29994 --- Comment #2 from Tom Saeger --- (In reply to Andreas Schwab from comment #1) > This is a bug in the linker script, see > https://lore.kernel.org/all/20221226184537.744960-1-masahi...@kernel.org/ Thank you! Indeed applying this patch to stable v5.15.86 also fixes Build ID. This bug should be closed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29998] New: ld terminated with signal 11 [Segmentation fault] under mingw with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=29998
Bug ID: 29998
Summary: ld terminated with signal 11 [Segmentation fault]
under mingw with LTO
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: medhefgo at web dot de
Target Milestone: ---
The following build steps will result in bfd crashing. This only seems to
happen with a mingw gcc toolchain and only if LTO is used. I can reproduce this
with mingw gcc 12 on arch and debian unstable. This does not happen with the
mingw gcc 10 from debian stable. This crash only happens with mingw, I was not
able to reproduce with a regular gcc targeting ELF.
$ cat test1.c
void test1(void) {
}
$ cat test2.c
void test1(void);
void test2(void) {
char a[4096];
test1();
}
$ rm -f libtest.a *.obj
lto="-flto=auto"
x86_64-w64-mingw32-gcc $lto -o test1.obj -c test1.c
x86_64-w64-mingw32-gcc $lto -o test2.obj -c test2.c
x86_64-w64-mingw32-gcc-ar csrDT libtest.a test1.obj
x86_64-w64-mingw32-gcc $lto -nostdlib -o test test2.obj libtest.a -lgcc
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core
dumped
compilation terminated.
$ x86_64-w64-mingw32-gcc --version
x86_64-w64-mingw32-gcc (GCC) 12-win32
$ x86_64-w64-mingw32-ld --version
GNU ld (GNU Binutils) 2.39.90.20230110
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/29994] ld fails to generate NOTE segment (with Build ID) on aarch64 if -z execstack or -z noexecstack
https://sourceware.org/bugzilla/show_bug.cgi?id=29994 Tom Saeger changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG --- Comment #3 from Tom Saeger --- The problem in fact was resolved by the linker script change linked above. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993 --- Comment #4 from William Cohen --- Hi Nick, My (limited) understanding of the code is that first note in the like notes is kept and the later notes are merged into that first note. The downside of this is that there can be a lot of scanning backwards over the previously deleted notes to find that earlier kept note. Is there a choice which note to merge into which? Would it be possible to merge the previous note into the current note and delete the previous note? That would eliminate the repeated long backward scans to find the note to merge into that are currently dominating the firefox build install. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #30 from Rainer Orth --- (In reply to H.J. Lu from comment #28) > (In reply to Rainer Orth from comment #27) > > Created attachment 14577 [details] > > Augmented patch, incorporating review comments > > expected_tls_le should be unsigned int. The check will be > > if (r_type_tls == expected_tls_le) Ah, I misunderstood. Patch updated. > > /var/gcc/binutils/i386/obj/binutils-2.40-branch-local/ld/tmpdir/ld/collect- > > ld: BFD (GNU Binutils) 2.39.90.20230111 assertion fail > > /vol/src/gnu/binutils/hg/binutils-2.40-branch/local/bfd/elf32-i386.c:3377 > > collect2: error: ld returned 1 exit status > > > > On top of that, there are four new failures > > > > +FAIL: TLS GD/LD -> LE transition without PLT (dynamic) > > +FAIL: TLS GD/LD -> LE transition without PLT (dynamic, -z now) > > +FAIL: TLS GD/LD -> LE transition without PLT (PIE) > > +FAIL: TLS GD/LD -> LE transition without PLT (PIE, -z now) > > > > which show the same error. > > So TLS doesn't work for Solaris. I don't think so. On the contrary, I'd expect an assertion BFD_ASSERT (r_type == R_386_TLS_LE_32)' to trigger on Solaris with a patch whose primary purpose is to avoid the emission of R_386_TLS_LE_32. I've adjusted the assertion to BFD_ASSERT (r_type == expected_tls_le); and now (with ld-i386/tls.exp enabled on Solaris), all those tests PASS there and still do on Linux/i686. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #29 from Rainer Orth --- Created attachment 14590 --> https://sourceware.org/bugzilla/attachment.cgi?id=14590=edit Augmented^2 patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993
Nick Clifton changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |nickc at redhat dot com
CC||nickc at redhat dot com
Status|NEW |ASSIGNED
--- Comment #3 from Nick Clifton ---
(In reply to Frank Ch. Eigler from comment #0)
Hi Frank,
> objcopy.c's merge copy seems to be responsible. There is a
> doubly nested loop over the notes, resulting in O(n**2) complexity.
Not quite...
>2406 for (pnote = pnotes; pnote < pnotes_end; pnote ++)
>2407 {
> [...]
>2426 /* Rule 2: Check to see if there is an identical previous
> note. */
>2427 for (iter = 0, back = pnote - 1; back >= pnotes; back --)
>2428 {
>2429 if (is_deleted_note (back))
>2430 continue;
But a few lines further on there is:
/* Don't scan too far back however. */
if (iter ++ > 16)
{
/* FIXME: Not sure if this can ever be triggered. */
merge_debug ("ITERATION LIMIT REACHED\n");
break;
}
So the inner loop only executes a maximum of 16 times per outer iteration.
Well it inspects 16 non-deleted notes. If there are lots of deletions then the
loop will continue for longer. But there is also another optimization:
/* Our sorting function should have placed all identically
attributed notes together, so if we see a note of a different
attribute type stop searching. */
if (back->note.namesz != pnote->note.namesz
|| memcmp (back->note.namedata,
pnote->note.namedata, pnote->note.namesz) != 0)
break;
So once the scan reaches a different kind of note it will stop searching.
> Please consider improving the algorithm's performance on this sort of large
> dataset.
Do you have any suggestions ? I will investigate myself, but if you have any
ideas I would love to hear them.
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/29991] gas: MicroMIPS flag mistakenly erased after align directives
https://sourceware.org/bugzilla/show_bug.cgi?id=29991 --- Comment #6 from 刘鑫 --- (In reply to Alan Modra from comment #5) > Created attachment 14589 [details] > Simpler patch > > Please verify that the attached patch works for you. It should be OK to run > file_mips_check_options and mips_mark_labels without your define_label > logic. I moved the mips_mark_labels call after .align expression parsing as > is done with other directives. Yes, I can verify this patch works, the new patch could pass testcases I have written. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29457] Consider making --disassembler-color=color default if terminal
https://sourceware.org/bugzilla/show_bug.cgi?id=29457 Martin Liska changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #12 from Martin Liska --- Let's close it again as there's a new configure option added: --disassembler-color. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29851] -Wl,-z,ibtplt emits MPX jumps
https://sourceware.org/bugzilla/show_bug.cgi?id=29851 Martin Liska changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Martin Liska --- Fixed now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29994] ld fails to generate NOTE segment (with Build ID) on aarch64 if -z execstack or -z noexecstack
https://sourceware.org/bugzilla/show_bug.cgi?id=29994 --- Comment #1 from Andreas Schwab --- This is a bug in the linker script, see https://lore.kernel.org/all/20221226184537.744960-1-masahi...@kernel.org/ -- You are receiving this mail because: You are on the CC list for the bug.
