[lkml]   [2009]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] FDPIC: Ignore the loader's PT_GNU_STACK when calculating the stack size
    Pavel Machek <> wrote:

    > > i really dont think this is realistic. there is exactly one ldso that
    > > everyone uses under FDPIC ELF, and it needs a very minuscule stack.
    > Not very realistic; but that argues that the patch is NOP.
    > And if it _is_ realistic, the patch adds a bug.

    No, it doesn't. The problem is that the loader, when it is linked, is given a
    sillyly large default stack size, and this causes the application to be given a
    much larger stack than is strictly necessary - a stack that is drawn from a
    limited pool of non-pageable RAM and that must be allocated as a contiguous

    The executables should take into account the amount of stack space needed to
    call into all their libraries - and that includes the loader. You can argue
    that the loader should specify the amount of extra overhead it will need, and
    that this should be _added_ to the executable's stack estimate, but using the
    loader's stack estimate instead of the executable's does not really make sense.

    You can also argue that the executable doesn't know how much space the loader
    will use, because the loader can be independently replaced; but this isn't a
    good argument because the loader doesn't know how much the executable will use,
    and neither know how much the various shared libs will use. The only way to do
    that is to add up all the stack estimates.

    Now, it *is* perfectly reasonable to use the loader's stack estimate in the
    case that the loader is run as an executable. It could, for example, behave as
    the GLIBC loader and have some functions available for shared library query and


     \ /
      Last update: 2009-07-09 13:03    [W:0.020 / U:43.068 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site