This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] MIPS16 TLS support for GCC
On Fri, 3 Feb 2012, Richard Sandiford wrote:
> > Not quite a large portion, just the function return stubs (which I reckon
> > there are exactly four) that process values in $v0/$v1 as if they were
> > arguments. This is of course a non-standard calling convention that
> > breaks the ABI and shouldn't be exposed to the dynamic linker and the PLT.
> > Not even mentioning that three of these four stubs are not bigger than a
> > PLT entry they would need, and the fourth is two or so instructions
> > larger, so making them dynamic hardly makes point (the cost of the
> > indirect call from PLT also matters).
>
> But that isn't the only reason to use shared libraries.
That is true in the general case, but these MIPS16 stubs have essentially
been cast in stone and there's little room if any for change here. I
can't imagine a case where static linking of these four stubs would cause
trouble, but certainly I am open to any examples.
> > Given that this code (to support MIPS16 shared libraries) was obviously
> > never fully functional before this effort, I think it is about the right
> > time to remove some hacks I saw in glibc's dynamic linker that are meant
> > to avoid clobbering $v0/$v1 before someone tries to rely on them for real.
>
> FSF BFD doesn't generate MIPS16 PLTs though. Is this a CS-local change?
A patch is in the queue, together with microMIPS PLT entries (that you
have expected, haven't you?). I can't give you a specific schedule, but I
expect to propose it as soon as I've got the current batch of GDB changes
followed by the outstanding binutils clean-ups I got your feedback on that
I haven't finished processing yet, off my plate.
> If so, the criticism seems a little unfair. The FSF code is self-
> consistent: PLTs can be used for these stubs because the resolver
> function preserves the necessary registers. Traditional lazy binding
> stubs are avoided by not using %call16.
Please don't take it as criticism but as a starting point for discussion.
And certainly I did not intend to sound negative, I'm sorry if I did.
I'm just raising points I noted as MIPS16 PLT entries were being
developed. I do think though that it's a bit unfortunate that such a
creeping ABI change has been made here. I think in case of doubt it's
always safe to stick to the ABI.
Lazy binding stubs are less of concern for some reason that is not
entirely clear to me and we have no MIPS16 implementation in the queue
(but we do have microMIPS stubs, as you might have expected -- to
facilitate pure-microMIPS processors that may eventually appear).
> I don't think changing the resolver function so that it preserves
> fewer registers would be a good idea. As well as the MIPS16 thing,
> $3 is needed for _mcount.
I don't think _mcount has ever worked for dynamic libraries, has it? --
please correct me if I am wrong, but I believe `gprof' relies on memory
segments to be contiguous which is certainly not the case for a dynamic
executable where you have a separate set of mappings for the executable
proper and then for each shared library loaded.
I didn't know it required $3 for anything either -- I've thought it was
$1 only. How has it worked for standard MIPS code then?
We have only about now got MIPS16 shared libraries to work -- are you
sure removing code to save/restore $2/$3 in the dynamic linker is going to
hit anyone? While a small piece, this is still some wasted memory and
execution time for every executable on every system and whether MIPS16
code is involved or not (even on systems that do not support the MIPS16
ASE at all), just to cope with an ABI anomaly of literally four functions
only needed for some MIPS16 code (and which had not originally been
expected to be ever used for dynamic linking -- until recently nobody even
considered the use of MIPS16 code on a shared library system). And I
think you can still get into trouble if you use the wrong ld.so with your
MIPS16 executable -- or has symbol versioning been used to ensure that
ld.so bails out in this case?
> You're right of course that PLTs can't be used for __mips16_rdhwr.
Unless you want to waste text (and possibly stack) space and time to save
and restore call-clobbered registers in the caller that is. ;)
> I'd forgotten about that, sorry. Will fix this weekend.
>
> If there's still some concern that __mips16_rdhwr might not have
> the right ABI, then maybe we should simply emit a link-once function
> in each object that needs it. We could then switch to another function
> (and another API) without having to keep the old one in libgcc.a for
> compatibility. It would also avoid the -shared-libgcc thing.
>
> Admittedly that's just an off-the-top-of-my-head idea. :-)
> What do you think?
Actually I had that idea of a link-once function too, but it turned out
quite complicated to do without rewriting some generic parts of GCC as it
is currently not prepared to emit link-once functions outside C++
compilations. It's been a while and I did lots of other stuff meanwhile,
so please excuse me if I got anything wrong here.
Maciej