[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [#717032] FYI: changed behaviour of _end symbol

From: Samuel Thibault
Subject: Re: [#717032] FYI: changed behaviour of _end symbol
Date: Sat, 1 Aug 2020 03:09:55 +0200
User-agent: NeoMutt/20170609 (1.8.3)


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

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]