This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH/RFA] Ambiguity problem of REL objects on ELF sh*-*-*
- From: kaz Kojima <kkojima at rr dot iij4u dot or dot jp>
- To: hjl at lucon dot org
- Cc: amodra at bigpond dot net dot au, binutils at sources dot redhat dot com
- Date: Sun, 03 Nov 2002 07:30:11 +0900
- Subject: Re: [PATCH/RFA] Ambiguity problem of REL objects on ELF sh*-*-*
- References: <20021102095851.B18209@lucon.org>
"H. J. Lu" <hjl@lucon.org> wrote:
>> BTW, now I get 2 errors on gas testsuite for sh64-unknown-linux-gnu
>> target configured with --enable-targets=all. objdump -x reports that
>> the start address of the REL object is -1 in these two cases.
>> It seems that vms_object_p calls vms_initialize unconditionally and
>> vms_initialize set the start address to -1:
>>
>
> I don't see why we should spend any times on it. SH is broken since
> it uses the same EI_OSABI value for different ABIs. I have suggested
> how it should be fixed. In the mean time, please try this. We have
> so many "#if 0"s in targets.c because the underline binary formats
> don't support different ABIs. But there is no excuse for ELF. Also
> Linux/sh64 vectors are missing for --enable-targets=all.
The original patch also added Linux/sh64 vectors. Of course, your
patch completely solves the ploblem for SH linux folks including me,
but I don't know it's ok for the other folks.
Anyway, vms_initialize problem seems independent to the ambiguity.
Let's consider a new target vector zzz_unknown_vec which would be
added after vms vectors. Then zzz tools would hit this problem even
without --enable-targets=all.
Regards,
kaz