Re: [#717032] FYI: changed behaviour of _end symbol
Hello,
Getting back on this (yes, it's been a long time... thanks for the
heads-up, it was not forgotten!)
Petr Salinger, le mar. 16 juil. 2013 16:59:50 +0200, a ecrit:
> the change in binutils might affect also hurd, as
>
> eglibc-2.17/hurd/Versions:
>
> GLIBC_2.0 {
> # necessary for the Hurd brk implementation
> _end;
> }
>
> Please recheck.
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717032
>
>
> ---------- Forwarded message ----------
>
> > > 1006: 0000000000358e28 0 NOTYPE GLOBAL DEFAULT ABS _end@@GLIBC_PRIVATE
> > > 1006: 0000000000358e08 0 NOTYPE GLOBAL DEFAULT 33 _end@@GLIBC_PRIVATE
>
> The value itself does not matter here, but ABS->33 change.
>
> Try to build and run via ktrace under stable and under sid
>
> int main()
> {
> sbrk(16*1024);
> };
>
> You will see the key difference.
On GNU/Hurd we don't actually see it because we already had a guard
against low values of _end which were brought by PIE executables.
But we do get a side effect: libc is currently defining a _end symbol,
and that leads to funky side effects, see my comment at the end of
https://sourceware.org/bugzilla/show_bug.cgi?id=23499
I'm thinking that we should perhaps just not try to stick to the
historic meaning of brk being exactly after the application binary
(_end), and just put it wherever we prefer: with PIE and randomization
sticking to _end doesn't seem to make sense any more, will any program
actually notice that it's not happening any more?
One thing that this breaks is the RLIMIT_DATA which is "supposed" to
account for data, bss, and heap, and computing brk - __start_data
is convenient, but again this RLIMIT_DATA notion is quite relative
nowadays, since one can dlopen() libraries which have data, we can mmap
data, etc. Trying to reach the main program's _end only to compute
its static data size seems outdated to me, and what we really want is
probably rather to control the heap size?
Samuel
Reply to: