[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug binutils/26356] FAIL: objcopy --reverse-bytes
From: |
danglin at gcc dot gnu.org |
Subject: |
[Bug binutils/26356] FAIL: objcopy --reverse-bytes |
Date: |
Sun, 09 Aug 2020 20:10:58 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=26356
--- Comment #1 from John David Anglin <danglin at gcc dot gnu.org> ---
Created attachment 12755
--> https://sourceware.org/bugzilla/attachment.cgi?id=12755&action=edit
Patch
The change to som.c fix the segmentation fault running objcopy. However, I'm
not sure that this isn't just papering over a higher level problem.
After this I found we had an extra backslash before the the '$' characters in
$DATA$. I revised the get_standard_section_names proc to work around this.
After this, the pr23633 started to fail so I xfailed it on som.
The reversed-bytes test still doesn't pass. $DATA$ turns into a space. It
should be a subspace in $PRIVATE$.
The "objcopy object (simple copy)" fails here:
tmpdir/bintest.o tmpdir/copy.o differ: char 168, line 1
I believe this is because the 'O' bit gets set in $LIT$ and $MILLICODE$:
-bash-4.4$ odump -subspaces tmpdir/bintest.o
Subspace dictionary for tmpdir/bintest.o:
Sub Sp AC RDCLQIOENKT Key Loc/Init InitLn Start Len Align Fixups Name
0 0 2c ...L0.O.... 24 000001ec 000010 00000000 000010 8 0 4 $CODE$
1 0 2c ...L0...... 16 000001fc 000000 00000000 000000 8 4 0 $LIT$
2 0 2c ...L0...... 8 000001fc 000000 00000000 000000 8 4 0
$MILLICODE$
3 1 1f ...L1...... 24 000001fc 000008 00000000 000008 8 4 1 $DATA$
4 1 1f ...L1...... 80 00000000 000000 00000000 000000 8 -1 0 $BSS$
-bash-4.4$ odump -subspaces tmpdir/copy.o
Subspace dictionary for tmpdir/copy.o:
Sub Sp AC RDCLQIOENKT Key Loc/Init InitLn Start Len Align Fixups Name
0 0 2c ...L0.O.... 24 000001ec 000008 00000000 000008 8 0 1 $CODE$
1 0 2c ...L0.O.... 16 000001f4 000000 00000000 000000 8 -1 0 $LIT$
2 0 2c ...L0.O.... 8 000001f4 000000 00000000 000000 8 -1 0
$MILLICODE$
3 1 1f ...L1...... 24 000001f4 000000 00000000 000000 8 -1 0 $DATA$
4 1 1f ...L1...... 80 00000000 000000 00000000 000000 8 -1 0 $BSS$
The O bit indicates code only (no literal data), so it is incorrectly set by
objcopy.
There's also differences in fixup indexes and counts.
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug binutils/26356] New: FAIL: objcopy --reverse-bytes, danglin at gcc dot gnu.org, 2020/08/08
- [Bug binutils/26356] FAIL: objcopy --reverse-bytes,
danglin at gcc dot gnu.org <=
- [Bug binutils/26356] FAIL: objcopy --reverse-bytes, danglin at gcc dot gnu.org, 2020/08/10
- [Bug binutils/26356] FAIL: objcopy --reverse-bytes, amodra at gmail dot com, 2020/08/10
- [Bug binutils/26356] FAIL: objcopy --reverse-bytes, danglin at gcc dot gnu.org, 2020/08/11
- [Bug binutils/26356] FAIL: objcopy --reverse-bytes, danglin at gcc dot gnu.org, 2020/08/20
- [Bug binutils/26356] FAIL: objcopy --reverse-bytes, cvs-commit at gcc dot gnu.org, 2020/08/27
- [Bug binutils/26356] FAIL: objcopy --reverse-bytes, danglin at gcc dot gnu.org, 2020/08/27