From: Jens Gustedt <jens.gustedt@inria.fr>
To: musl@lists.openwall.com
Subject: Re: ppc soft-float regression
Date: Mon, 25 May 2015 08:31:29 +0200 [thread overview]
Message-ID: <1432535489.2715.1.camel@inria.fr> (raw)
In-Reply-To: <20150525003648.GO17573@brightrain.aerifal.cx>
[-- Attachment #1: Type: text/plain, Size: 2614 bytes --]
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 ::
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2015-05-25 6:31 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-17 8:03 Waldemar Brodkorb
2015-05-17 10:02 ` Felix Janda
2015-05-17 16:37 ` Rich Felker
2015-05-17 17:50 ` Felix Janda
2015-05-17 18:15 ` Felix Janda
2015-05-17 19:56 ` Felix Janda
2015-05-18 18:39 ` Felix Janda
2015-05-18 20:10 ` Rich Felker
2015-05-18 20:14 ` Rich Felker
2015-05-18 22:07 ` Felix Janda
2015-05-22 6:23 ` Rich Felker
2015-05-24 3:08 ` Rich Felker
2015-05-25 0:36 ` Rich Felker
2015-05-25 6:31 ` Jens Gustedt [this message]
2015-05-25 6:57 ` Rich Felker
2015-05-25 7:44 ` Jens Gustedt
2015-05-25 13:26 ` Szabolcs Nagy
2015-05-25 13:40 ` Alexander Monakov
2015-05-25 14:35 ` Szabolcs Nagy
2015-05-25 14:45 ` Alexander Monakov
2015-05-25 21:45 ` Rich Felker
2015-05-25 22:46 ` Rich Felker
2015-05-25 23:51 ` Rich Felker
2015-05-17 13:06 ` Felix Janda
2015-05-17 16:35 ` Rich Felker
2015-05-17 17:20 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1432535489.2715.1.camel@inria.fr \
--to=jens.gustedt@inria.fr \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).