Am Sonntag, den 24.05.2015, 20:36 -0400 schrieb Rich Felker:
> There's a simple alternative I just came up with though: have
> dlstart.c compute the number of REL entries that need their addends
> saved and allocate a VLA on its stack for stages 2 and 3 to use. While
> the number of addends could be significant, it's many orders of
> magnitude smaller than the smallest practical stack sizes we could
> actually run with, so it's perfectly safe to put it on the stack.
> 
> Here're the basic changes I'd like to make to dlstart.c to implement
> this:
> 
> 1. Remove processing of DT_JMPREL REL/RELA table. All entries in this
>    table are necessarily JMP_SLOT type, and thus symbolic, so there's
>    nothing stage 1 can do with them anyway. Also, being JMP_SLOT type,
>    they have implicit addends of zero if they're REL-type, so there's
>    no need to save addends.
> 
> 2. Remove the loop in dlstart.c that works like a fake function call 3
>    times to process DT_JMPREL, DT_REL, and DT_RELA. Instead we just
>    need 2 iterations, and now the stride is constant in each, so they
>    should simplify down a lot more inline.
> 
> 3. During the loop that processes DT_REL, count the number of
>    non-relative relocations (ones we skip at this stage), then make a
>    VLA this size and pass its address to __dls2 as a second argument.
> 
> 4. Have the do_relocs in stage 2 save addends in this provided array
>    before overwriting them, and save its address for use by stage 3.
> 
> 5. Have the do_relocs in stage 3 (for ldso/libc only) pull addends
>    from this array instead of of from inline.
> 
> Steps 1 and 2 are purely code removal/simplification and should be
> done regardless of whether we move forward on the above program, I
> think. Steps 3-5 add some complexity but hardly any code, just a few
> lines here and there.
> 
> Comments?

I like it.

The thing that is a bit critical here, is the VLA. Not because it is a
VLA as such, but because it is a dynamic allocation on the stack. We
already have a similar strategy in pthread_create for TLS. The
difference is that there we have

 - a sanity check
 - an alternative strategy if the sanity check fails

Would there be a possibility to have both here, too?

Thanks
Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::