https://sourceware.org/bugzilla/show_bug.cgi?id=32643
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #3 fro
https://sourceware.org/bugzilla/show_bug.cgi?id=32644
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #3 fro
https://sourceware.org/bugzilla/show_bug.cgi?id=32644
--- Comment #4 from Nick Clifton ---
(In reply to Michael Matz from comment #3)
> Similar to PR32643, shouldn't the error message that's clearly there have
> prevented the followup code from running, even in presence of -w? I.e.
> like fixed
https://sourceware.org/bugzilla/show_bug.cgi?id=31101
Lulu Cai changed:
What|Removed |Added
CC||cailulu at loongson dot cn
--- Comment #1
https://sourceware.org/bugzilla/show_bug.cgi?id=32382
--- Comment #3 from Jackson Huff ---
I'm now testing the same with
.insn b 0b1001011, 0b111, a2, a3, 64
and the standards-compliant hex output should be 4b 70 d6 04, but as generated
4b 64 d6 00 6f 00 00 00.
--
You are receiving this mail
Replying to this email means your email address will be shared with the
team that works on this product.
https://issues.oss-fuzz.com/issues/395921930
Reference Info: 395921930 binutils:fuzz_disassemble: Direct-leak in xcalloc
component: Public Trackers > 1362134 > OSS Fuzz
status: New
reporter:
https://sourceware.org/bugzilla/show_bug.cgi?id=32666
--- Comment #2 from Indu Bhagat ---
Confirmed.
In presence of bad offsets, relocating SFrame sections with bad .rela.sframe
will result in bad data in the SFrame section.
The issue is that with relocatable link, we need to manually adjust (i
