tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Support for indirect function in external modules


From: Thomas Preud'homme
Subject: Re: [Tinycc-devel] Support for indirect function in external modules
Date: Wed, 11 Aug 2010 01:11:05 +0200
User-agent: KMail/1.13.5 (Linux/2.6.32-5-686; KDE/4.4.5; i686; ; )

Le mardi 10 août 2010 22:57:13, vous avez écrit :
>  Hi y'all!
> 
>  I used Thomas Preud'homme's patch on the tcc-0.9.25 I had retrieved from
> sourceforge (on Ubuntu Lucid 10.04 x86_64: Linux Gypsy-IV 2.6.32-24-server
> #39-Ubuntu SMP Wed Jul 28 06:21:40 UTC 2010 x86_64 GNU/Linux)
> 
> I the tcc bootstraps again
> the bootstrapped tcc is able to compile the complete Eiffel 6.6.8 system
> and a sample program (freeze/finalize)... the sample program executes
> properly I applied 'patch' on elf.h & tccelf.c,
>  however the 3rd file (tccrun.cc) was nowhere to be found... yet everything
> works (I suspect T had a slightly more recent tcc version)
Indeed, the patch was done against latest mob. modifs in tccrun only affects 
error message (to say where in a file a parse error has occured).

A patch against tcc 0.9.25 is attached to this email
> 
>  Kudos to Thomas!!!
>  Vin
Happy to see that tcc bootstrap again :)

Best regards,

Thomas
> 
>  On 08/09/2010 11:24 AM, Thomas Preud'homme wrote:
> Hi all,
> 
> last version of GNU libc uses symbol with indirect function type (also
> known as STT_GNU_IFUNC) in its recent versions on x86_64 architecture.
> 
> This straightforward patch (pushed on mob with short sha1 bcc9137) allow
> tinycc to build against libraries using such type for symbol. Notes that
> this patch does not allow tcc to build executable or library with such
> symbol type. It only supports linking against such libraries.
> 
> Important note: The documentation I read about STT_GNU_IFUNC symbols says
> that when a code *load* (which is different from jump and calls) such a
> symbol, the value used should be either its GOTPLT (.got.plt) entry or its
> GOT entry depending on the context. I quickly look at the code and saw
> that whenever a STT_FUNC (or also STT_IFUNC now) is used, a GOT *and* a
> PLTGOT entry is created but I don't know which of the two entries is used
> depending on the context. But for what I saw, whenever there is a load,
> it's loaded from the same place (I guess it's loaded from GOT, according
> to first comment in load() in x86_64-gen.c).
> 
> I'm still lacking some tinycc knowledge about the link between source
> parsing and code generation so it would be quite long for me to add the
> necessary support. So could one of the tinycc guru add the code to handle
> this differentiation ? The rules about the value to load (GOTPLT entry or
> GOT entry) are explained in this document:
> 
> http://generic-abi.googlegroups.com/web/ifunc.txt?gda=xtGavTsAAADkRlZw3fTn8
> WF8pRDgf6aLfN_Atkb_cwXe6cZOcg5qrUgoJ4G7--yvLPBq95D3B7sGRdr3QrylPkw2aRbXD_gF
> 
> I quote:
> 
> "Note:
> 
> Instead of branching to an STT_GNU_IFUNC symbol directly, we always
> branch to its PLT entry, which simply loads its GOTPLT entry and branch
> to it.  Its GOTPLT entry has the real function address.  It has an
> optional GOT entry for the function pointer value of the symbol.  To
> load an STT_GNU_IFUNC symbol function pointer value,
> 
> 1. Use its GOTPLT entry in a shared object if it is forced local or not
> dynamic.
> 2. Use its GOTPLT entry in a non-shared object if pointer equality isn't
> needed.
> 3. Use its GOTPLT entry in a position independent executable (PIE).
> 4. Use its GOTPLT entry if no normal GOT, other than GOTPLT, is used.
> 5. Otherwise use its GOT entry.  We only need to relocate its GOT entry
> in a shared object."
> 
> Best regards,
> 
> Thomas Preud'homme
> 
> 
> _______________________________________________
> Tinycc-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tinycc-devel

Attachment: indirect_function.patch
Description: Text Data

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]