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 > Tinycc-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/tinycc-devel
diff --git a/elf.h b/elf.h
index 82fd7ed..fe694de 100644
--- a/elf.h
+++ b/elf.h
@@ -431,6 +431,7 @@ typedef struct
#define STT_SECTION 3 /* Symbol associated with a section */
#define STT_FILE 4 /* Symbol's name is file name */
#define STT_NUM 5 /* Number of defined types. */
+#define STT_GNU_IFUNC 10 /* Symbol is a indirect code object */
#define STT_LOOS 11 /* Start of OS-specific */
#define STT_HIOS 12 /* End of OS-specific */
#define STT_LOPROC 13 /* Start of processor-specific */
diff --git a/libtcc.c b/libtcc.c
index ade77c0..c9d37b8 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1431,7 +1431,11 @@ static void rt_printline(unsigned long wanted_pc)
sym < sym_end;
sym++) {
type = ELFW(ST_TYPE)(sym->st_info);
+#ifdef STT_IFUNC
+ if ((type == STT_FUNC) || (type == STT_GNU_IFUNC)) {
+#else
if (type == STT_FUNC) {
+#endif
if (wanted_pc >= sym->st_value &&
wanted_pc < sym->st_value + sym->st_size) {
pstrcpy(last_func_name, sizeof(last_func_name),
diff --git a/tccelf.c b/tccelf.c
index 4020e24..6156cc2 100644
--- a/tccelf.c
+++ b/tccelf.c
@@ -1378,9 +1378,10 @@ int elf_output_file(TCCState *s1, const char *filename)
build_got(s1);
/* scan for undefined symbols and see if they are in the
- dynamic symbols. If a symbol STT_FUNC is found, then we
- add it in the PLT. If a symbol STT_OBJECT is found, we
- add it in the .bss section with a suitable relocation */
+ dynamic symbols. If a symbol STT_FUNC or STT_GNU_IFUNC
+ is found, then we add it in the PLT. If a symbol
+ STT_OBJECT is found, we add it in the .bss section with
+ a suitable relocation */
sym_end = (ElfW(Sym) *)(symtab_section->data +
symtab_section->data_offset);
if (file_type == TCC_OUTPUT_EXE) {
@@ -1393,7 +1394,7 @@ int elf_output_file(TCCState *s1, const char *filename)
if (sym_index) {
esym = &((ElfW(Sym) *)s1->dynsymtab_section->data)[sym_index];
type = ELFW(ST_TYPE)(esym->st_info);
- if (type == STT_FUNC) {
+ if ((type == STT_FUNC) || (type == STT_GNU_IFUNC)) {
put_got_entry(s1, R_JMP_SLOT, esym->st_size,
esym->st_info,
sym - (ElfW(Sym) *)symtab_section->data);
@@ -1470,7 +1471,8 @@ int elf_output_file(TCCState *s1, const char *filename)
sym++) {
if (ELFW(ST_BIND)(sym->st_info) != STB_LOCAL) {
#if defined(TCC_OUTPUT_DLL_WITH_PLT)
- if (ELFW(ST_TYPE)(sym->st_info) == STT_FUNC &&
+ if ((ELFW(ST_TYPE)(sym->st_info) == STT_FUNC ||
+ ELFW(ST_TYPE)(sym->st_info) == STT_GNU_IFUNC) &&
sym->st_shndx == SHN_UNDEF) {
put_got_entry(s1, R_JMP_SLOT, sym->st_size,
sym->st_info,
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
