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