https://sourceware.org/bugzilla/show_bug.cgi?id=19020
--- Comment #4 from Andrew Stubbs ---
It generates an output file, the same as the interleave test does:
$ echo -n abcdefgh > in
$ objcopy -I binary -O binary \
--pad-to=10 --gap-fill=65 \
--reverse-bytes=8 \
in
https://sourceware.org/bugzilla/show_bug.cgi?id=19020
--- Comment #2 from Andrew Stubbs ---
My patch in PR19005 has a testcase for --reverse-bytes, but that test passes.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
--- Comment #23 from Andrew Stubbs ---
Done: pr19020.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.g
Assignee: unassigned at sourceware dot org
Reporter: ams at sourceware dot org
Target Milestone: ---
The recent fix for pr binutils/19005 broke the interleave feature.
Before the "fix":
$ echo -n abcdefgh > in
$ objcopy -I binary -O binary \
--pad-to=
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
--- Comment #21 from Andrew Stubbs ---
Looks like I'm just too late with my test results you broke the interleave
feature. :-(
The "interleave size" testcase in my patch demonstrates the problem. Here's the
output:
$ xxd tmpdir/interleav
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
--- Comment #17 from Andrew Stubbs ---
I can check this tomorrow, but I don't think the output size is actually
broken, as long as everything respects the input size when reading from input
sections. The "change something, change it back, chan
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
--- Comment #15 from Andrew Stubbs ---
It's just because the padding is added to the output section size when
--gap-fill is set in the following snippet:
objcopy.c, copy_object()
size = bfd_section_size (obfd, osections[i]);
gap
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
Andrew Stubbs changed:
What|Removed |Added
Attachment #8632|0 |1
is obsolete|
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
--- Comment #11 from Andrew Stubbs ---
My testcase was not really for reverse. I was trying to test for the buffer
overrun, but as that's UB there's no direct way to do it reliably. Testing
reverse was only meant to serve as an indicator that
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
--- Comment #9 from Andrew Stubbs ---
No, it's the call to bfd_set_section_contents in which the UB occurs. You can
see this with valgrind:
==14966== Invalid read of size 1
==14966==at 0x50AA0A0: _IO_default_xsputn (genops.c:480)
==14966=
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
--- Comment #6 from Andrew Stubbs ---
It's a negative test. No error *is* a failure.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-b
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
Andrew Stubbs changed:
What|Removed |Added
Attachment #8631|0 |1
is obsolete|
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
Andrew Stubbs changed:
What|Removed |Added
Attachment #8629|0 |1
is obsolete|
|unassigned at sourceware dot org |ams at sourceware dot
org
--- Comment #2 from Andrew Stubbs ---
Created attachment 8630
--> https://sourceware.org/bugzilla/attachment.cgi?id=8630&action=edit
proposed patch
And here's my patch to fix the issue.
This has already been approved by Alan
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
--- Comment #1 from Andrew Stubbs ---
Created attachment 8629
--> https://sourceware.org/bugzilla/attachment.cgi?id=8629&action=edit
test case
I've attached a test suite patch that detects the issue.
--
You are receiving this mail because
Assignee: unassigned at sourceware dot org
Reporter: ams at sourceware dot org
Target Milestone: ---
objcopy exhibits intermittent failures when creating binary files from ELF
files (the typical error message is "No space left on device"). Even though
failure is intermittent
http://sourceware.org/bugzilla/show_bug.cgi?id=13843
--- Comment #4 from Andrew Stubbs 2012-03-17
20:40:46 UTC ---
Ah, ok, it appears my maths is mysteriously broken. On a second inspection, the
patch seems fine.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
http://sourceware.org/bugzilla/show_bug.cgi?id=13843
--- Comment #2 from Andrew Stubbs 2012-03-14
16:19:19 UTC ---
I can confirm that the patch fixes the -65536 case, but it still fails for
-262144 and -1048576, etc.
It ought to be possible to represent any 64-bit number in which each byte
cons
http://sourceware.org/bugzilla/show_bug.cgi?id=13843
Bug #: 13843
Summary: Negative immediate for vmov fails on 32-bit host
Product: binutils
Version: 2.23 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Compon
19 matches
Mail list logo
