[Tinycc-devel] Failed tests on win32
Hello ! Testing tinycc from the repository on a windows 7 32 bits with mingw32 the following tests fail: abitest.c: ret_2double_test abitest.c: reg_pack_longlong_test abitest.c: sret_test abitest.c: many_struct_test Cheers ! ___ 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
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 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
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] trying tinycc on several hundred projects (results)
Yes you are right, it was pointed by scan-build from llvm/clang and indeed
is a false positive, thanks for pointing it.
Cheers !
On Fri, Mar 28, 2014 at 7:13 PM, grischka wrote:
> 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
>
___
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] Tinycc from git still can't compile fossil-scm
The strange thing is that on linux 32bits it works fine without the las
hack.
On Fri, Mar 28, 2014 at 5:05 PM, Domingo Alvarez Duarte
wrote:
> 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] 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 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] 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 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] Valgrind Inconsistency detected by ld.so: rtld.c:
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 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
[Tinycc-devel] Valgrind Inconsistency detected by ld.so: rtld.c:
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
