aboutsummaryrefslogtreecommitdiff
path: root/tccelf.c
Commit message (Collapse)AuthorAgeFilesLines
* Revert "--whole-archive support"grischka2016-10-011-3/+0
| | | | | | | | | | | | - 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 19a169ceb896f78205bc23b847938c58f14d1dda.
* Rein in unintended external functions.Jean-Claude Beaudoin2016-09-251-2/+2
|
* --whole-archive supportseyko2016-05-201-0/+3
| | | | | | | | | | | | | | | 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.
* x86_64: Use addend on relocsMichael Matz2016-05-091-1/+1
| | | | | | | | | | | | 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).
* tccpp: cleanup options -dD -dM, remove -Cgrischka2016-05-051-1/+1
| | | | | | | The lexer is for reading files, not for writing. Also : - macro_is_equal(): avoid crash if redefining __FILE__
* preprocessor oprtion -C (keep comments)seyko2016-04-151-1/+1
| | | | | This is done by impression of the pcc -C option. Usual execution path and speed are not changed.
* R_386_COPYseyko2016-04-031-0/+6
| | | | | | 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?
* Silence FIXME and compiler warningVlad Vissoultchev2016-03-131-0/+3
|
* i386: Add support for new psABI relocationThomas Preud'homme2015-12-271-2/+9
| | | | | | | 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.
* x86-64: fix shared libsMichael Matz2015-12-171-2/+4
| | | | | | | | | | | | | | 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.
* x86-64: Define symbol constant for new relocsMichael Matz2015-12-171-7/+9
| | | | | | Whoops, we have our own <elf.h> copy, so I can just as well add the symbol defines for the relocs instead of hard-coding numbers in tccelf.c.
* x86-64: Add support for new psABI relocationsMichael Matz2015-12-171-4/+10
| | | | | | | | | 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.
* tccelf.c: On arm64, use read64le, and use uint64_t to check range.Edmund Grimley Evans2015-11-201-3/+2
|
* Replace pointer casts with calls to (read|write)(16|32|64)le.Edmund Grimley Evans2015-11-191-121/+106
| | | | | This stops UBSan from giving runtime misaligned address errors and might eventually allow building on a non-little-endian host.
* tccelf.c: Avoid two trivial instances of undefined behaviour.Edmund Grimley Evans2015-11-091-2/+4
|
* defined twice: revertseyko2015-10-291-1/+1
| | | | An error message is changed to suggest -fcommon
* comment out tcc_error_noabort("'%s' defined twice"...seyko2015-10-251-1/+1
| | | | | | | | | | | 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; }
* tccelf.c: Reset sym after call to build_got.Edmund Grimley Evans2015-10-161-1/+3
| | | | | | | | 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?
* Revert all of my changes to directories & codingstyle.gus knight2015-07-291-0/+3504
|
* Reorganize the source tree.gus knight2015-07-271-3504/+0
| | | | | | | | | | * 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...
* Clean up lots of rogue tabs.gus knight2015-07-271-139/+139
| | | | | | Still some more tabs to be taken care of. arm-gen.c and tcccoff.c have so many style issues that I'm just going to throw clang-format at them.
* Trim trailing spaces everywhere.gus knight2015-07-271-1/+1
|
* tccpp: fix issues, add testsgrischka2015-05-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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 a3fc54345949535524d01319e1ca6378b7c2c201 a715d7143d9d17da17e67fec6af1c01409a71a31 (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)
* fix a potential end-of-buffer issue in tccelf.cPhilip2015-04-301-2/+5
| | | | | also read characters one at a time when PARSE_DEBUG is set; after this patch, things seem to work with that.
* Fix program symbols exported in dynsym sectionThomas Preud'homme2015-04-181-12/+11
| | | | | | | | | | 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.
* ability to specify a type of the input file with the -x switchseyko2015-04-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* fix "handle a -s option" commitseyko2015-04-101-12/+8
| | | | for targets which don't support variable length arrays.
* a bounds checking code for the ARCH=x86_64seyko2015-04-101-2/+0
|
* fix installation amd bcheck for Windowsseyko2015-04-101-15/+16
| | | | | | | | | | | | | | | | | | | | | | * 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.
* handle a -s option by executing sstrip/strip programseyko2015-04-101-0/+14
|
* output all sections if we produce an executable fileseyko2015-04-101-0/+1
| | | | | | | | | | 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.
* fix for the bcheck.o (bug #14958)seyko2015-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | - 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
* fix: try to add a bounds.o only if __bounds_init not foundseyko2015-03-281-3/+6
| | | | | | | | | | | | | | | /usr/local/lib/tcc/i386/bcheck.o: error: '__bound_error_msg' defined twice #include <stdio.h> int main () { #if 1 int v[10]; v[10] = 0; fprintf(stderr, "is bounds error catched?\n"); #endif return 0; } // tcc -b test.c
* make a bound checking more compatible with Windows 64seyko2015-03-261-1/+1
| | | | | | 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
* fix for the previous commit: tcc_add_support() was used before definitionseyko2015-03-261-25/+25
|
* fix: enforce bcheck.o linking when -b option is usedseyko2015-03-261-1/+4
| | | | | fixes a crash for the empry program (tcc -b empty.c) empty.c: int main() { return 0; }
* fix for: x86_64-tcc compiled by i386-tcc is wrongseyko2015-03-231-1/+1
| | | | | | | | | | | | | | | | | | | | | 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); }
* fix a gcc compiler warning for the previous commitseyko2015-03-231-1/+1
| | | | mark a constant as long long (or -std=gnu99 is needed)
* revert a commit: Work around for the issue TCC doesn't handle -2147483648 ↵seyko2015-03-231-1/+1
| | | | | | | properly because a tcc handle now -2147483648 properly. Look a commit: Make integer constant parsing C99 compliant
* A correction for the commit: revert a grischka patch: gdb refused to know "main"seyko2015-03-101-0/+7
| | | | | keep revert (check SHF_ALLOC) only for x86 target and keep a grishka patch for other targets
* Find libtcc1.a on arm32Michael Matz2015-03-091-1/+1
| | | | The directory is called "arm", not "ARM".
* tccelf.c: File path component is "arm64", not "ARM64".Edmund Grimley Evans2015-03-041-1/+1
|
* A 32/64 bit tcc on linux: an arch specific path for libtcc1.aseyko2015-03-031-1/+19
| | | | | | | 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
* tcc_add_runtime() for a CONFIG_USE_LIBGCC case: reducing a complexityseyko2015-03-031-5/+2
|
* Revert a grischka patch: gdb refused to know "main"seyko2015-03-031-1/+1
| | | | | | | | | | | | | | | 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.
* aarch64: Fix -run.Michael Matz2015-02-231-9/+53
| | | | | | | 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.
* Add arm64 (AArch64) as a target architecture.Edmund Grimley Evans2015-02-231-4/+133
|
* Use RELA relocations properly for R_DATA_PTR on x86_64.Edmund Grimley Evans2015-02-211-3/+12
| | | | | | | 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.
* tccelf: layout_sections: add missing param strsecMatteo Cypriani2014-09-071-3/+4
| | | | This fixes compilation on (k)FreeBSD.
* win64: try to fix linkagegrischka2014-06-241-14/+16
| | | | | | | | | - 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.