From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27813 invoked by alias); 19 Feb 2015 20:10:01 -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 27781 invoked by uid 89); 19 Feb 2015 20:10:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-ob0-f172.google.com Received: from mail-ob0-f172.google.com (HELO mail-ob0-f172.google.com) (209.85.214.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 19 Feb 2015 20:09:59 +0000 Received: by mail-ob0-f172.google.com with SMTP id nt9so18965203obb.3 for ; Thu, 19 Feb 2015 12:09:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.196.137 with SMTP id u131mr3905567oif.78.1424376597800; Thu, 19 Feb 2015 12:09:57 -0800 (PST) Received: by 10.76.134.102 with HTTP; Thu, 19 Feb 2015 12:09:57 -0800 (PST) In-Reply-To: References: <20150205135440.GA27203@gmail.com> <20150207094240.GD14796@bubble.grove.modra.org> <54E61565.2090008@arm.com> Date: Thu, 19 Feb 2015 20:10:00 -0000 Message-ID: Subject: Re: Re: [PATCH 1/8] PR ld/17878: Add bfd_maybe_object_p From: "H.J. Lu" To: Alex Velenko Cc: Binutils Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00277.txt.bz2 On Thu, Feb 19, 2015 at 8:59 AM, H.J. Lu wrote: > On Thu, Feb 19, 2015 at 8:55 AM, Alex Velenko wrote: >> >> >> 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 >>>>>> 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.