https://sourceware.org/bugzilla/show_bug.cgi?id=33385
Bug ID: 33385
Summary: Binutils do not recognize valid target files
Product: binutils
Version: 2.46 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: devel at fricas dot org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: alpha-dec-vms
Build: x86_64-pc-linux-gnu
Created attachment 16314
--> https://sourceware.org/bugzilla/attachment.cgi?id=16314&action=edit
Binaries needed to reproduce the problems.
Using command:
/pom/kompi/gcc/binu-build3/binutils/objdump -x bar.exe
gives message:
/pom/kompi/gcc/binu-build3/binutils/objdump: bar.exe: file format not
recognized
The path above leads to build tree of binutils from current trunk.
bar.exe is a VMS shared image made on VMS and transferred to Linux.
Both VMS ANALYZE tool and objdump from binutils 2.21 give expected
result on this file.
Similarly, running 'objdump -d' on object files 'bar.obj' or 't0.obj'
gives the message above. Again both VMS ANALYZE tool and objdump from
binutils 2.21 give expected result.
AFAICS problem with bar.exe is due to fixes for PR 17512 and PR 21813,
more precisely from hunks dealing with 'struct vms_eihd' in
'bfd/vms-alpha.c'. Namely, part of this structure is typically
unused, in particular field 'alias' originally was intended to
be _after_ the header proper. Currenly header may contain more data,
so _some_ files satisfy current test in binutils. But some shared
images (and probly some executables) have short header, ending before
end of 'struct vms_eihd').
After disabling part of fix for PR 17512 and PR 21813 one can see
another problem: 'objdump -x' gives result but complanis that
EEOM record is too small. But valid EEOM record may have size 10
(as happens in 'bar.exe') and in this case code does not access
following field, so test should use 10 instead of size of
'struct vms_eeom' (and probaly us this size in the following test).
There are other problem. In particular 'ar rcs ttb.old bar.obj' gives
message about invalid operation.
First problem is known for several years and prevents building
cross gcc in "usual way", that is using system libraries transferred
from the target machine. VMS folks work around this problem staying
with old versions of binutils or reverting fixes for PR-s above.
Second problem probably would prevent building cross gcc, but is
intertwined with third one and possibly other problems (VMS folks
reported that 'ar' from binutils-2.27 produces malformed archives).
--
You are receiving this mail because:
You are on the CC list for the bug.
