https://sourceware.org/bugzilla/show_bug.cgi?id=30447
--- Comment #1 from Alan Modra ---
I don't see these fails on powerpc64le-linux with gcc-12.3 and
--enable-pgo-build=lto.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29961
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://sourceware.org/bugzilla/show_bug.cgi?id=29961
--- Comment #16 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=80b6c32f233ed28607643c4e4e4e2ee3399fdfd7
commit 80b6c32f233ed28607643c4e4e4e
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #13 from Eric Botcazo
Updates:
Labels: -deadline-approaching -restrict-view-commit Deadline-Exceeded
Comment #3 on issue 55991 by sheriffbot: binutils:fuzz_as: Stack-overflow in
snapshot_symbol
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55991#c3
This bug has exceeded our disclosure deadline. It has
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #12 from Tom Kacvinsky ---
(In reply to Eric Botcazou from comment #11)
> > The problem is an access violation at startup, deep in the guts of the DLL
> > loader. Doing a debug session with Visual Studio and looking at registers
>
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #11 from Eric Botcazou ---
> The problem is an access violation at startup, deep in the guts of the DLL
> loader. Doing a debug session with Visual Studio and looking at registers
> and memory locations, it was determined that loa
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #10 from Tom Kacvinsky ---
The problem is an access violation at startup, deep in the guts of the DLL
loader. Doing a debug session with Visual Studio and looking at registers and
memory locations, it was determined that loading t
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2023-05-16
CC|
https://sourceware.org/bugzilla/show_bug.cgi?id=30444
--- Comment #15 from Sven ---
(In reply to Sven from comment #2)
> //AAph7S is an example of a section name from the attached file. The part
> after the two slashed decodes to the byte sequence 00 0a 61 ed. So i'm
> pretty sure, the byte order
https://sourceware.org/bugzilla/show_bug.cgi?id=29983
Nick Alcock changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=30359
--- Comment #17 from Pali Rohár ---
Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30359
--- Comment #16 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=d1792f72bf92ac06be7a4785567e2c7bf78c0496
commit d1792f72bf92ac06be7a478556
https://sourceware.org/bugzilla/show_bug.cgi?id=30359
--- Comment #15 from Nick Clifton ---
(In reply to Pali Rohár from comment #14)
> Well, if this is the way how it should be used then "fixed" linker script
> should be distributed with linker. Or at least described in the LD
> documentation. B
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #8 from Tom Kacvinsky ---
I think it was actually this commit
dc9bd8c92af67947db44b3cb428c050259b15cd0
That had pep_dll_enable_reloc_section = 1 only if --enable-dynamicbase was
specified (which we hadn't been doing). Later on i
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #7 from Tom Kacvinsky ---
I don't understood _why_ those patches introduced the issue.
Looking at them, one was from 2018, and the problem started sometime after
2019, and the other patches are changing ld options for DLL characte
https://sourceware.org/bugzilla/show_bug.cgi?id=30444
--- Comment #14 from Jose E. Marchesi ---
Correct. The encoding is simple base 64 using the base64 alphabet, but not the
RFC base64 encoding.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30444
--- Comment #13 from Sven ---
(In reply to Jose E. Marchesi from comment #12)
> Ok, this is worse than I thought :)
>
> Given the section name //AAph7S, the corresponding base64 to decode is
> 00AAph7S, _not_ AAph7S==.
>
> Found it the hard
https://sourceware.org/bugzilla/show_bug.cgi?id=30444
--- Comment #12 from Jose E. Marchesi ---
(In reply to Sven from comment #8)
> (In reply to Jose E. Marchesi from comment #7)
> > While implementing this in GNU poke [1] I noticed that the base64 value
> > encoded in ASCII after the // is muti
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #6 from Nick Clifton ---
(In reply to Tom Kacvinsky from comment #5)
Hi Tom,
> So yeah, definite difference between 2.35 and 2.36 with relocation handling.
I suspect that this is all because of this PR:
https://sourceware.org/
https://sourceware.org/bugzilla/show_bug.cgi?id=30409
--- Comment #6 from Daniel Starke ---
(In reply to Alan Modra from comment #5)
> > Regarding the temporary file creation: I had trouble deleting a tmp like
> > folder within the build tree. Windows asked me if I want to remove the
> > shared n
21 matches
Mail list logo
