This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 1/8] PR ld/17878: Add bfd_maybe_object_p
- From: Alan Modra <amodra at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: binutils at sourceware dot org
- Date: Sat, 7 Feb 2015 20:12:41 +1030
- 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>
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
> file.
Hmm, in other words, if it is unknown. (bfd_format takes the values
bfd_unknown, bfd_object, bfd_archive, bfd_core.)
> +bfd_boolean
> +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!
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.
--
Alan Modra
Australia Development Lab, IBM