- generate and use SYM@PLT for plt addresses
- get rid of patch_dynsym_undef hack (no idea what it did on FreeBSD)
- use sym_attrs instead of symtab_to_dynsym
- special case for function pointers into .so on i386
- libtcc_test: test tcc_add_symbol with data object
- move target specicic code to *-link.c files
- add R_XXX_RELATIVE (needed for PE)
MSVC does not support array designator so cannot compile source using
relocs_info. This commit replace the relocs_info array into a set of
functions, each returning the value given by a given field of the struct
reloc_info.
i386 target does not have PC relative loads. Its ABI therefore require
ebx register to points to the GOT when executing a PLT entry. This means
that PLT entry cannot be used transparently, the compiler needs to
expect execution of a PLT entry to be able to use one, that is a PLT
entry should only be created if the relocation explicitely asks for it
(eg. R_386_PLT32).
This patch creates a new target macro PCRELATIVE_DLLPLT to indicate
whether a target can do a PC relative load in PLT entry when building a
dynamic library. Executable do not normally pose a problem because they
are loaded at a fixed address and thus the absolute address of GOT can
be used.
Note that in such a case, if the compiler does not use a PLT aware
relocation for external access then the code relocation will fall on the
dynamic loader since there is no PLT entry to relocate too.
Static relocation of functions in dynamic libraries must use the PLT
entry as the target. Before this commit, it used to be done in 2 parts
for ARM, with the offset of the PLT entry from the beginning of the PLT
being put in the relocated place in build_got_entries () and then the
address of the PLT being added in relocate_section.
This led to code dealing with reading the offset of a bl instruction in
build_got_entries. Furthermore, the addition of the address of the start
of the PLT was done based on the relocation type which does not convey
whether a PLT entry should be used to reach the symbol.
This commit moves the decision to use the PLT as the target in
relocate_section, therefore having the instruction aware code contained
to the target-specific bit of that function (in <target>-link.c).
Note that relocate_syms is *not* the right place to do this because two
different relocations for the same symbol can make different decision.
This is the case in tcc -run mode where the static and dynamic
relocation are done by tcc.
Storing the PLT entry address in the symbol's st_value field and relying
on the specific relocation type being used for dynamic relocation would
work but the PLT entry address would then appear in the static symbol
table (symtab). This would also make the static symbol table entry
differ from the dynamic symbol table entry.
Change alloc_sym_attr into get_sym_attr and add a parameter to control
whether to allocate a new symattr structure or return NULL if symbol is
not found;
Currently GOT/PLT creation happens in two locations depending on whether
the GOT/PLT [entry] is required by the symbol or the relocation:
- bind_exe_dynsym for relocations to undefined symbol
- build_got_entries/put_got_entry for relocations that require a GOT/PLT
entry
This commit consolidate GOT/PLT creation in build_got_entries by
reducing bind_exe_dynsym's job to create a dynamic symbol for undefined
symbols. build_got_entries then invoke put_got_entry if the symbol being
relocated is undefined or the relocation asks for a PLT or GOT [entry].
put_got_entry is also modified to only export a symbol in the dynamic
symbol table when we are in the case of PLT/GOT [entry] required by the
relocation (since undefined symbol are already exported by
bind_exe_dynsym).
Currently we always build a GOT when we recognize a relocation in
build_got_entries even if the relocation does not require one. In the
same spirit, when the relocation does require one we always create a GOT
entry even if not entry is necessary. This patch restricts the creation
of a GOT and a GOT entry to relocations that needs it, ie:
- do not create a GOT if relocation is not related to GOT and symbol is
not UNDEF
- do not create a GOT entry if relocation only relates to beginning of
GOT
On ARM targets, the jump to ld.so resolution routine is done in PLT0 by
loading the offset to the GOT found in PLT+16 and from there loading the
address in GOT+8 and jumping to it.
Currently tcc starts the first regular PLT entry at PLT+16 which thus
does not contain the offset to the GOT. This commit fixes that.
Note that calls via PLT still worked nonetheless because of some missing
dynamic tag which makes ld.so behaves as if RTLD_BIND_NOW was specified
in the environment for all executable created by tcc.
add_elf_sym is a confusing name because it is not clear what the
function does compared to put_elf_sym. As a matter of fact, put_elf_sym
also adds a symbol in a symbol table. Besides, "add_elf_sym" fails to
convey that the function can be used to update a symbol (for instance
its value). "set_elf_sym" seems like a more appropriate name: it will
set a symbol to a given set of properties (value, size, etc.) and create
a new one if non exist for that name as one would expect.
Do not create a new symbol in add_elf_sym if a symbol with same properties
(value, size, info, etc.) already exists. This prevents symbols from
being exported twice in the dynamic symbol table.
Prior to this patch, an error would only be given when a library has an
unresolved undefined symbol if there is no undefined reference for the
same symbol in the executable itself. This patch changes the logic to
check both that the executable has the symbol in its static symbol table
*and* that it is defined to decide if the error path should be followed.
SHF_GROUP flag set on a section indicates that it is part of a section
group and that if the section is removed, the other sections in the same
group should be removed as well [1]. Since section group are guide for
the linking process, they do not have any meaning after linking has
occured. TCC rightfully [2] discard such sections (by not recognizing the
section type) but keeps the SHF_GROUP flag set on sections that were
part of a section group which confuses binutils (objdump and gdb at
least). Clearing that bit makes objdump and gdb accept binaries created
by TCC.
[1] https://docs.oracle.com/cd/E19683-01/816-1386/chapter7-26/index.html
[2] GNU ld does the same
- call RtlDeleteFunctionTable
(important for multiple compilations)
- the RUNTIME_FUNCTION* is now at the beginning of the
runtime memory. Therefor when tcc_relocate is called
with user memory, this should be done manually before
it is free'd:
RtlDeleteFunctionTable(*(void**)user_mem);
[ free(user_mem); ]
- x86_64-gen.c: expand char/short return values to int
With -run the call instruction and a defined function can be
far away, if the function is defined in the executable itself,
not in the to be compiled code. So we always need PLT slots
for -run, not just for undefined symbols.
Makefile :
- do not 'uninstall' peoples /usr/local/doc entirely
libtcc.c :
- MEM_DEBUG : IDE-friendly output "file:line: ..."
- always ELF for objects
tccgen.c :
- fix memory leak in new switch code
- move static 'in_sizeof' out of function
profiling :
- define 'static' to empty
resolve_sym() :
- replace by dlsym()
win32/64: fix R_XXX_RELATIVE fixme
- was fixed for i386 already in
8e4d64be2f
- do not -Lsystemdir if compiling to .o
Except
- that libtcc1.a is now installed in subdirs i386/ etc.
- the support for arm and arm64
- some of the "Darwin" fixes
- tests are mosly unchanged
Also
- removed the "legacy links for cross compilers" (was total mess)
- removed "out-of-tree" build support (was broken anyway)
-- Not a fix
This reverts commit 089ce6235c.
Revert "handle a -s option by executing sstrip/strip program"
-- related, not a fix.
This reverts commit 5cd4393a54.
- would parse linker args in two different places
- would mess up "tcc -v ..." output:
tcc -v test.c
-> test.c
+> test.c
- would use function "tcc_load_alacarte()" to do the contrary of
what its name suggests.
This reverts commit 19a169ceb8.
A patch is implemented as suggested in tinycc-devel mail list.
From: Reuben Thomas
Date: Thu, 31 Jul 2014 16:52:53 +0100
Subject: [PATCH] Add --{no,}-whole-archive support
I resurrected the patch supplied to the mailing list in 2009
Since --whole-archive is a useful flag to get tcc working with
autotools, and of course in its own right, I suggest you have a look
at the patch and see if it is acceptable. I cannot see any suggestion
that it was actively rejected last time round, just no evidence that
it was ever added.
Traditional behaviour on x86-64 is to encode the relocation
addend in r_addend, not in the relocated field (after all,
that's the reason to use RELA relocs to begin with). Our
linker can deal with both, other linkers as well. But using
e.g. the GNU assembler one can detect differences (equivalent
code in the end, but still a difference).
Now there's only a trivial difference in tests/asmtest.S
(having to do with ordering of prefixes).
This reloction must copy initialized data from the library
to the program .bss segment. Currently made like for ARM
(to remove noise of defaukt case). Is this true?
R_386_GOT32X can occur in object files assembled by new binutils, and in
particular do appear in glibc startup code (crt*.o). This patch is
modeled after the x86_64 one, handling the new relocation in the same
trivial way.
The introduction of read32le everywhere created a subtle issue, going
from
x = *(int*)p;
to
x = read32le(p);
is not equivalent if x is a larger than 32bit quantity, like an
address on x86_64, because read32le returns an unsigned int. The first
sign extends, the latter zero extends. This broke shared library
creation for gawk. It's enough to amend the case of the above
situation, cases like "write32le(p, read32le(p) +- something)" are okay,
no extensions happen or matter.
R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX can occur in object files
comiled by new binutils. They are not dynamic relocations, so normally
wouldn't be a problem for tcc (one doesn't normally mix object files
created by different compiler/binutils, static archives are so out :)).
If it weren't for the glibc startup code, crt*.o, of course. They now
do contain such relocs --> boom. Handle them in the trivial way.
