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.
gcc-3.4.6 don't give such error by default
example file1
char __version_303_xxxxxxxx;
void func1() {}
example file2
char __version_303_xxxxxxxx;
void func2() {}
int main() { return 0; }
The call to build_got can cause symtab_section->data to be reallocated
(build_got -> add_elf_sym -> put_elf_sym -> section_ptr_add ->
section_realloc -> tcc_realloc). This is not obvious on a cursory
inspection, but fortunately Valgrind spotted it immediately.
Are there other, similar bugs that Valgrind did not detect?
* Documentation is now in "docs".
* Source code is now in "src".
* Misc. fixes here and there so that everything still works.
I think I got everything in this commit, but I only tested this
on Linux (Make) and Windows (CMake), so I might've messed
something up on other platforms...
* fix some macro expansion issues
* add some pp tests in tests/pp
* improved tcc -E output for better diff'ability
* remove -dD feature (quirky code, exotic feature,
didn't work well)
Based partially on ideas / researches from PipCet
Some issues remain with VA_ARGS macros (if used in a
rather tricky way).
Also, to keep it simple, the pp doesn't automtically
add any extra spaces to separate tokens which otherwise
would form wrong tokens if re-read from tcc -E output
(such as '+' '=') GCC does that, other compilers don't.
* cleanups
- #line 01 "file" / # 01 "file" processing
- #pragma comment(lib,"foo")
- tcc -E: forward some pragmas to output (pack, comment(lib))
- fix macro parameter list parsing mess from
a3fc543459a715d7143d
(some coffee might help, next time ;)
- introduce TOK_PPSTR - to have character constants as
written in the file (similar to TOK_PPNUM)
- allow '\' appear in macros
- new functions begin/end_macro to:
- fix switching macro levels during expansion
- allow unget_tok to unget more than one tok
- slight speedup by using bitflags in isidnum_table
Also:
- x86_64.c : fix decl after statements
- i386-gen,c : fix a vstack leak with VLA on windows
- configure/Makefile : build on windows (MSYS) was broken
- tcc_warning: fflush stderr to keep output order (win32)
Prior to this commit TinyCC was exporting symbols defined in programs
only when they resolve an undefined symbol of a library. However, the
expected behavior (see --export-dynamic in GNU ld manpage) is that all
symbols used by libraries and defined by a program should be exported in
dynsym section. This is because symbol resolution search first in
program and then in libraries, thus allowing program symbol to interpose
symbol defined in a library.
Usage example: tcc -xc ex5.cgi
From a gcc docs:
You can specify the input language explicitly with the -x option:
-x language
Specify explicitly the language for the following input files
(rather than letting the compiler choose a default based on the file
name suffix). This option applies to all following input files until
the next -x option. Possible values for language are:
c c-header c-cpp-output
c++ c++-header c++-cpp-output
objective-c objective-c-header objective-c-cpp-output
objective-c++ objective-c++-header objective-c++-cpp-output
assembler assembler-with-cpp
ada
f77 f77-cpp-input f95 f95-cpp-input
java
-x none
Turn off any specification of a language, so that subsequent files
are handled according to their file name suffixes (as they are if -x
has not been used at all)
* define targetos=Windows when --enable-tcc32-mingw, --enable-cygwin, ...
* use TARGETOS insteed HOST_OS when selecting PROGS
* use "$(tccdir)" insteed $(tccdir) on install (spaces in path)
* install tcc.exe too
* produce bcheck.o when cross-compiling too (lib/Makefile)
* force bcheck.o linking by compiling inside tcc_set_output_type()
a dummy program with local array. Otherwise bcheck.o may be not linked.
* replace %xz format specifier with %p in bcheck (don't supported on
Windows)
* call a __bound_init when __bound_ptr_add, __bound_ptr_indir,
__bound_new_region, __bound_delete_region called.
This is because a __bound_init inside ".init" section is not called
on Windows for unknown reason.
* print on stderr a message when an illegal pointer is returned:
there is no segmentation violation on Windows for a program
compiled with "tcc -b"
* remove "C:" subdir on clean if $HOST_OS = "Linux"
* default CFLAGS="-Wall -g -O0" insteed CFLAGS="-Wall -g -O2"
to speed up compilation and more precise debugging.
tcc w/o -g option generate an executable file which format
is not recognized by binutils. It is like stripped one but
binutils don't think so. Solution: generate not stripped
file which can be correctly stripped by external utils.
may be there is a need to handle a -s option and call
a sstrip/strip program to do a job.
- care about __attribute__ redefinition in the system headers
- an invalid pointer must be returned when (addr >= e->size),
and not (addr > e->size)
A test program:
#include <stdio.h>
#include <stdlib.h>
int main ()
{
int v[10];
fprintf(stderr, "&v[0] = %p\n", &v[0]);
fprintf(stderr, "&v[10] = %p\n", &v[10]);
exit(1);
return 0;
}
// tcc -b test.c
The output before a patch:
&v[0] = 0xbf929d8c
&v[10] = 0xbf929db4
The output after a patch:
&v[0] = 0xbff6e33c
&v[10] = 0xfffffffe
On Linux 32: sizeof(long)=32 == sizeof(void *)=32
on Linux 64: sizeof(long)=64 == sizeof(void *)=64
on Windows 64: sizeof(long)=32 != sizeof(void *)=64
A test program (must be compiled by the above version of the tcc):
/* Tickle a bug in TinyC on 64-bit systems:
* the LSB of the top word or ARGP gets set
* for no obvious reason.
*
* Source: a legacy language interpreter which
* has a little stack / stack pointer for arguments.
*
* Output is: 0x8049620 0x10804961c
* Should be: 0x8049620 0x804961c
*/
#include <stdio.h>
#define NARGS 20000
int ARG[NARGS];
int *ARGSPACE = ARG;
int *ARGP = ARG - 1;
main() { printf("%p %p\n", ARGSPACE, ARGP); }
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.
