This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: [PATCH] ld: Failing to copy processor specific flags for split-by-file
- From: "Andrew Burgess" <aburgess at broadcom dot com>
- To: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 6 Sep 2010 06:03:47 -0700
- Subject: RE: [PATCH] ld: Failing to copy processor specific flags for split-by-file
- References: <89AE14E37D740B4796DC14566DF6325ECB7D053AC1@SJEXCHCCR02.corp.ad.broadcom.com>
I was wondering if there was anything I could do that would
help get these patches merged?
...or should I just be more patient :)
Thanks,
Andrew
> -----Original Message-----
> From: binutils-owner@sourceware.org [mailto:binutils-
> owner@sourceware.org] On Behalf Of Andrew Burgess
> Sent: 18 August 2010 15:32
> To: binutils@sourceware.org
> Subject: [PATCH] ld: Failing to copy processor specific flags for
> split-by-file
>
> I believe that I have found a problem when using processor specific
> flags while also using the -split-by-file option to the linker.
>
> I create two files, each with a section called "foo" and set the same
> processor specific flag on both of these sections.
> I assemble and link these files, using the -split-by-file option to
> the linker.
> I would expect to see two sections in the output file, one called
> ".foo", and one called ".foo.0", each with the processor specific flag
> set. Instead the flag is set on ".foo", but unset on ".foo.0".
>
> I found this bug while working on a private port of binutils, for a
> platform that use processor specific flags.
> As this looks like a generic issue I've created a test case for this
> using an x86-64 target, setting the "l" flag on the sections.
>
> I've attached two patches, split-test.patch, contains the test that
> highlights this problem. I'll be honest, I don't really understand
> what the "l" flag is used for, but I don't *think* that it makes any
> difference for the purpose of this test, please let me know if I've
> missed something obvious here :)
>
> The second patch, split.patch, is my attempt at fixing the problem by
> calling bfd_copy_private_section_data in clone_section to get the
> required data copied over.
>
> Let me know if there's anything else I need change or fix before the
> patch could be considered for inclusion.
>
> Thanks
>
> Andrew