Re: [Tinycc-devel] Valgrind Inconsistency detected by ld.so: rtld.c:
And also on ubuntu 13.10 arm for the fossil-scm compiled with tcc: ==16261== Nulgrind, the minimal Valgrind tool ==16261== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote. ==16261== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==16261== Command: bld/translate ./src/branch.c ==16261== valgrind: m_debuginfo/readelf.c:2309 (vgModuleLocal_read_elf_debug_info): Assertion 'crc_offset + sizeof(UInt) = debuglink_sz' failed. ==16261==at 0x380ABB88: ??? (in /usr/lib/valgrind/none-arm-linux) On Fri, Mar 28, 2014 at 11:51 AM, Domingo Alvarez Duarte mingo...@gmail.com wrote: Now that valgrind works I run it on linux X86_64 against fossil-scm compiled with tcc and got this: ==32200== Nulgrind, the minimal Valgrind tool ==32200== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote. ==32200== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==32200== Command: /home/mingo/dev/c/fossil-src-20140127173344/fossil server ==32200== ==32200== ==32200== Process terminating with default action of signal 11 (SIGSEGV) ==32200== Access not within mapped region at address 0x18 ==32200==at 0x46BEB49: _int_malloc (malloc.c:3827) ==32200==by 0x46C0F94: malloc (malloc.c:2924) ==32200==by 0x8220083: __va_start (in /home/mingo/dev/c/fossil-src-20140127173344/fossil) Any clue on this ? Cheers ! On Fri, Mar 28, 2014 at 10:59 AM, Domingo Alvarez Duarte mingo...@gmail.com wrote: Hello ! Trying to test tinycc on linux X86_64 I get this error with valgrind: Inconsistency detected by ld.so: rtld.c: 1284: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed! Comparing the headers generated by other compilers it seem that tinycc is missing the PHDR entry, and making the following preprocessor test always true on tccelf.c seems to fix the problem, anyone knows this better and can explain it ? #if 1 // //defined(__FreeBSD__) || defined(__FreeBSD_kernel__) #define HAVE_PHDR 1 #define EXTRA_RELITEMS 14 /* move the relocation value from .dynsym to .got */ void patch_dynsym_undef(TCCState *s1, Section *s) Cheers ! ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
I found that on X86_64 linux if I do not free the memory on __va_end(), the compiled fossil-scm server works, I suspect is something with the fork/threads. --- void __va_end(struct __va_list_struct *ap) { //free(ap); } Cheers ! On Thu, Mar 27, 2014 at 12:23 PM, Domingo Alvarez Duarte mingo...@gmail.com wrote: When I say that fossil-scm compiled with tcc segfault I mean on linux X86_64, but on linux 32bits it does compile and work fine. So it's something specific to 64 bits. Cheers ! On Thu, Mar 27, 2014 at 11:50 AM, Domingo Alvarez Duarte mingo...@gmail.com wrote: Hello ! Even with our latest bug fixes tinycc fail to compile fossil-scm, I mean it does compile but segfault after a few malloc calls. Cheers ! ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] trying tinycc on several hundred projects (results)
Domingo Alvarez Duarte wrote: Fix a incorrect size for malloc. --- libtcc.c --- index 601999e..9f486f3 100644 @@ -328,11 +328,11 @@ static void tcc_split_path(TCCState *s, void ***p_ary, int *p_nb_ary, const char ST_FUNC Section *new_section(TCCState *s1, const char *name, int sh_type, int sh_flags) { Section *sec; -sec = tcc_mallocz(sizeof(Section) + strlen(name)); +sec = tcc_mallocz(sizeof(Section) + strlen(name)+1); This was not incorrect. --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
Hi, On Wed, 26 Mar 2014, Domingo Alvarez Duarte wrote: On my commit It would be easier if you wrote your reasons for doing things in mails, not only in commit messages, it makes quoting much harder. Anyway, in the commit message you wrote: I found the problem it was because CValue stack variables have rubish as it inital values and assigning to a member that is smaller than the big union item and trying to recover it later as a different member gives bak garbage. ST_FUNC void vset(TCCState* tcc_state, CType *type, int r, int v) { CValue cval; memset(cval, 0, sizeof(CValue)); cval.i = v; //, here is the main bug that mix with garbage vsetc(tcc_state, type, r, cval); } ... vset only initializes the .i member, that's an invariant. If you want to read out something else later you have to use other functions, or set vtop-correctmember after vset yourself ... static void init_putv(TCCState* tcc_state, CType *type, Section *sec, unsigned long c, int v, int expr_type) { ... case VT_PTR: if (tcc_state-tccgen_vtop-r VT_SYM) { greloc(tcc_state, sec, tcc_state-tccgen_vtop-sym, c, R_DATA_PTR); } // on the next line is where we try to get the assigned value to cvalue.i as cvalue.ull *(addr_t *)ptr |= (tcc_state-tccgen_vtop-c.ull bit_mask) bit_pos; ... like here. You either need to find out which vset() it was that created the vtop used above and fix that (to initialize -c.ull), or access only -c.i here and extend it to unsigned long long yourself, depending on what's the right thing. (That will generally require looking at the type of vtop and access the right member according to that). The thing you did (simply zeroing all local CValues) doesn't fix the bug (it papers over it, and on big-endian platforms doesn't even do that), and generates needless code. Please revert and fix it correctly. Or post a testcase here that breaks without that zeroing, in which case I'll promise to take a look. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
It's simple remove the zeroing CValues and try make clean, make and make test you'll see that on linux 32 bits and linux 64 bits and you'll see that it doesn't pass the tests, on linux 32 bits try make test -i and you'll see garbage been generated. And I did not create that code I only found it as is an the bug pointed and found this solution to be a good programming pratice. Now again can you explain me why zeroing CValues will produce incorrect results on big-endian platforms, I didn't found this anywhere ! Thanks in advance for your time, attention and great work ! On Fri, Mar 28, 2014 at 7:58 PM, Michael Matz matz@frakked.de wrote: Hi, On Wed, 26 Mar 2014, Domingo Alvarez Duarte wrote: On my commit It would be easier if you wrote your reasons for doing things in mails, not only in commit messages, it makes quoting much harder. Anyway, in the commit message you wrote: I found the problem it was because CValue stack variables have rubish as it inital values and assigning to a member that is smaller than the big union item and trying to recover it later as a different member gives bak garbage. ST_FUNC void vset(TCCState* tcc_state, CType *type, int r, int v) { CValue cval; memset(cval, 0, sizeof(CValue)); cval.i = v; //, here is the main bug that mix with garbage vsetc(tcc_state, type, r, cval); } ... vset only initializes the .i member, that's an invariant. If you want to read out something else later you have to use other functions, or set vtop-correctmember after vset yourself ... static void init_putv(TCCState* tcc_state, CType *type, Section *sec, unsigned long c, int v, int expr_type) { ... case VT_PTR: if (tcc_state-tccgen_vtop-r VT_SYM) { greloc(tcc_state, sec, tcc_state-tccgen_vtop-sym, c, R_DATA_PTR); } // on the next line is where we try to get the assigned value to cvalue.i as cvalue.ull *(addr_t *)ptr |= (tcc_state-tccgen_vtop-c.ull bit_mask) bit_pos; ... like here. You either need to find out which vset() it was that created the vtop used above and fix that (to initialize -c.ull), or access only -c.i here and extend it to unsigned long long yourself, depending on what's the right thing. (That will generally require looking at the type of vtop and access the right member according to that). The thing you did (simply zeroing all local CValues) doesn't fix the bug (it papers over it, and on big-endian platforms doesn't even do that), and generates needless code. Please revert and fix it correctly. Or post a testcase here that breaks without that zeroing, in which case I'll promise to take a look. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Code refactoring to remove globals phase1 done.
Hello all ! I finished phase1 of code refactoring of tinycc to remove global variables, not all global variables are removed yet but most of then are, with that it can cross compile all platforms on my linux X86_64 and till only on real test was done on linux. Here you can find the repository to test yourselves https://github.com/mingodad/tinycc any comment/suggestion/patch are welcome. Thanks for your time, attention and great work ! ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel