This is the mail archive of the
mailing list for the binutils project.
Re: [RFC][PATCH] Check ELF relocs after opening all all input files
- From: Alan Modra <amodra at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, Binutils <binutils at sourceware dot org>
- Date: Wed, 20 Apr 2016 08:54:57 +0930
- Subject: Re: [RFC][PATCH] Check ELF relocs after opening all all input files
- Authentication-results: sourceware.org; auth=none
- References: <20160419134956 dot GA12310 at intel dot com> <57165642 dot 1070808 at redhat dot com> <CAMe9rOrydGcortz2AsujVSQYZCRbSPsi7CFQRnA6ZZiicbUvTA at mail dot gmail dot com>
On Tue, Apr 19, 2016 at 11:03:15AM -0700, H.J. Lu wrote:
> On Tue, Apr 19, 2016 at 9:01 AM, Nick Clifton <firstname.lastname@example.org> wrote:
> > Hi H.J.
> >> Delaying checking ELF relocations until opening all input files so
> >> that symbol information is final when relocations are checked. This
> >> is only enabled for x86 targets.
> >> Any comments, feedbacks?
> > What benefit is gained by doing this ? I would guess that it is connected
> > with symbols changing type and/or visibility and/or protected status, but
> > it would be nice to know what you are hoping to achieve.
> Yes, this change is motivated by that discussion. Currently backend
> check_relocs doesn't have the final information on symbols. A better
> linker can provide better diagnostics in check_relocs if symbol info is
There are other benefits too. As it is the backend check_relocs
functions do things like "maybe this symbol remains undefined so
perhaps it needs a plt entry", and "maybe this symbol remains dynamic
so perhaps it needs dynamic relocations". This complexity can
disappear if all of those "maybe" cases are resolved.
Now, if you run check_relocs even later, say at
ldemul_before_allocation, after gc-sections has run, then all the
reference counting code for plt and got relocs can be removed too.
Australia Development Lab, IBM