This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Binutuls is broken now.


Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:

I see that sources is running nearly five hours behind on mail
delivery, due to the gcc 3.0 release, so this message may be
completely out of date.

> We know -r happens to work for a particular case of
> one-single-binary-input-to-ELF in the Linux kernel.  But I don't
> know if linking -r from one or more binary input files to ELF,
> alone or together with other ELF input files works *in general*.
> (Do you?)

Yes, we know that that works.

> If we knew *that*, we still don't know if it works
> with binary files and linking -r to *other* formats than ELF.
> (Do you?)

Yes, we know that that works too.

The thing which fails when linking with -r is relocation processing
for object file formats other than the output file format.  Binary
files have no relocations, by definition.  Therefore nothing fails.

> Since we don't know it works in the *general* case when
> including one or more binary files with zero or more of the same
> format as the output file, and we know it *doesn't* work (and it
> is documented to *not* work) for other -r cases, I don't see it
> as logical to allow -r in general for binary-to-anything.  That
> is the reason.  I thought it be seen as inferred from my
> previous reply.

It's fine to allow binary input files for ld -r in all cases.  In
general it's fine to allow any input file which has no relocations for
ld -r.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]