From: "H.J. Lu" <hjl.tools@gmail.com>
To: Alex Velenko <Alex.Velenko@arm.com>
Cc: Binutils <binutils@sourceware.org>
Subject: Re: Re: [PATCH 1/8] PR ld/17878: Add bfd_maybe_object_p
Date: Thu, 19 Feb 2015 20:10:00 -0000 [thread overview]
Message-ID: <CAMe9rOpsjqOKz4pi9k8sCn_ESUeEnFE0zF5EsF9-74TQ4h+zRA@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOr+xobuKsKDK1fHJXZ0qCtVSjy6=jzFbiXBuceLwvu1YQ@mail.gmail.com>
On Thu, Feb 19, 2015 at 8:59 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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.
>
It looks like an ARM linker bug. ARM linker shouldn't complain
anything on input BFDs with BFD_PLUGIN since it is a dummy
input file.
--
H.J.
next prev parent reply other threads:[~2015-02-19 20:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-05 13:54 H.J. Lu
2015-02-07 9:42 ` Alan Modra
2015-02-07 12:50 ` H.J. Lu
2015-02-07 19:10 ` H.J. Lu
2015-02-07 20:47 ` H.J. Lu
2015-02-07 20:51 ` H.J. Lu
2015-02-09 4:36 ` H.J. Lu
2015-02-19 16:55 ` Alex Velenko
2015-02-19 16:59 ` H.J. Lu
2015-02-19 20:10 ` H.J. Lu [this message]
2017-02-13 16:03 ` [ld, testsuite] Relax the expectation pattern for several plugin-* tests Jiong Wang
2017-02-13 16:57 ` H.J. Lu
2017-02-15 17:46 ` Jiong Wang
2017-02-15 23:42 ` Alan Modra
2017-02-16 10:16 ` Jiong Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMe9rOpsjqOKz4pi9k8sCn_ESUeEnFE0zF5EsF9-74TQ4h+zRA@mail.gmail.com \
--to=hjl.tools@gmail.com \
--cc=Alex.Velenko@arm.com \
--cc=binutils@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).