This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Re: [PATCH 1/8] PR ld/17878: Add bfd_maybe_object_p
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Alex Velenko <Alex dot Velenko at arm dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Thu, 19 Feb 2015 08:59:24 -0800
- Subject: Re: 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> <CAMe9rOo_u9VL2KjczbppH7C8Kv-j6-EOvPrB12Vw65Ro_mg4+g at mail dot gmail dot com> <54E61565 dot 2090008 at arm dot com>
On Thu, Feb 19, 2015 at 8:55 AM, Alex Velenko <Alex.Velenko@arm.com> wrote:
>
>
> On 09/02/15 04:36, H.J. Lu wrote:
>>
>> On Sat, Feb 7, 2015 at 4:50 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>
>>> On Sat, Feb 7, 2015 at 1:42 AM, Alan Modra <amodra@gmail.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
>>>>> file.
>>>>
>>>>
>>>> Hmm, in other words, if it is unknown. (bfd_format takes the values
>>>> bfd_unknown, bfd_object, bfd_archive, bfd_core.)
>>>
>>>
>>> Yes.
>>>
>>>>> +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!
>>>
>>>
>>> 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:
>>
>>
>> https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=23903a326cd1cb205902698bb61f9deb1d1bf9a9
>>
>> I will submit a proper patch tomorrow.
>>
>
> Hi Lu,
> After this patch on arm-none-eabi and arm-none-linux-gnueabihf I see
> following regressions:
> FAIL: load plugin 2 with source
> FAIL: load plugin 3 with source
> FAIL: plugin 2 with source lib
> FAIL: plugin 3 with source lib
> FAIL: plugin claimfile replace symbol with source
> FAIL: plugin claimfile resolve symbol with source
>
> when I run test src/binutils-gdb/ld/testsuite/ld-plugin/func.c
> , I see:
> /work/fsf-trunk-3/build-arm-none-eabi/install/bin/arm-none-eabi-gcc
> -B/work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/ld/
> -I/work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin -O2
> -specs=rdimon.specs -Wa,-mno-warn-deprecated -mthumb -O2 -c
> /work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin/text.c -o
> /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/text.o
> /work/fsf-trunk-3/build-arm-none-eabi/install/bin/arm-none-eabi-gcc
> -B/work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/ld/
> -I/work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin -O2
> -specs=rdimon.specs -Wa,-mno-warn-deprecated -mthumb -O2 -c
> /work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin/main.c -o
> /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/main.o
> /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/ld-new -o
> /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/main.x
> -L/work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin -plugin
> /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/.libs/libldtestplug2.so.0
> -plugin-opt registerclaimfile -plugin-opt registerallsymbolsread -plugin-opt
> registercleanup -plugin-opt dumpresolutions
> /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/main.o
> /work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin/func.c
> /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/text.o --defsym
> __stack_chk_fail=0 --defsym __gccmain=0 --defsym printf=main --defsym
> puts=main
> hook called: all symbols read.
> Input: /work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin/func.c
> (/work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin/func.c)
> Sym: 'func' Resolution: LDPR_PREVAILING_DEF
> Sym: '_func' Resolution: LDPR_PREVAILING_DEF_IRONLY
> /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/ld-new:
> /work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin/func.c (symbol
> from plugin)(func): warning: interworking not enabled.
> first occurrence:
> /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/main.o: Thumb
> call to ARM
I think those failures are caused by those extra messages.
I am not familiar with ARM linker. I can skip those tests
for ARM.
--
H.J.