Don't use /usr/local/lib/tcc/libtcc1.a for i386 and x86_64
A $(tccdir)/i386 directory was used to install a libtcc1.a
but only when cross compiling. And no x86_64 directory.
And this directory location was unknown inside tccelf.c
It is a strange patch because before this commit a gdb is working well
and after this commit there is exactly the same problem on Linux:
gdb refuses to know "main"
Author: grischka <grischka>
Date: Tue Feb 5 21:18:29 2013 +0100
tccelf: fix debug section relocation
With:
tcc -g hello.c
gdb a.out
b main
gdb refused to know "main" because of broken dwarf info.
This adds some more support for properly transfering some
offsets over the different stages of a relocations life.
Still not at all psABI compliant and DSOs can't yet be generated.
But it runs the testsuite in qemu-arm64.
libtcc.c: Add greloca, a generalisation of greloc that takes an addend.
tcc.h: Add greloca and put_elf_reloca.
tccelf.c: Add put_elf_reloca, a generalisation of put_elf_reloc.
tccgen.c: On x86_64, use greloca instead of greloc in init_putv.
- revert to R_X86_64_PC32 for near calls on PE
- revert to s1->section_align set to zero by default
Untested. Compared to release_0_9_26 the pe-image looks back to
normal. There are some differences in dissassembly (r10/r11 usage)
but maybe that's ok.
Same as with x86_64, disable the runtime_plt_and_got hack
for -run on arm as well. For that we need to handle several
relocations as (potentially) generating PLT slots as well.
Tested with mpfr-3.1.2 and gawk (both using --disable-shared),
there are two resp. five pre-existing problems, so no regressions.
This also works toward enabling real shared libs for arm,
but it's not there yet.
This makes us use the normal PLT/GOT codepaths also for -run,
which formerly used an on-the-side blob for the jump tables.
For x86_64 only for now, arm coming up.
These relocations are used to express a dependency on a certain
symbol (e.g. for EABIs exception handling to the
__aeabi_unwind_cpp_pr{0,1,2} routines). Just ignore them in
reloc processing.
When output is memory we applied the correct GOT offset for certain
relocations (e.g. _GOT32), but we forgot to actually fill the got
entries with the final symbol values, so unconditionally create relocs
against .got as well.
This makes it so that the first PT_LOAD segment covers
ELF and program header and .interp (contained in the same page anyway,
right before the start of the first loaded section). binutils
strip creates invalid output otherwise (which strictly is a binutils
bug, but let's be nice anyway).
This correctly resolves local references to global functions from
shared libs to their PLT slot (instead of directly to the target
symbol), so that interposition works.
This is still not 100% conforming (executables don't export symbols
that are also defined in linked shared libs, as they must), but
normal shared lib situations work.
Introduce a new attribute to check the existence of a PLT entry for a
given symbol has the presence of an entry for that symbol in the dynsym
section is not proof that a PLT entry exists.
This fixes commit dc8ea93b13.
Some symbol (such as __gmon_start__ but this one does not matter to tcc)
can have both a R_386_GOT32 and R_386_PLT32 relocation. It is thus not
enough to test if a GOT reloc was already done when deciding whether to
return early from put_got_entry.
When bound check is enabled, tcc tries to relocate a call to
__bound_init in _init. This means that relocation (in tcc_add_bcheck)
must be done after libtcc1.a (which countains __bound_init) is loaded
but before crtn.o is loaded as this finalize _init.
Call fill_got_entry unconditionally from fill_got so as to avoid
warnings on !x86-64 architectures. This can be done since this code path
is only followed by x86-64 architecture anyway.
Variants __fixsfdi/__fixxfdi are not needed for now because
the value is converted to double always.
Also:
- remove __tcc_fpinit for unix as it seems redundant by the
__setfpucw call in the startup code
- avoid reference to s->runtime_main in cross compilers
- configure: fix --with-libgcc help
- tcctok.h: cleanup
When statically linking, runtime library should be static as well. tcc
could link with libgcc.a but it's in a gcc version specific directory.
Another solution, followed by this patch, is to use libtcc.a when
statically linking, even if USE_LIBGCC was configured.
TLS support in tinyCC is absolutely not ready:
- segment register not select in load and store
- no relocation added for computing offset of per-thread symbol
- no support for TLS-specific relocations
- no program header added as per Drepper document about TLS
This reverts commit 1c4afd1350.
This replaces -> use instead:
-----------------------------------
- tcc_set_linker -> tcc_set_options(s, "-Wl,...");
- tcc_set_warning -> tcc_set_options(s, "-W...");
- tcc_enable_debug -> tcc_set_options(s, "-g");
parse_args is moved to libtcc.c (now tcc_parse_args).
Also some cleanups:
- reorder TCCState members
- add some comments here and there
- do not use argv's directly, make string copies
- use const char* in tcc_set_linker
- tccpe: use fd instead of fp
tested with -D MEM_DEBUG: 0 bytes left
Should fix some warnings wrt. access out of array bounds.
tccelf.c: fix "static function unused" warning
x86_64-gen.c: fix "ctype.ref uninitialzed" warning and cleanup
tcc-win32.txt: remove obsolete limitation notes.
Also:
- fix "make tcc_p" (profiling version)
- remove old gcc flags:
-mpreferred-stack-boundary=2 -march=i386 -falign-functions=0
- remove test "hello" for Darwin (cannot compile to file)
With:
tcc -g hello.c
gdb a.out
b main
gdb refused to know "main" because of broken dwarf info.
This partially reverts commit 0d598aca08.
I don't remember what the problem was but it was the wrong way
to fix it.
Fix overflow detection for R_ARM_CALL, R_ARM_PC24, R_ARM_JUMP24 and
R_ARM_PLT32 relocations on ARM. 26 bits means 25 bits for positive and
negative offsets !
Indirect functions shall have STT_FUNC type in executable dynsym
section. Indeed, a dlsym call following a lazy resolution would pick the
symbol value from the executable dynsym entry. This would contain the
address of the function wanted by the caller of dlsym instead of the
address of the function that would return that address.
Revert commit 891dfcdf3f since it assumes
*all* architectures supported by tcc have GOT offsets aligned on 2. A
rework of this commit is being done since without it all PLT entries
grow by 4 bytes.
Since commit c6630ef92a, Call to a veneer
when the final symbol to be reached is thumb is made through a blx
instruction. This is a mistake since veneers are ARM instructions and
should thus be called with a simple bl. This commit prevent the bl ->
blx conversion when a veneer is used.
Generate PLT thumb stub for an ARM PLT entry only when at least one
Thumb instruction branches to that entry.
Warning: To save space, this commit reuses the bit 0 of entries of
got_offsets array. The GOT offset is thus saved in a 31 bit value.
Make sure to divide by 2 (right shift by 1) an offset before storing it
there and conversely to multiply the value by 2 (left shift by 1) before
using it.
Add support for relocations R_ARM_THM_JUMP24 and R_ARM_THM_CALL. These
are encountered with gcc when compiling for armv6 or greater with
-mthumb flag and a call (conditional or not) is done.
Introduce ARM version for the target architecture in order to determine
if blx instruction can be used or not. Availability of blx instruction
allows for more scenarii supported in R_ARM_CALL relocation. It should
also be useful when introducing support for the R_ARM_THM_CALL
relocation.
With R_ARM_CALL, if target function is to be entered in Thumb mode, the
relocation is supposed to transform bl in blx. This is not the case
actually so this commit is there to fix it.
Add support for relocations R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS as well
as their Thumb2 counterpart R_ARM_THM_MOVW_ABS_NC and
R_ARM_THM_MOVT_ABS. These are encountered with gcc when compiling for
armv7-a and a data is loaded in a register, either in arm or Thumb2
mode. The first half of the data is loaded with movw ; the second half
is loaded with movt.
Modify tcc to accept convert full 64bits of specified text section
when converting on Win64. Write high bytes to the elf section address
as well. This allows creation of elf binaries located in offsets using
full 64 bit addresses.
Signed-off-by: Andrew Mulbrook <andrew262@gmail.com>
This changeset attempts to fix a few problems when giving using
the high 32bits of a 64bit section offset. There are likely more
issues (or perhaps regressions) lurking in the muck here. In general,
this moves a few data type declarations to use uplong. Also, add
support for 64bit mingw32 building under cygwin. Because native
types are used for 64 bit offsets, this won't fix challenges with
cross compiling from 32bit -> 64bit.
Tested under cygwin, against binary compiled with
-Wl,-Ttext=0xffffff8000000000
Signed-off-by: Andrew Mulbrook <andrew262@gmail.com>
Remove the previous logic to link a named file with a loader script by
using tcc_add_dll instead. Hence, all files can be linked, not only
files ending in .so/.def.
TinyCC fails to link correctly to libraries when both R_ARM_PLT32 and
R_ARM_GOT32 relocation to a same symbol exist (see
http://lists.nongnu.org/archive/html/tinycc-devel/2010-05/msg00032.html
for more details).
The patch marks all undefined weak symbols found in external libraries
as strong. The value of all remaining weak symbols is set to zero just
before the section is output.
Note by Thomas Preud'homme: it's been 2 months in Debian without any new
bug report, hence commiting.
- use {B} to substitute tcc_lih_path (instead of \b)
- expand CONFIG_TCC_CRTPREFIX in CONFIG_TCC_LIBPATHS
which fixes duplicate CONFIG_SYSROOT.
- put default CONFIG_SYSROOT ("") into tcc.h
- remove hack from commit db6fcce78f
because $(tccdir)/include is already in sysincludes
- configure: error out for unrecognized options.
- win32/build-tcc.bat: put libtcc into base dir where it will
find lib/include automatically, and build libtcc_test example.
--sysincludepaths=.. specify system include paths, colon separated"
Sets CONFIG_TCC_SYSINCLUDEPATHS
--libpaths=... specify system library paths, colon separated"
Sets CONFIG_TCC_LIBPATHS
--crtprefix=... specify location of crt?.o"
Sets CONFIG_TCC_CRTPREFIX
--elfinterp=... specify elf interpreter"
Sets CONFIG_TCC_ELFINTERP
Also the CONFIG_TCC_XXX were renamed to make them look
more consistent.
Also move the elf_interp definitions to tcc.h.
Add a --multiarch-triplet switch to configure. The switch will allow
files to be search for each default path in path/<triplet> and then
path.
Default paths handled that way:
- CONFIG_TCC_SYSINCLUDE_PATHS
- CONFIG_TCC_LIBPATH
- path to crt*.o
- path to libgcc_s.so.1
Path missing: elf interpreter path (will be handled in another commit)
This allows passing colon separated paths to
tcc_add_library_path
tcc_add_sysinclude_path
tcc_add_include_path
Also there are new configure variables
CONFIG_TCC_LIBPATH
CONFIG_TCC_SYSINCLUDE_PATHS
which define the lib/sysinclude paths all in one and can
be overridden from configure/make
For TCC_TARGET_PE semicolons (;) are used as separators
Also, \b in the path string is replaced by s->tcc_lib_path
(CONFIG_TCCDIR rsp. -B option)
- r_addend should be applied for PLT entries as well
- R_X86_64_PLT32 should be handled just like R_X86_64_PC32
- spec says GLOB_DAT and JUMP_SLOT don't need r_addend (not tested)
http://www.x86-64.org/documentation/abi.pdf
Now we can -run ELF objects generated by GCC.
ARM architecture doesn't have any libtcc1 implementation but tcc load
libtcc1.a in all case. This patch add a conditional preprocessor
instruction to load libtcc1.a only when there is an implementation for
the target architecture.
Make sure alias symbols resolve to the same address in program .bss or .data
section. This ensure for example that if a program reference environ (via an
extern char **environ declaration) and the libc change its value via the
__environ alias after the R_ARCH_COPY relocation have been performed, then
the program will see the new value.
* Replace the save/load_buffer_state by a dynarray approach:
- Filename and libname are added to a dynarray when first encountered
- Load repeatedly the files in the dynarray until no new undefined
symbol are encountered
* Replace snprintf by sprintf in libname_to_filename
* Use tcc_fileextension in filename_to_libname
* Introduce a tcc_strcpy_part fonction to copy only a subset of a
string
* Move new_undef_syms declaration from tcc.h to tccelf.c
* search file from INPUT and GROUP commands in the library path in
addition to the current directory
* handle libraries specified by -lfoo options
* Search lib in GROUP command repeatedly
Without -Bsymbolic, a symbol/function in a *.so can be overridden
by a symbol/function in the main module.
That is the default search order, but not supported by tcc.
With -Bsymbolic, the linker tries to resolve a symbol/function in
the current module first.
The loader in tcc implements this search order.
We do not distinguish -Bsymbolic and -Bsymbolic-function
--
By by ... Detlef
On Sun, Nov 22, 2009 at 05:43:14PM +0100, Luigi Rizzo wrote:
> Hi,
> there is a well known problem with tcc and FreeBSD in the generation
> of elf objects -- see
> http://lists.gnu.org/archive/html/tinycc-devel/2005-07/msg00070.html
>
> Apparently Sergey Lyubka has tried a partial fix to the problem.
> I was wondering if Sergey or someone can post some more detail on
> what needs to be done so we can try to help fixing this issue
I think i have managed to solve the problem and produce
almost valid elf files on FreeBSD. The two patches attached
address a few problems (trying to explain to the
best of my knowledge; i am not very familiar with ELF and
the FreeBSD ELF conventions):
1. ELF file format
tcc produces an ELF executable which is good for linux but
not for FreeBSD. It misses the PHDR section which is almost
mandatory for shared executables, puts in the .dynsym section
some relocation info that FreeBSD expects to be in .got,
and expect the relocation sections to be contiguous.
patch-tccelf.c tries to address the above problem using
conditional sections (so hopefully can be imported upstream)
and also adds the ability to override the name of the dynamic
loader through an environment variable (this is important to
debug tcc).
2. predefined macros
patch-libtcc.c adds/fixes some predefined macros when compiling
on FreeBSD: these are __FreeBSD__ and the usual set of
__i386__ and __unix__ variants.
It also sets __INTEL_COMPILER so we can grab the __aligned
macro from cdefs.h , otherwise many programs would fail
The resulting elf file is still not 100% correct -- if you strip it,
the program will not run (presumably there is some dangling reference).
Other than that, program do seem to run correctly.
It would be nice to integrate these patches in the main repository.
The FreeBSD specific code is in #ifdef so it should not harm
linux users
cheers
luigi
TCC produces code which is incompatible with GCC for the following code:
printf("%lld\n", (long long)-2147483648);
printf("%lld\n", (long long)-2147483649);
For now, just avoid using the corner value.
- Now we can run tcc -run tcc.c successfully, though there are some bugs.
- Remove jmp_table and got_table and use text_section for got and plt entries.
- Combine buffers in tcc_relocate().
- Use R_X86_64_64 instead of R_X86_64_32 for R_DATA_32 (now the name R_DATA_32 is inappropriate...).
- Add got_table in TCCState. This approach is naive and the distance between executable code and GOT can be longer than 32bit.
- Handle R_X86_64_GOTPCREL properly. We use got_table for TCC_OUTPUT_MEMORY case for now.
- Fix load() and store() so that they access global variables via GOT.
- Add a macro TCC_OUTPUT_DLL_WITH_PLT.
-- Now, the DLL with PLT support works only on x86-64, but we may be able to support it on all architectures eventually.
- Define TCC_OUTPUT_DLL_WITH_PLT when target architecture is x86-64.
- Current status (x86-64):
-- Main program should be able to call functions in shared objects.
-- Main program should be able to use global variables in shared objects.
-- Shared objects should be able to call functions in main program.
-- Shared objects can NOT use global variables in main program.
- To fix the last issue, we may need to add support of -fPIC option in our code generator.
seyko