This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] Support 'exclude' in objcopy --set-section-flags
- From: Nick Clifton <nickc at redhat dot com>
- To: Fangrui Song <i at maskray dot me>
- Cc: binutils <binutils at sourceware dot org>
- Date: Tue, 11 Feb 2020 17:14:32 +0000
- Subject: Re: [PATCH] Support 'exclude' in objcopy --set-section-flags
- References: <20200116085509.pttoo3atw34dbl3m@google.com> <20200203060029.a3mora6uaadropos@google.com> <3390c868-a19f-e3cf-4cbd-27dfd507d43f@redhat.com> <SN6PR07MB522933C280BE82ECF585CB7DCB190@SN6PR07MB5229.namprd07.prod.outlook.com>
Hi Fangrui,
> Thanks! I'm curious to learn what SHF_MASKPROC tests on what archs are affected,
> and how you made the test.
Well I have a build-lots-of-toolchains script that I run to test patches.
These are the linker failures that show up with that change to elf.c applied:
LD REGRESSION: ld-elf/exclude3c
LD REGRESSION: ld-elf/pr20528a
LD REGRESSION: ld-elf/pr20528b
This is for lots of architectures (x86_64, arm, aarch64, ppc, etc). Now it may
well be that these tests are inaccurate and need to be updated. But that
should be done in sync with applying the patch, rather than afterwards.
> The main issue is that (SHF_EXCLUDE & SHF_MASKPROC) != 0.
> SHF_EXCLUDE = SHF_ARM_COMDEF = SHF_MIPS_STRINGS = SHF_PARISC_SBP
Which implies that the value being used for SHF_EXCLUDE is wrong. It
ought to be a generic value. I assume that it is too late to change
this however.
So it seems to me that what we need to do is to provide a backend
hook to handle the copying of OS/PROC flag bits from an input bfd to
an output bfd. The default could be to strip the SHF_EXCLUDE, but
backends should be able to decide.
Cheers
Nick