[lkml]   [2009]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Latest brk patchset
H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>>> It really doesn't make much sense to me, and is more than a bit
>>> confusing given the symbols.
>> Mostly because I knew that the bss would get mapped into the appropriate
>> phdr segment correctly, but I wasn't sure that another bss-like section
>> would be.
> It will; in fact if they are adjacent then ld will typically merge the
> PHDRs.
>> Also because historically the brk segment was just an
>> extension of the executable's bss, and its more or less the same too.
> An extension of, yes, but not a part of.
>> Is there any real benefit in putting it into another section?
> Well, the semantics are different; the .bss section is zeroed while the
> brk isn't,
Traditionally, brk is always zeroed. extend_brk() zeros the memory it
returns (to be consistent with bootmem, and to make it easier to migrate
from bss -> brk).

> and the brk symbols don't necessarily point to the data
> associated with those particular symbols, unlike (of course) the bss.

Yes, its a bit of a pitfall. I guess the symbols are useful as a way to
identify brk users just from looking at the vmlinux, but they're not
really all that useful. I'm half thinking we should put some non-C
identifier characters in them to make sure that C code can never refer
to them.


 \ /
  Last update: 2009-03-15 07:13    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean