This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 1/2] ld: Define _edata, __bss_start, and _end only for executables
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>, "Maciej W. Rozycki" <macro at mips dot com>, Joseph Myers <joseph at codesourcery dot com>, Dave Anglin <dave dot anglin at bell dot net>
- Date: Sat, 2 Jun 2018 06:43:45 -0700
- Subject: Re: [PATCH 1/2] ld: Define _edata, __bss_start, and _end only for executables
- References: <20180530215940.20797-1-hjl.tools@gmail.com> <20180530215940.20797-2-hjl.tools@gmail.com> <20180531004407.GR23663@bubble.grove.modra.org> <CAMe9rOqpyn0QBO2C+fG4MU_Z-0b83ag6Q-iyMcfxhu4O5FwoEg@mail.gmail.com> <20180602132241.GC7660@bubble.grove.modra.org>
On Sat, Jun 2, 2018 at 6:22 AM, Alan Modra <amodra@gmail.com> wrote:
> On Fri, Jun 01, 2018 at 11:45:32AM -0700, H.J. Lu wrote:
>> On Wed, May 30, 2018 at 5:44 PM, Alan Modra <amodra@gmail.com> wrote:
>> > On Wed, May 30, 2018 at 02:59:39PM -0700, H.J. Lu wrote:
>> >> _edata, __bss_start, and _end are defined for executables. FreeBSD's
>> >> libc.so uses executable's _end to initialize curbrk. But there is no
>> >> good reason to access values of _edata, __bss_start, and _end defined
>> >> in shared libraries. We should define _edata, __bss_start, and _end
>> >> only for executables.
>> >
>> > I agree with the idea, but the patch isn't complete. You'll need to
>> > look at all the target OTHER_END_SYMBOLS, OTHER_BSS_SYMBOLS, and
>> > OTHER_BSS_END_SYMBOLS. For instance, elf32mep.sh defines __heap = _end
>> > in OTHER_END_SYMBOLS, which is going to go wrong when _end isn't
>> > defined in a shared library.. Ah, no, mep uses its own mep.sc so
>> > won't be affected by your elf.sc patch, but I'm sure you can see the
>> > potential problem in other targets. So please do look for _edata,
>> > edata, __bss_start, _end and end in emulparams/*.sh. A quick look
>> > says this patch will likely cause fails on some targets, eg. see
>> > elf32epiphany.sh EXECUTABLE_SYMBOLS.
>> >
>> > If you're lucky you might be able to wrap the occurrences of
>> > OTHER_END_SYMBOLS, OTHER_BSS_SYMBOLS, OTHER_BSS_END_SYMBOLS and
>> > EXECUTABLE_SYMBOLS in elf.sc with ${CREATE_SHLIB- }.
>> >
>> > Also, do test this sort of patch on a large set of ELF targets before
>> > posting.
>> >
>>
>> The new set of patches are posted at
>>
>> https://sourceware.org/ml/binutils/2018-06/msg00021.html
>
> Did you do the analysis of emulparams files to see whether this is OK?
>
> I suspect you may have taken my "If you're lucky" comment as meaning
> to try that out and if there are no testsuite fails then the simple
> approach is OK. I meant that you should look at target usage of shell
> variables like EXECUTABLE_SYMBOLS to see whether wrapping in
> ${CREATE_SHLIB-} make sense, and at least report back to the binutils
> list about places where you are unsure.
>
I know very little about these targets. Maybe I should limit my
change to targets which only define _edata, __bss_start, and
_end.
--
H.J.