[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    [W:0.021 / U:5.820 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site