From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 961 invoked by alias); 19 Feb 2015 16:55:18 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 952 invoked by uid 89); 19 Feb 2015 16:55:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Feb 2015 16:55:15 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by service87.mimecast.com; Thu, 19 Feb 2015 16:55:12 +0000 Received: from [10.2.207.44] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2015 16:55:08 +0000 Message-ID: <54E61565.2090008@arm.com> Date: Thu, 19 Feb 2015 16:55:00 -0000 From: Alex Velenko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "H.J. Lu" , Binutils Subject: Re: Re: [PATCH 1/8] PR ld/17878: Add bfd_maybe_object_p References: <20150205135440.GA27203@gmail.com> <20150207094240.GD14796@bubble.grove.modra.org> In-Reply-To: X-MC-Unique: 115021916551201901 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-02/txt/msg00274.txt.bz2 On 09/02/15 04:36, H.J. Lu wrote: > On Sat, Feb 7, 2015 at 4:50 AM, H.J. Lu wrote: >> On Sat, Feb 7, 2015 at 1:42 AM, Alan Modra 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 coredu= mp >>>> 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 whi= ch >>>> + 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=3Dbinutils-gdb.git;a=3Dpatch;h=3D23903a326c= d1cb205902698bb61f9deb1d1bf9a9 > > I will submit a proper patch tomorrow. > Hi Lu, After this patch on arm-none-eabi and arm-none-linux-gnueabihf I see=20 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=20 -B/work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/ld/=20 -I/work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin -O2=20 -specs=3Drdimon.specs -Wa,-mno-warn-deprecated -mthumb -O2 -c=20 /work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin/text.c -o=20 /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=20 -B/work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/ld/=20 -I/work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin -O2=20 -specs=3Drdimon.specs -Wa,-mno-warn-deprecated -mthumb -O2 -c=20 /work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin/main.c -o=20 /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=20 /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/main.x=20 -L/work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin -plugin=20 /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/.libs/libldtestplug2.= so.0=20 -plugin-opt registerclaimfile -plugin-opt registerallsymbolsread=20 -plugin-opt registercleanup -plugin-opt dumpresolutions=20 /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/main.o=20 /work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin/func.c=20 /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/text.o=20 --defsym __stack_chk_fail=3D0 --defsym __gccmain=3D0 --defsym printf=3Dmain= =20 --defsym puts=3Dmain hook called: all symbols read. Input: /work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin/func.c=20 (/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:=20 /work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin/func.c (symbol=20 from plugin)(func): warning: interworking not enabled. first occurrence:=20 /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/main.o:=20 Thumb call to ARM /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/ld-new:=20 /work/fsf-trunk-3/src/binutils-gdb/ld/testsuite/ld-plugin/func.c (symbol=20 from plugin)(func): warning: interworking not enabled. first occurrence:=20 /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/main.o:=20 Thumb call to ARM /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/ld-new: warning:=20 cannot find entry symbol _start; defaulting to 0000000000008000 /work/fsf-trunk-3/build-arm-none-eabi/obj/binutils/ld/tmpdir/main.o: In=20 function `main': main.c:(.text.startup+0xa): undefined reference to `func' hook called: cleanup. Kind regards, Alex