lkml.org 
[lkml]   [2009]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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.

J


\
 
 \ /
  Last update: 2009-03-15 07:13    [from the cache]
©2003-2011 Jasper Spaans