Messages in this thread | | | Date | Sat, 14 Mar 2009 23:09:48 -0700 | From | Jeremy Fitzhardinge <> | Subject | Re: 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
| |