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
