This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH 1/8] PR ld/17878: Add bfd_maybe_object_p
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Binutils <binutils at sourceware dot org>
- Date: Sun, 8 Feb 2015 20:36:28 -0800
- Subject: Re: [PATCH 1/8] PR ld/17878: Add bfd_maybe_object_p
- Authentication-results: sourceware.org; auth=none
- References: <20150205135440 dot GA27203 at gmail dot com> <20150207094240 dot GD14796 at bubble dot grove dot modra dot org> <CAMe9rOoC1KKOHtPT81fFAnU8sjHWO0BLjG2=XoGU=b1oiuR10g at mail dot gmail dot com>
On Sat, Feb 7, 2015 at 4:50 AM, H.J. Lu <firstname.lastname@example.org> wrote:
> On Sat, Feb 7, 2015 at 1:42 AM, Alan Modra <email@example.com> wrote:
>> On Thu, Feb 05, 2015 at 05:54:40AM -0800, H.J. Lu wrote:
>>> This patch adds bfd_maybe_object_p which is similar to
>>> bfd_check_format (abfd, bfd_object)
>>> The difference is bfd_maybe_object_p takes an argument to indicate if a
>>> compiler plug-in library is applied. When a compiler plug-in library is
>>> active, it also returns TRUE if the file is not an archive or a coredump
>> Hmm, in other words, if it is unknown. (bfd_format takes the values
>> bfd_unknown, bfd_object, bfd_archive, bfd_core.)
>>> +bfd_maybe_object_p (bfd *abfd, bfd_boolean plugin_active_p)
>>> + /* LTO IR object file may look like a bfd_object file or a file which
>>> + is not bfd_core nor bfd_archive. */
>>> + return (bfd_check_format (abfd, bfd_object)
>>> + || (plugin_active_p
>>> + && !bfd_check_format (abfd, bfd_core)
>>> + && !bfd_check_format (abfd, bfd_archive)));
>> I find this really strange. If plugins are active then you're
>> willing to accept anything except cores and archives. To throw out
>> cores and archives you'll be iterating over all compiled-in bfd
>> targets, asking "is this a core file", then asking "is this an
>> archive". That's quite a bit of processing, and won't exclude your
>> average text file!
> LTO IR could be stored in the average text file. The new plug tests
> use this feature. We can add a new type, bfd_maybe_object.
>> I think you need to find a way of answering the question "is this a
>> file accepted by a plugin?" in a more robust way. One possibility is
>> merging the linker handling of plugins into the bfd plugin support.
> I have considered it before. This approach has many implications.
> If we do this, we need to add bfd_plugin_object and bfd_all_object.
> bfd_all_object includes bfd_object and bfd_plugin_object. We need
> bfd_plugin_object so that we won't update dummy BFD info from the
> LTO IR input. Let me take another look.
Here is a draft to make linker plugin_object_p available to BFD:
I will submit a proper patch tomorrow.