Re: [Tinycc-devel] TinyCC as selfcontaining compiler

[Domingo Alvarez Duarte]

I once did something related to this and can be seen here 
https://github.com/mingodad/tinycc/blob/af686a796bda94dc92fc3ad140ef438dafa08950/libtcc.h#L44 
and here 
https://github.com/mingodad/tinycc/blob/af686a796bda94dc92fc3ad140ef438dafa08950/libtcc.c#L479 
.


On 6/6/23 21:50, draco wrote:

Dear TinyCC community,

first: Thanks for all the work that goes into maining tcc all the years,
I'm a regular reader of the mailing list.


I developed a little add-on//patch to TinyCC which I call ziptcc.

It enables tcc to read include files etc from a single zip or even from
it's own exe (if it's a sfx zip).

So, this is kind of self-containing compiler...

You can find the (proof of concept) code on my github:

https://github.com/MichaelMiR01/ziptcc_dev

I appreciate any (most) feedback

Michael


__
Aktuelle Lichtmaschinenkunst

http://mir52.wordpress.com


___
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] Calling for Release 0.10.0

[Domingo Alvarez Duarte]

Hello all !

I would like to offer my patch for fully reentrant TCC for the upcoming 
release (see here https://github.com/mingodad/tinycc ) !


Cheers !

On 31/5/23 15:07, John Mastronardo via Tinycc-devel wrote:


David Koch is spot on. I couldn’t agree more, and I’m paraphrasing him 
here:


Pause the adventurous code. Do a feature freeze and a comparison 
checklist with other compilers. Then thoroughly test a few release 
candidates with a chosen set of popular platforms. After that, publish 
a completely stable new official TCC 10.0 that we can be proud of.


Like David, I’d like TCC to be treated more professionally than its 
original legacy.


And, I also thank you all for putting your time and passion into its 
maintenance.


—JM




On May 29, 2023, at 6:06 PM, david.k...@libertysurf.fr wrote:

Hi Detlef,

I don't care about the "simplicity" of tcc and its supposed goal not 
to compete with larger and more established compilers like gcc or clang.


Tcc still have to be reliable and not falling on simple corner cases 
because someone decided to push a patch on the mob branch, requiring 
someone else to remove it.


I'd like tcc not to be considered just a "quick hack" or a "toy 
compiler" due to its inherent simplicity, it still have to produce 
correct and reliable code.


Especially since its internals are so "simple", there is no reason 
tcc couldn't be thoroughly tested and stabilized orthogonally across 
all supported architectures.


It's been more than 5 years since the last "stable" release, I'd like 
the next one to be as much "reliable" despite the mob branch will 
still remain the Wild Wide West of salvage patches.


Experimenting is one thing, but regarding the last few months of 
adventurous code modifications and group discussions, I would NOT bet 
on just numbering the current state as being the new 0.10.0.


Let's do a feature freeze first, a comparison checklist with other 
compilers, supporting common flags and attributes, producing correct 
binary files (Windows, Linux, Mac, ...).


Then after a few release candidates, maybe only we could decide the 
last RC to be worthwhile enough to get released with the new official 
0.10.0 tags that we could feel proud of.


Until then tcc:mob will just remain a nerd's joke and a geek's 
playground that only a few insiders can really use it after great 
hacking to get it to work almost like expected.


Our view on tcc may diverge, but rest assured I like it anyway, I 
just would like it to be treated more fairly and professionally than 
its original legacy.


Thank you all for putting all such time and passion into its maintenance.

Regards.


- Mail d'origine -
De: wine dev 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 29 May 2023 14:39:17 +0200 (CEST)
Objet: Re: [Tinycc-devel]  Re :  Calling for Release 0.10.0


[Tinycc-devel] Re :  Calling for Release 0.10.0 – Hi,

the mob branch is pretty much unstable.

Before turning the mob branch into a new release, better do some 
thorough

checking and regression testing.

And have something consistent across the various supported platforms 
(x86,

AMD64, ARM, M1, RISC-V, ...).

Regards. [...]


Where do you see tcc to be unstable?

Yes, the last patch is ugly and should be removed or fixed
(path is created with alloca and later overwritten with malloc),
and that patch is only used as fallback,
when CONFIG_TCCDIR is undefined.

Primary goals for tcc are:
* Compile to correct code,
* as fast as possible,
* while being as simple as possible


For memory leaks from malloc, which are only freed at program shutdown:
A design decision is not a bug.
* tcc is a short running program,
   and a design decission to not free every memory from malloc
   is also done by other compiler for speed reasons:
   (look at DMC or DMD as examples.)
   (i dont know, if both compiler do not free, but i can remember,
that walter bright wrote, not to free memory was his
design decision for speed reasons).
* things done in libtcc are different,
   as the programm, which is using libtcc might live longer.
   I would suggest to fix memory leaks in libtcc.


For using an object format, with is not the same, what most other 
compiler

use on that system:
A design decision, and not a bug
Disadvantage:
* You can't link object files from other compiler
Advantage:
* simplify the code generator, the linker and probably other tools

This is also done by other compiler for many Years:
* Watcom/OpenWatcom uses OMF
* Embarcadero C++ Builder:
   The newer compiler are based on clang
   and use ELF object files also on Windows

-​-
Regards ... Detlef


___
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 mailing 

Re: [Tinycc-devel] C23 front end

[Domingo Alvarez Duarte]

Hello Thiago !

I also think that this project https://github.com/melt-umn/ableC can of 
your interest:


Their description:



AbleC is a C11 compiler front-end that supports modular definition and 
reliable composition of language extensions. AbleC is implemented 
usingSilver <https://github.com/melt-umn/silver>.


=

Cheers !

On 30/5/23 9:48, Domingo Alvarez Duarte wrote:


Hello Thiago !

Maybe this project https://github.com/graphitemaster/gmqcc can be of 
your interest to use as backend on the playground.


Cheers !

On 30/5/23 3:44, Thiago Adams wrote:

Apologies if this is a wrong place for this e-mail.

I am creating a c23 front end called cake 
https://github.com/thradams/cake 
<https://github.com/thradams/cake> and TCC is an inspiration for me 
mainly because it is a complete compiler.


I can try to help TCC with some C23 features but I am also interested 
in to learn about backends (I have no experience in this field).


Maybe someone from this list also may be interested in creating new 
backends or helping me to find references to implement a backend for 
cake. I wish cake could generate an executable like TCC does. I have 
considered web assembly for the backend as well. also QBE for QBE 
does not generate executables directly.


I have little experience with TCC I don’t know for instance how many 
warnings/erros it have or how prepared it is for C 23.


 cake is progressing to full analysis semantics and I believe It 
already have the infrastructure to implement good warnings.


My interest in on compilers but also in promoting/modernising and 
using the C language.


Thanks
Thiago



___
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] C23 front end

[Domingo Alvarez Duarte]

Hello Thiago !

Maybe this project https://github.com/graphitemaster/gmqcc can be of 
your interest to use as backend on the playground.


Cheers !

On 30/5/23 3:44, Thiago Adams wrote:

Apologies if this is a wrong place for this e-mail.

I am creating a c23 front end called cake 
https://github.com/thradams/cake 
 and TCC is an inspiration for me 
mainly because it is a complete compiler.


I can try to help TCC with some C23 features but I am also interested 
in to learn about backends (I have no experience in this field).


Maybe someone from this list also may be interested in creating new 
backends or helping me to find references to implement a backend for 
cake. I wish cake could generate an executable like TCC does. I have 
considered web assembly for the backend as well. also QBE for QBE does 
not generate executables directly.


I have little experience with TCC I don’t know for instance how many 
warnings/erros it have or how prepared it is for C 23.


 cake is progressing to full analysis semantics and I believe It 
already have the infrastructure to implement good warnings.


My interest in on compilers but also in promoting/modernising and 
using the C language.


Thanks
Thiago



___
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] TCC produced wrong code (yarpgen v1)

[Domingo Alvarez Duarte]

Sorry !

It was my fault I was testing with a not mob tinycc, using mob the 
failed example I've showed before doesn't happen.


Cheers !

On 8/3/23 12:02, Domingo Alvarez Duarte wrote:

Using this script:



yarpgen --std=c
#../c2m driver.c func.c -ei
gcc -o ygcc driver.c func.c && ./ygcc
tinycc-env tcc -o ytcc driver.c func.c && ./ytcc



It gives different result than gcc after 4 trials:



check-it.sh
/*SEED 2003917550*/
5782830862525388415
1507557374623343254



Cheers !

On 7/3/23 18:23, Michael Matz wrote:

Hey,

On Sat, 18 Feb 2023, wine@web.de wrote:


While trying yarpgen (v1 branch of github.com/intel/yarpgen ),
various test files compiled with tcc (x86_64@linux) produce a wrong 
result.


I compared the first failed program with gcc
and found an "if" section in the example code,
where the compiled programs from both compiler
(tcc and gcc-12) enter the "true" section,
but in the middle of the "if" sections,
the tcc compiled code breaks out of the "true" part of the "if" section
and execution continiues at the start of the "false" section.

Very strange


The problem (at least for the 'yarpgen -s 5' generated program) is 
fixed in mob now.  I haven't tried yarpgen on more than your reported 
example, so you might want to check yourself.


FWIW, the problem was that too complicated expressions involving 
short-circuiting || and && with constant operands sometimes left code 
generation deactivated to further statements outside the expression 
(which is why it seemed to jump from inside the true if block to some 
random other place).



Ciao,
Michael.



Any idea, how to nail down the issue?

I already increased some internal stacks:
#define INCLUDE_STACK_SIZE  932
#define IFDEF_STACK_SIZE    964
#define VSTACK_SIZE 9256
#define STRING_MAX_SIZE 91024
#define TOKSTR_MAX_SIZE 9256
#define PACK_STACK_SIZE 98


The example source works with clang (v15) and gcc (v12)
and is attached to a bug report:
https://savannah.nongnu.org/bugs/?63816




___
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 mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TCC produced wrong code (yarpgen v1)

[Domingo Alvarez Duarte]

Using this script:



yarpgen --std=c
#../c2m driver.c func.c -ei
gcc -o ygcc driver.c func.c && ./ygcc
tinycc-env tcc -o ytcc driver.c func.c && ./ytcc



It gives different result than gcc after 4 trials:



check-it.sh
/*SEED 2003917550*/
5782830862525388415
1507557374623343254



Cheers !

On 7/3/23 18:23, Michael Matz wrote:

Hey,

On Sat, 18 Feb 2023, wine@web.de wrote:


While trying yarpgen (v1 branch of github.com/intel/yarpgen ),
various test files compiled with tcc (x86_64@linux) produce a wrong 
result.


I compared the first failed program with gcc
and found an "if" section in the example code,
where the compiled programs from both compiler
(tcc and gcc-12) enter the "true" section,
but in the middle of the "if" sections,
the tcc compiled code breaks out of the "true" part of the "if" section
and execution continiues at the start of the "false" section.

Very strange


The problem (at least for the 'yarpgen -s 5' generated program) is 
fixed in mob now.  I haven't tried yarpgen on more than your reported 
example, so you might want to check yourself.


FWIW, the problem was that too complicated expressions involving 
short-circuiting || and && with constant operands sometimes left code 
generation deactivated to further statements outside the expression 
(which is why it seemed to jump from inside the true if block to some 
random other place).



Ciao,
Michael.



Any idea, how to nail down the issue?

I already increased some internal stacks:
#define INCLUDE_STACK_SIZE  932
#define IFDEF_STACK_SIZE    964
#define VSTACK_SIZE 9256
#define STRING_MAX_SIZE 91024
#define TOKSTR_MAX_SIZE 9256
#define PACK_STACK_SIZE 98


The example source works with clang (v15) and gcc (v12)
and is attached to a bug report:
https://savannah.nongnu.org/bugs/?63816




___
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 mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] test failures on win32 x86-64

[Domingo Alvarez Duarte]

Looking through the code on "tests/tcctest.c" there is more places using 
"[unsigned] long" that probably will need to be revised to use 
"[unsigned] long long" or "size_t".


Probably in several other places see bellow for a search on my fork:

=

va_list.c
extern void *memcpy(void *dest, const void *src, unsigned long n);  
[position 26:59]
    ap->overflow_arg_area = (char*)((long 
long)(ap->overflow_arg_area + align - 1) & -align); [position 59:42]
    ap->overflow_arg_area = (char*)((long 
long)(ap->overflow_arg_area + align - 1) & -align); [position 59:47]

va_list.c
extern void *memcpy(void *dest, const void *src, unsigned long n);  
[position 26:59]
    ap->overflow_arg_area = (char*)((long 
long)(ap->overflow_arg_area + align - 1) & -align); [position 59:42]
    ap->overflow_arg_area = (char*)((long 
long)(ap->overflow_arg_area + align - 1) & -align); [position 59:47]

tcctest.c
enum ELong {  [position 598:7]
    EL_large = ((unsigned long)0xf000 << 31) << 1,  [position 601:27]
    i = ((long)p) >> 32;  [position 927:11]
    unsigned long flags;  [position 1003:14]
    unsigned long index;  [position 1011:15]
    unsigned long counters;  [position 1015:15]
    long u3;  [position 1024:6]
    long u4;  [position 1025:6]
    unsigned long compound_head;  [position 1029:15]
} __attribute__((aligned(2 * sizeof(long;  [position 1034:37]

 unsigned long ul = 0x8000UL;  [position 1585:14]
   (long)p, (unsigned long)p,  [position 1632:13]
   (long)p, (unsigned long)p,  [position 1632:31]
   (long long)p, (unsigned long long)p);  [position 1633:13]
   (long long)p, (unsigned long long)p);  [position 1633:18]
   (long long)p, (unsigned long long)p);  [position 1633:36]
   (long long)p, (unsigned long long)p);  [position 1633:41]
    printf("0x%lx\n", (unsigned long)(int)ul);  [position 1641:33]
    long diff;  [position 2353:5]
long __pa_symbol(void)  [position 2848:1]
   return ((long)(((unsigned long)())) - 
(0x8000UL));  [position 2855:17]
   return ((long)(((unsigned long)())) - 
(0x8000UL));  [position 2855:34]

    printf("cmpfn=%lx\n", (long)cmpfn);  [position 2880:28]
    printf("cmpfn=%lx\n", (long)cmpfn);  [position 2886:28]
    printf("sizeof(long) = %d\n", sizeof(long));  [position 3006:20]
    printf("sizeof(long) = %d\n", sizeof(long));  [position 3006:42]
    printf("sizeof(unsigned long) = %d\n", sizeof(unsigned long));  
[position 3007:29]
    printf("sizeof(unsigned long) = %d\n", sizeof(unsigned long));  
[position 3007:60]

void consume_ulong (unsigned long i)  [position 3078:15]
void consume_ulong (unsigned long i)  [position 3078:30]
       long pre = 48;  [position 3131:5]
       long post = 49;  [position 3133:5]
    printf ("stmtexpr: %ld %ld\n", (long)h.first, (long)h.last);  
[position 3137:37]
    printf ("stmtexpr: %ld %ld\n", (long)h.first, (long)h.last);  
[position 3137:52]
    consume_ulong(({ __label__ __here; __here: (unsigned long)&&__here; 
}));  [position 3140:14]
    consume_ulong(({ __label__ __here; __here: (unsigned long)&&__here; 
}));  [position 3140:58]
    :"0" (n/4), "q" (n),"1" ((long) to),"2" ((size_t) from) [position 
3249:28]
    :"0" (n/4), "q" (n),"1" ((long) to),"2" ((size_t) from) [position 
3267:28]

    unsigned long addr;  [position 3336:14]
unsigned long mconstraint_test(struct struct1231 *r) [position 3339:10]
    unsigned long ret;  [position 3341:14]
    unsigned long ret;  [position 3363:14]
    printf ("oc1: %d\n", ret == (unsigned long)); [position 3367:43]
    "some_symbol: .long 0\n"  [position 3415:18]
    "2:\t.long 1b - 2b, %c0 - 2b\n"  [position 3422:9]
    ".long 661b - .\n" /* This reference to 661 generates an external 
sym*/  [position 3440:7]

    register long val asm("r12");  [position 3484:14]
    long val2;  [position 3485:5]
    long x1, x2;  [position 3500:5]
static long cpu_number;  [position 3511:8]
void trace_console(long len, long len2)  [position 3512:20]
void trace_console(long len, long len2)  [position 3512:30]
  long pscr_ret__;  [position 3531:15]
   long pfo_ret__;  [position 3535:24]
   long pfo_ret__;  [position 3544:24]
  long rdi;  [position 3566:3]
    struct struct1231 s2 = { (unsigned long) }; [position 3668:40]
    unsigned long asmret;  [position 3673:14]
int force_get_order(unsigned long s)  [position 4170:30]
elf.h
libtcc.c
 * License along with this library; if not, write to the Free 
Software  [position 17:13]

PUB_FUNC void *tcc_malloc_base(unsigned long size)  [position 256:41]
PUB_FUNC void *tcc_mallocz_base(unsigned long size)  [position 267:42]
PUB_FUNC void *tcc_malloc(TCCState 

Re: [Tinycc-devel] test failures on win32 x86-64

[Domingo Alvarez Duarte]

Hello Michael !

Thank you for your great work !

I applied your changes to my fork but the tests continue to fail on 
window see the result here 
https://github.com/mingodad/tinycc/actions/runs/3282234645/jobs/5405354710 .


Cheers !

On 19/10/22 14:36, Michael Matz wrote:

Hello,


On Fri, 14 Oct 2022, avih via Tinycc-devel wrote:


0x7ff72b42b266 <+50>: repnz scas %es:(%rdi),%al
0x7ff72b42b268 <+52>: dec %edi


This is the problem.  "dec %edi" truncates the %rdi register to 32bit 
by zero-extension, so that ...



0x7ff72b42b26a <+54>: mov 0x30(%rbp),%ecx
0x7ff72b42b26d <+57>: dec %ecx
0x7ff72b42b26f <+59>: js 0x7ff72b42b277 
0x7ff72b42b271 <+61>: lods %ds:(%rsi),%al
=> 0x7ff72b42b272 <+62>: stos %al,%es:(%rdi)


... this insn now segfault.  That only matters if the stack (which 
%rdi points into) is setup such that it's beyond 32bit, which ...



rdi 0xcb9ff955 3416258901
rbp 0x4ecb9ff8f0 0x4ecb9ff8f0
rsp 0x4ecb9ff8e0 0x4ecb9ff8e0


... is indeed the case on win10 for you.  So, it's not malloc() 
result, but it does have to do with address space layout.


The problem is that win64 is an IL32 platform, so that 'long' is not 
the same size as a pointer, but the strncat1 implementation, coming 
from the linux kernel, expects that to be the case.  The below patch 
should fix it, but I can't test on win64, so please check yourself and 
commit if it does.



Ciao,
Michael.

--

diff --git a/tests/tcctest.c b/tests/tcctest.c
index f5bd9aab..1d625b0c 100644
--- a/tests/tcctest.c
+++ b/tests/tcctest.c
@@ -3254,7 +3254,7 @@ void local_label_test(void)
 /* from linux kernel */
 static char * strncat1(char * dest,const char * src,size_t count)
 {
-long d0, d1, d2, d3;
+size_t d0, d1, d2, d3;
 __asm__ __volatile__(
    "repne\n\t"
    "scasb\n\t"
@@ -3276,7 +3276,7 @@ return dest;

 static char * strncat2(char * dest,const char * src,size_t count)
 {
-long d0, d1, d2, d3;
+size_t d0, d1, d2, d3;
 __asm__ __volatile__(
    "repne scasb\n\t" /* one-line repne prefix + string op */
    "dec %1\n\t"

___
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] test failures on win32 x86-64

[Domingo Alvarez Duarte]

It seems that something changed on windows itself because my fork was 
passing the tests before and now without any substantial change is 
failing see here https://github.com/mingodad/tinycc/actions , and I also 
tested on Windows7 32 bits and all tests pass.


On 14/10/22 11:24, avih via Tinycc-devel wrote:

In reply to the second half of:
https://lists.nongnu.org/archive/html/tinycc-devel/2022-10/msg00021.html

> As to spurious problems with MSYS2 I can only say that in my experience
> it is not a completely reliable build system.
>
> As a derivative from cygwin it shares the same fork() emulation hack,
> and I've seen it sub-processes just silently terminating (or maybe not
> even start them) with no failure code whatsoever.
>
> That would not affect the built tcc itself however it could affect the
> 'diff' used by the tests for example.

I think I removed the cygwin/fork/diff variables as follows:

I'm using this, which is a reproducible mingw env without cygwin:
https://github.com/skeeto/w64devkit/releases/tag/v1.16.1

building tcc (simply configure && make) within this environment
is producing identical tcc.exe, libtcc.dll, libtcc1.a on both my
Windows 10 system (32G ram) and my Windows 7 system (16G ram).

"make test" succeeds on win7 but fails on win10.

_Before_ commit d76e0323 (win64: hi-mem adjustments) test 104
failed also when invoked manually as:
cd tests/tests2 && path/to/inttalled/tcc 104+_inline.c -run 104_inline.c

where on win7 it printed things and exited successfully, while on
win10 it printed "tcc: error: internal error: relocation failed".

So it's also not an issue of diff not running correctly.

I took the liberty to print the value which fails ("diff") and its
origin (s->sh_addr at relocate_section), and noticed that on win10
it's 41-44 bits values, while on win7 it's 22-24 bits values.

I guessed that this might be an address from malloc, and checked
which values malloc returns using this program (source link below):

int msb(unsigned long long v) {
for (int i = 0;; ++i, v /= 2)
if (!v) return i;
}

int main(int argc, char **argv) {
unsigned long long a = (uintptr_t)malloc(1024);
printf("%s %d [%d]: malloc: %llu (%d/%d bits)\n",
cc, ccver, ccbits, a, msb(a), 8 * (int)sizeof(void*));
return 0;
}

I compiled this program using tcc (64) itself, as well as using
mingw gcc 5.5 (64), mingw gcc 12.2 (64), and msvc 2015 (64).
Source + binaries are available here https://0x0.st/ov4N.zip

On win7 these programs print results like this:
gcc 12 [64]: malloc: 1464336 (21/64 bits)
gcc 5 [64]: malloc: 8476688 (24/64 bits)
msvc 1900 [64]: malloc: 2635264 (22/64 bits)
tcc 927 [64]: malloc: 2185120 (22/64 bits)

While on win10 the same binaries print resuts like this:
gcc 12 [64]: malloc: 2620625130432 (42/64 bits)
gcc 5 [64]: malloc: 12260288 (24/64 bits)
msvc 1900 [64]: malloc: 1504834189600 (41/64 bits)
tcc 927 [64]: malloc: 8590208 (24/64 bits)

So somehow, on win7 the address from malloc is always ~22 bits,
while on win10 msvc and new mingw gcc procude ~43 bits address,
while with tcc and old gcc malloc returns ~22 bits addresses.

and indeed, when tcc64 is compiled using tcc64 then on win10
s->sh_addr is ~22 bits, and all tests do pass _before_ d76e0323.


--


On Thursday, October 13, 2022, 10:16:45 PM GMT+3, grischka 
 wrote:


>> from tests/tests2/:
>> - 104_inline.test
>
> This might be fixed on mob.

Confirmed, 104 now passes on win10 with gcc 12.2 (at d76e032).


> You can see the command when you call the test directly:
>
> make -C tests clean
> make -C tests test1

On win10 with gcc 12.2, the output ends with this:
./tcctest.gcc > test.ref
make: *** [Makefile:110: test.ref] Error -1073741819
make: Leaving directory 'D:/tmp/tcc2/tests'

and the last line at test.ref is " asm_test -"

Then, at tcctest.c, I commented out /* RUN(asm_test); */
and the test passes.

I tried to find which line crashes at asm_test, and it's:
strncat1(buf, " worldX", 3);

(adding exit(42) just before it exits with code 42, but exit(42)
after it is not reached).

I then tried also
make -C tests clean
make -C tests test3

and it's the same end of output as with test1, and same
diagnostics (pass if commenting out RUN(asm_test), else
crash at strncat1(buf, " worldX", 3)).


- avih

___
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] test failures on win32 x86-64

[Domingo Alvarez Duarte]

The github action is already working and the windows tests failed see 
then here https://github.com/TinyCC/tinycc/actions/runs/3249532722 .


On 14/10/22 11:24, avih via Tinycc-devel wrote:

In reply to the second half of:
https://lists.nongnu.org/archive/html/tinycc-devel/2022-10/msg00021.html

> As to spurious problems with MSYS2 I can only say that in my experience
> it is not a completely reliable build system.
>
> As a derivative from cygwin it shares the same fork() emulation hack,
> and I've seen it sub-processes just silently terminating (or maybe not
> even start them) with no failure code whatsoever.
>
> That would not affect the built tcc itself however it could affect the
> 'diff' used by the tests for example.

I think I removed the cygwin/fork/diff variables as follows:

I'm using this, which is a reproducible mingw env without cygwin:
https://github.com/skeeto/w64devkit/releases/tag/v1.16.1

building tcc (simply configure && make) within this environment
is producing identical tcc.exe, libtcc.dll, libtcc1.a on both my
Windows 10 system (32G ram) and my Windows 7 system (16G ram).

"make test" succeeds on win7 but fails on win10.

_Before_ commit d76e0323 (win64: hi-mem adjustments) test 104
failed also when invoked manually as:
cd tests/tests2 && path/to/inttalled/tcc 104+_inline.c -run 104_inline.c

where on win7 it printed things and exited successfully, while on
win10 it printed "tcc: error: internal error: relocation failed".

So it's also not an issue of diff not running correctly.

I took the liberty to print the value which fails ("diff") and its
origin (s->sh_addr at relocate_section), and noticed that on win10
it's 41-44 bits values, while on win7 it's 22-24 bits values.

I guessed that this might be an address from malloc, and checked
which values malloc returns using this program (source link below):

int msb(unsigned long long v) {
for (int i = 0;; ++i, v /= 2)
if (!v) return i;
}

int main(int argc, char **argv) {
unsigned long long a = (uintptr_t)malloc(1024);
printf("%s %d [%d]: malloc: %llu (%d/%d bits)\n",
cc, ccver, ccbits, a, msb(a), 8 * (int)sizeof(void*));
return 0;
}

I compiled this program using tcc (64) itself, as well as using
mingw gcc 5.5 (64), mingw gcc 12.2 (64), and msvc 2015 (64).
Source + binaries are available here https://0x0.st/ov4N.zip

On win7 these programs print results like this:
gcc 12 [64]: malloc: 1464336 (21/64 bits)
gcc 5 [64]: malloc: 8476688 (24/64 bits)
msvc 1900 [64]: malloc: 2635264 (22/64 bits)
tcc 927 [64]: malloc: 2185120 (22/64 bits)

While on win10 the same binaries print resuts like this:
gcc 12 [64]: malloc: 2620625130432 (42/64 bits)
gcc 5 [64]: malloc: 12260288 (24/64 bits)
msvc 1900 [64]: malloc: 1504834189600 (41/64 bits)
tcc 927 [64]: malloc: 8590208 (24/64 bits)

So somehow, on win7 the address from malloc is always ~22 bits,
while on win10 msvc and new mingw gcc procude ~43 bits address,
while with tcc and old gcc malloc returns ~22 bits addresses.

and indeed, when tcc64 is compiled using tcc64 then on win10
s->sh_addr is ~22 bits, and all tests do pass _before_ d76e0323.


--


On Thursday, October 13, 2022, 10:16:45 PM GMT+3, grischka 
 wrote:


>> from tests/tests2/:
>> - 104_inline.test
>
> This might be fixed on mob.

Confirmed, 104 now passes on win10 with gcc 12.2 (at d76e032).


> You can see the command when you call the test directly:
>
> make -C tests clean
> make -C tests test1

On win10 with gcc 12.2, the output ends with this:
./tcctest.gcc > test.ref
make: *** [Makefile:110: test.ref] Error -1073741819
make: Leaving directory 'D:/tmp/tcc2/tests'

and the last line at test.ref is " asm_test -"

Then, at tcctest.c, I commented out /* RUN(asm_test); */
and the test passes.

I tried to find which line crashes at asm_test, and it's:
strncat1(buf, " worldX", 3);

(adding exit(42) just before it exits with code 42, but exit(42)
after it is not reached).

I then tried also
make -C tests clean
make -C tests test3

and it's the same end of output as with test1, and same
diagnostics (pass if commenting out RUN(asm_test), else
crash at strncat1(buf, " worldX", 3)).


- avih

___
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] test failures on win32 x86-64

[Domingo Alvarez Duarte]

Thank you !

I just accepted it and I'm waiting for an answer here 
https://github.com/repo-sync/github-sync/issues/104 to add something 
like I did here 
https://github.com/mingodad/tinycc/actions/runs/1638429826/workflow .


On 14/10/22 11:12, Vlad Vissoultchev wrote:

Just sent you an invitation from  https://github.com/orgs/TinyCC org.

In mob development fashion every member of the org has owner rights and can 
invite other people to configure CI for instance or anything needed.

cheers,


-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+wqweto=gmail@nongnu.org] On 
Behalf Of Domingo Alvarez Duarte
Sent: Friday, October 14, 2022 10:54 AM
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] test failures on win32 x86-64

I noticed that there is a github mirror of tinycc repository, maybe it's a good 
idea to set a github action there that builds and test it on windows, mac and 
linux on every commit.

On 13/10/22 20:59, grischka wrote:

On 08.10.2022 22:39, avih via Tinycc-devel wrote:

Hi,

The following tests fail for me currently (0fd7376 gnu hash) when
building tcc for win32 x86-64 (but pass when building i386)

from tests/:
- test3
- test1b

Basically we would need to know first what part of the test fails at
all.  Is it tcc compiling itself, or the compiled tcc compiling
tcctest, or is it tcctest running, or even is it maybe gcc that
crashes?

You can see the command when you call the test directly:

make -C tests clean
make -C tests test1


from tests/tests2/:
- 104_inline.test

This might be fixed on mob.

--- grischka


I sampled several revisions since release_0_9_27, and all of them
fail somehow, mostly in tests (one revision also failed to build).

This could be related to the mingw gcc I'm testing with - gcc 11.3.0
using mingw64 in MSYS2. I _think_ the x86-64 win32 tests did pass in
thepast, so if someone could confirm the failures it may help.

I tested as follows on Windows 10:
- launch the mingw64 MSYS2 desktop shortcut
- cd path/to/tinycc
- git clean -xfd
- ./configure --cpu=x86_64 --config-mingw32 && make && make test


regards,
avih

___
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 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 mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] test failures on win32 x86-64

[Domingo Alvarez Duarte]

I noticed that there is a github mirror of tinycc repository, maybe it's 
a good idea to set a github action there that builds and test it on 
windows, mac and linux on every commit.


On 13/10/22 20:59, grischka wrote:

On 08.10.2022 22:39, avih via Tinycc-devel wrote:

Hi,

The following tests fail for me currently (0fd7376 gnu hash) when
building tcc for win32 x86-64 (but pass when building i386)

from tests/:
- test3
- test1b


Basically we would need to know first what part of the test fails
at all.  Is it tcc compiling itself, or the compiled tcc compiling
tcctest, or is it tcctest running, or even is it maybe gcc that
crashes?

You can see the command when you call the test directly:

   make -C tests clean
   make -C tests test1


from tests/tests2/:
- 104_inline.test


This might be fixed on mob.

--- grischka



I sampled several revisions since release_0_9_27, and all of them
fail somehow, mostly in tests (one revision also failed to build).

This could be related to the mingw gcc I'm testing with - gcc 11.3.0
using mingw64 in MSYS2. I _think_ the x86-64 win32 tests did pass
in thepast, so if someone could confirm the failures it may help.

I tested as follows on Windows 10:
- launch the mingw64 MSYS2 desktop shortcut
- cd path/to/tinycc
- git clean -xfd
- ./configure --cpu=x86_64 --config-mingw32 && make && make test


regards,
avih

___
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 mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Linking with cosmopolitan: Invalid relocation entry

[Domingo Alvarez Duarte]

Looking at it in more depth and comparing with the gcc command line I 
can see that it only work with gcc using a custom link script.


=

# run gcc compiler in freestanding mode
gcc -fno-pie -no-pie -nostdlib -nostdinc \
  -o hello-gcc.com.dbg hello-tcc.c  \
  -Wl,-T,ape.lds \
   crt.o ape-no-modify-self.o cosmopolitan.a

=

ape.lds

=

ENTRY(_start)
PHDRS {
  Head 1 FLAGS(1|4);
  Rom 1 FLAGS(1|4);
  Ram 1 FLAGS(2|4);
  Tls 7 FLAGS(2|4);
  Bss 1 FLAGS(2|4);
  stack 0x6474e551 FLAGS(2|4);
}
SECTIONS {
  .head SEGMENT_START("text-segment", 0x40) : AT(0x2000) {
    HIDDEN(_base = .);
    KEEP(*(.head))
    KEEP(*(.apesh))
    KEEP(*(.head2))
    KEEP(*(.text.head))
    . = ALIGN(8);
    HIDDEN(ape_phdrs = .);
    KEEP(*(.elf.phdrs))
    HIDDEN(ape_phdrs_end = .);
    . = ALIGN(8);
    HIDDEN(ape_note = .);
    KEEP(*(.note.openbsd.ident))
    KEEP(*(.note.netbsd.ident))
    HIDDEN(ape_note_end = .);
    KEEP(*(.pe.header))
    HIDDEN(ape_pe_sections = .);
    KEEP(*(.pe.sections))
    HIDDEN(ape_pe_sections_end = .);
    KEEP(*(.macho))
    . = ALIGN(8);
    HIDDEN(ape_macho_end = .);
    KEEP(*(.ape.pad.head))
    . = ALIGN(((255 & 4) == 4) || ((255 & 2) == 2) ? 0x1000 : 16);
    HIDDEN(_ehead = .);
  } :Head
  .text . : {
    BYTE(0x90)
    *(.text.real)
    KEEP(*(SORT_BY_NAME(.sort.text.real.*)))
    KEEP(*(.ape.loader))
    HIDDEN(_ereal = .);
    . += 1;
    *(.start)
    KEEP(*(.initprologue))
    KEEP(*(SORT_BY_NAME(.init.*)))
    KEEP(*(.init))
    KEEP(*(.initepilogue))
    KEEP(*(.pltprologue))
    *(.plt)
    KEEP(*(.pltepilogue))
    KEEP(*(.pltgotprologue))
    *(.plt.got)
    KEEP(*(.pltgotepilogue))
    *(.text.startup .text.startup.*)
    *(.text.exit .text.exit.*)
    *(.text.unlikely .text.*_unlikely .text.unlikely.*)
    *(SORT_BY_ALIGNMENT(.text.antiquity))
    *(SORT_BY_ALIGNMENT(.text.antiquity.*))
    KEEP(*(.textwindowsprologue))
    *(.text.windows)
    KEEP(*(.textwindowsepilogue))
    *(SORT_BY_ALIGNMENT(.text.modernity))
    *(SORT_BY_ALIGNMENT(.text.modernity.*))
    *(SORT_BY_ALIGNMENT(.text.hot))
    *(SORT_BY_ALIGNMENT(.text.hot.*))
    KEEP(*(.keep.text))
    *(.text .stub .text.*)
    KEEP(*(SORT_BY_NAME(.sort.text.*)))

...

ASSERT((!DEFINED(ape_grub) ? 1 : ((ape_grub) - (0x40)) < 8192),
   "grub stub needs to be in first 8kb of image");
ASSERT(DEFINED(_start) || DEFINED(_start16),
   "please link a _start() or _start16() entrypoint");
ASSERT(!DEFINED(_start16) || ((_end) - (0x40 - 0x2000)) < 65536,
   "ape won't support non-tiny real mode programs");
ASSERT((!((ape_stack_memsz) & ((ape_stack_memsz)-1))),
   "ape_stack_memsz must be a two power");
ASSERT(ape_stack_vaddr % ape_stack_memsz == 0,
   "ape_stack_vaddr must have ape_stack_memsz alignment; try using 
STATIC_STACK_ADDR(0x7004 - ape_stack_memsz);");

ASSERT(ALIGNOF(.tdata) <= 64 && ALIGNOF(.tbss) <= 64,
       "_Thread_local _Alignof can't exceed TLS_ALIGNMENT");

=

On 12/10/22 17:44, Domingo Alvarez Duarte wrote:

Hello !

I'm trying to use tcc to build a test program using cosmopolitan libc 
https://github.com/jart/cosmopolitan and I'm getting this error : 
"cosmopolitan.a: error: Invalid relocation entry [ 2] '.rela.text' @ 
000c".


Here is the C program:

=

typedef short __CHAR16_TYPE__;
typedef int __CHAR32_TYPE__;
typedef signed char __INT8_TYPE__;
typedef unsigned char __UINT8_TYPE__;
typedef short __INT16_TYPE__ ;
typedef unsigned short __UINT16_TYPE__;
typedef unsigned int __UINT32_TYPE__;
typedef unsigned long __UINT64_TYPE__;
typedef long long __INTMAX_TYPE__;
typedef unsigned long long __UINTMAX_TYPE__;

typedef signed char __INT_LEAST8_TYPE__;
typedef unsigned char __UINT_LEAST8_TYPE__;
typedef short __INT_LEAST16_TYPE__;
typedef unsigned short __UINT_LEAST16_TYPE__;
typedef int __INT_LEAST32_TYPE__;
typedef unsigned int __UINT_LEAST32_TYPE__;
typedef long __INT_LEAST64_TYPE__;
typedef unsigned long __UINT_LEAST64_TYPE__;

typedef signed char __INT_FAST8_TYPE__;
typedef unsigned char __UINT_FAST8_TYPE__;
typedef short __INT_FAST16_TYPE__;
typedef unsigned short __UINT_FAST16_TYPE__;
typedef int __INT_FAST32_TYPE__;
typedef unsigned int __UINT_FAST32_TYPE__;
typedef long __INT_FAST64_TYPE__;
typedef unsigned long __UINT_FAST64_TYPE__;

#define __STRICT_ANSI__

#include "cosmopolitan.h"
int main(int argc, char *argv) {
    printf("hello world\n");
    return 0;
}

=

And here is the command line:

=

# run gcc compiler in freestanding mode
tinycc-env tcc -nostdlib -nostdinc \
  -o hello-tcc.com.dbg hello-tcc.c  \
   crt.o ape-no-modify-self.o cosmopolitan.a
#objcopy -S -O binary hello-tcc.com.dbg hello-tcc.com

# NOTE: scp it to windows/mac/etc. *before* you run it!
# ~40kb static binary (can be ~16kb w/ MODE=tiny)
#./ape.elf ./hello-tcc.com

=

Here is the folder content:

=

total 5452

[Tinycc-devel] Linking with cosmopolitan: Invalid relocation entry

[Domingo Alvarez Duarte]

Hello !

I'm trying to use tcc to build a test program using cosmopolitan libc 
https://github.com/jart/cosmopolitan and I'm getting this error : 
"cosmopolitan.a: error: Invalid relocation entry [ 2] '.rela.text' @ 
000c".


Here is the C program:

=

typedef short __CHAR16_TYPE__;
typedef int __CHAR32_TYPE__;
typedef signed char __INT8_TYPE__;
typedef unsigned char __UINT8_TYPE__;
typedef short __INT16_TYPE__ ;
typedef unsigned short __UINT16_TYPE__;
typedef unsigned int __UINT32_TYPE__;
typedef unsigned long __UINT64_TYPE__;
typedef long long __INTMAX_TYPE__;
typedef unsigned long long __UINTMAX_TYPE__;

typedef signed char __INT_LEAST8_TYPE__;
typedef unsigned char __UINT_LEAST8_TYPE__;
typedef short __INT_LEAST16_TYPE__;
typedef unsigned short __UINT_LEAST16_TYPE__;
typedef int __INT_LEAST32_TYPE__;
typedef unsigned int __UINT_LEAST32_TYPE__;
typedef long __INT_LEAST64_TYPE__;
typedef unsigned long __UINT_LEAST64_TYPE__;

typedef signed char __INT_FAST8_TYPE__;
typedef unsigned char __UINT_FAST8_TYPE__;
typedef short __INT_FAST16_TYPE__;
typedef unsigned short __UINT_FAST16_TYPE__;
typedef int __INT_FAST32_TYPE__;
typedef unsigned int __UINT_FAST32_TYPE__;
typedef long __INT_FAST64_TYPE__;
typedef unsigned long __UINT_FAST64_TYPE__;

#define __STRICT_ANSI__

#include "cosmopolitan.h"
int main(int argc, char *argv) {
    printf("hello world\n");
    return 0;
}

=

And here is the command line:

=

# run gcc compiler in freestanding mode
tinycc-env tcc -nostdlib -nostdinc \
  -o hello-tcc.com.dbg hello-tcc.c  \
   crt.o ape-no-modify-self.o cosmopolitan.a
#objcopy -S -O binary hello-tcc.com.dbg hello-tcc.com

# NOTE: scp it to windows/mac/etc. *before* you run it!
# ~40kb static binary (can be ~16kb w/ MODE=tiny)
#./ape.elf ./hello-tcc.com

=

Here is the folder content:

=

total 54520
-rwxr-xr-x 1 mingo mingo    22192 oct 11 06:07 ape-copy-self.o
-rwxr-xr-x 1 mingo mingo   146720 oct 11 06:07 ape.lds
-rwxr-xr-x 1 mingo mingo    31000 oct 11 06:07 ape-no-modify-self.o
-rwxr-xr-x 1 mingo mingo    22192 oct 11 06:07 ape.o
-rwxr-xr-x 1 mingo mingo 54084380 oct 11 06:07 cosmopolitan.a
-rwxr-xr-x 1 mingo mingo  1472975 oct 11 06:08 cosmopolitan.h
-rwxr-xr-x 1 mingo mingo 3608 oct 11 06:07 crt.o
-rw-rw-r-- 1 mingo mingo    12620 oct 12 17:16 gcc-macros.h
-rwxrwxr-x 1 mingo mingo 3648 oct 12 17:23 hello-tcc
-rw-rw-r-- 1 mingo mingo 1135 oct 12 17:22 hello-tcc.c
-rwxrw-r-- 1 mingo mingo  348 oct 12 17:33 mk-hello-tcc.sh
-rw-rw-r-- 1 mingo mingo   66 oct 12 17:16 mk-it-tcc.sh

=

Can someone with more experience shed some light here ?

Cheers !


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

[Domingo Alvarez Duarte]

Hello Ziyao !

Although gcc compiles a file containing your example with warnings, I'm 
not sure it's worth try to do the same in TiinyCC the preprocessor 
probably uses TOKENS from the lexer to decide to skip till the end of 
the initial "#if 0" and '"' is not a valid token the error probably come 
from the lexer that found a non terminated string.


Cheers !

On 11/7/22 15:57, Ziyao wrote:

Hi list,

When I was compiling Bash with TinyCC,an error occurred.

The simpliest example is like below:

#if 0
"
#if 0
"
#endif
#endif

Code within #if 0 ... end block should be ignored.But this code breaks
TinyCC.TinyCC seems to analyse the string inside the useless code block.

As many use #if 0 blocks as comments,maybe this is valuable to fix.

Tons of thanks for your help

Ziyao


___
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] [patch] adding path resolution to #line directives

[Domingo Alvarez Duarte]

Why don't you do the collapse at generation time ?

On 5/5/22 10:50, Raul Hernandez wrote:

Hi, list.


Over at vlang/v, we use #line directives to map line numbers in the 
generated C to the respective locations in the original code in 
backtraces, etc.

The code we generate looks something like this:

    #line 29 
"../../../../../../home/spaceface/git/v/v/vlib/builtin/builtin.c.v"

    void panic_debug(void) {
        #line 53 
"../../../../../../home/spaceface/git/v/v/vlib/builtin/builtin.c.v"

tcc_backtrace("Backtrace");
    }

    #line 1 "../../../../../../home/spaceface/git/v/v/test.v"
    void main__inner(void) {
        #line 1 "../../../../../../home/spaceface/git/v/v/test.v"
panic_debug();
    }

    #line 2 "../../../../../../home/spaceface/git/v/v/test.v"
    void main__outer(void) {
        #line 2 "../../../../../../home/spaceface/git/v/v/test.v"
main__inner();
    }

    #line 3 "../../../../../../home/spaceface/git/v/v/test.v"
    int main(void) {
        #line 3 "../../../../../../home/spaceface/git/v/v/test.v"
main__outer();
return 0;
    }


Other C compilers collapse the `../`s in the #line paths, but TCC does 
not, so currently the backtraces it produces look like this:


/tmp/v_1000/../../../../../../home/spaceface/git/v/v/vlib/builtin/builtin.c.v:53: 
at panic_debug: Backtrace
/tmp/v_1000/../../../../../../home/spaceface/git/v/v/test.v:1: by 
main__inner
/tmp/v_1000/../../../../../../home/spaceface/git/v/v/test.v:2: by 
main__outer

/tmp/v_1000/../../../../../../home/spaceface/git/v/v/test.v:3: by main


I decided to try and fix this, and came up with the following patch:

    diff --git a/tccpp.c b/tccpp.c
    index 2ff5d5e..47ac859 100644
    --- a/tccpp.c
    +++ b/tccpp.c
    @@ -1797,7 +1797,7 @@ ST_FUNC void preprocess(int is_bof)
    {
TCCState *s1 = tcc_state;
        int i, c, n, saved_parse_flags;
    -    char buf[1024], *q;
    +    char buf[1024], *q, *last_slash;
        Sym *s;
saved_parse_flags = parse_flags;
    @@ -2042,6 +2042,22 @@ include_done:
      pstrcpy(buf, sizeof buf, file->true_filename);
      *tcc_basename(buf) = 0;
      pstrcat(buf, sizeof buf, (char *)tokc.str.data);
    +        // collapse relative `../`s
    +        while ((q = strstr(buf, "../")) != NULL) {
    +            (q == buf) ? (*q = '\0') : (*(q-1) = '\0');
    +            last_slash = strrchr(buf, '/');
    +            if (last_slash == NULL) {
    +                memmove(buf, q + 2, strlen(q + 2) + 1);
    +            } else {
    +                memmove(last_slash + 1, q + 2, strlen(q + 2) + 1);
    +            }
    +        }
    +        // collapse `foo//bar` to `foo/bar`
    +        c = strlen(buf);
    +        while((q = strstr(buf, "//")) != NULL) {
    +            memmove(q, q+1, c - (q - buf));
    +            c--;
    +        }
      tcc_debug_putfile(s1, buf);
  } else if (parse_flags & PARSE_FLAG_ASM_FILE)
      break;


With it, that same backtrace now looks like this:

/home/spaceface/git/v/v/vlib/builtin/builtin.c.v:53: at panic_debug: 
Backtrace

/home/spaceface/git/v/v/test.v:1: by main__inner
/home/spaceface/git/v/v/test.v:2: by main__outer
/home/spaceface/git/v/v/test.v:3: by main


Would you be willing to merge something this?

We’ve also added a function that returns the backtrace as a char** 
rather than printing it out, and modified the backtrace functions to 
replace e.g. main__foo with main.foo in symbol names, but I presume 
these patches won’t be as useful outside of V.


Raul


___
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] Linking with libtcc1.a

[Domingo Alvarez Duarte]

Hello Ziyao !

I once did this "Added what I call virtual io to tinycc this way we can 
make a monolitic executable or library that contains all needed to 
compile programs, truly tinycc portable." here 
https://github.com/mingodad/tinycc/commit/59e18aee0e509a3ca75dbe6f909e18c1d17893d1 
maybe it would be interesting to you.


Cheers !

On 14/4/22 2:49, Ziyao wrote:

Hi list,

I am working to port musl to TinyCC.Because musl is an
implementation of libc,-nostdlib option is used to stop TinyCC from
linking the standard libc to the executable files.

But -nostdlib option also prevents TinyCC from linking libtcc1.a,which
contains serveral runtime functions (e.g. __va_arg).As for GCC,its
manual points out that using -lgcc option may be needed to work with
-nostdlib option.But it seems that there is no way to make TinyCC add
libtcc1.a to the executable file.Simply adding "-ltcc1" does not work
because libtcc1.a is not in the usual library searching path.

Will there be a solution for this?

Ziyao


___
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] Compilation error while including LAPACKE

[Domingo Alvarez Duarte]

After your last message I've tried defining "_Complex" to empty and for 
the simple test it compiled, probably if you are not using complex this 
trick could work:


=

#include 
#define _Complex  //make it e noop
#include 

int main() {
  printf("Hello World!\n");
  return 0;
}



Output:



../tcc  cmath.c
>Exit code: 0
./a.out
>./a.out
Hello World!
>Exit code: 0



On 9/4/22 18:14, Christopher Choi wrote:

Sorry I guess I'm not familiar with TCC, but I suppose this is
something TCC hasn't implemented yet? having dug into the archives a
little more the only other mention of complex type support with TCC
was in 2015.

https://www.mail-archive.com/tinycc-devel@nongnu.org/msg06428.html

If complex types are not supported are there known work-arounds other
than "dont use them"?

Thanks
Chris

On Sat, 9 Apr 2022 at 09:03, Domingo Alvarez Duarte  wrote:

The problem seem to be related with "Complex" rather than "lapacke":



#include 
#include 

int main() {
printf("Hello World!\n");
return 0;
}



Output:



tcc -c cmath.c
In file included from cmath.c:2:
In file included from /usr/include/complex.h:106:
/usr/include/x86_64-linux-gnu/bits/cmathcalls.h:55: error: ';' expected
(got "cacos")



Output of preprocessing:



/tcc -E cmath.c

...

# 106 "/usr/include/complex.h"
# 1 "/usr/include/x86_64-linux-gnu/bits/cmathcalls.h" 1
# 55 "/usr/include/x86_64-linux-gnu/bits/cmathcalls.h"
extern double _Complex cacos (double _Complex __z) ; extern double
_Complex __cacos (double _Complex __z) ;

...



On 9/4/22 2:03, Christopher Choi wrote:

#include 
#include 

int main() {
printf("Hello World!\n");
return 0;
}

___
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 mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Compilation error while including LAPACKE

[Domingo Alvarez Duarte]

The problem seem to be related with "Complex" rather than "lapacke":



#include 
#include 

int main() {
  printf("Hello World!\n");
  return 0;
}



Output:



tcc -c cmath.c
In file included from cmath.c:2:
In file included from /usr/include/complex.h:106:
/usr/include/x86_64-linux-gnu/bits/cmathcalls.h:55: error: ';' expected 
(got "cacos")




Output of preprocessing:



/tcc -E cmath.c

...

# 106 "/usr/include/complex.h"
# 1 "/usr/include/x86_64-linux-gnu/bits/cmathcalls.h" 1
# 55 "/usr/include/x86_64-linux-gnu/bits/cmathcalls.h"
extern double _Complex cacos (double _Complex __z) ; extern double 
_Complex __cacos (double _Complex __z) ;


...



On 9/4/22 2:03, Christopher Choi wrote:

#include 
#include 

int main() {
   printf("Hello World!\n");
   return 0;
}


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Question about Atomics support in TCC

[Domingo Alvarez Duarte]

Here is the code that runs on linux and also seems to not behave correctly:



#include 
//#include 
#include 
#include 

atomic_int acnt;
int cnt;

//int f(void* thr_data) {
void *f(void* thr_data) {
    for (int n = 0; n < 1000; ++n) {
    ++cnt;
    ++acnt;
    }
    return 0;
}

int main(void) {
    //thrd_t thr[10];
    pthread_t thr[10];
    for(int n = 0; n < 10; ++n)
    //thrd_create([n], f, NULL);
    pthread_create([n], NULL, f, NULL);
    for(int n = 0; n < 10; ++n)
    //thrd_join(thr[n], NULL);
    pthread_join(thr[n], NULL);

    printf("The atomic counter is %u\n", acnt);
    printf("The non-atomic counter is %u\n", cnt);
    return 0;
}



Looking at the output of objdump for the generated binary from tcc and 
gcc I can see that tcc doesn't generate any "lock".


Output from tcc for function "f":



004006a3 :
  4006a3:    55       push   %rbp
  4006a4:    48 89 e5     mov    %rsp,%rbp
  4006a7:    48 81 ec 10 00 00 00     sub    $0x10,%rsp
  4006ae:    48 89 7d f8      mov    %rdi,-0x8(%rbp)
  4006b2:    b8 00 00 00 00       mov    $0x0,%eax
  4006b7:    89 45 f4     mov    %eax,-0xc(%rbp)
  4006ba:    8b 45 f4     mov    -0xc(%rbp),%eax
  4006bd:    81 f8 e8 03 00 00        cmp    $0x3e8,%eax
  4006c3:    0f 8d 3e 00 00 00        jge    400707 
  4006c9:    e9 0b 00 00 00       jmpq   4006d9 
  4006ce:    8b 45 f4     mov    -0xc(%rbp),%eax
  4006d1:    83 c0 01     add    $0x1,%eax
  4006d4:    89 45 f4     mov    %eax,-0xc(%rbp)
  4006d7:    eb e1        jmp    4006ba 
  4006d9:    48 8b 05 d8 0a 20 00     mov 0x200ad8(%rip),%rax    # 
6011b8 

  4006e0:    8b 00        mov    (%rax),%eax
  4006e2:    83 c0 01     add    $0x1,%eax
  4006e5:    4c 8b 1d cc 0a 20 00     mov 0x200acc(%rip),%r11    # 
6011b8 

  4006ec:    41 89 03     mov    %eax,(%r11)
  4006ef:    48 8b 05 ca 0a 20 00     mov 0x200aca(%rip),%rax    # 
6011c0 

  4006f6:    8b 00        mov    (%rax),%eax
  4006f8:    83 c0 01     add    $0x1,%eax
  4006fb:    4c 8b 1d be 0a 20 00     mov 0x200abe(%rip),%r11    # 
6011c0 

  400702:    41 89 03     mov    %eax,(%r11)
  400705:    eb c7        jmp    4006ce 
  400707:    48 b8 00 00 00 00 00     movabs $0x0,%rax
  40070e:    00 00 00
  400711:    c9       leaveq
  400712:    c3       retq



Output from gcc for function "f":



0755 :
 755:    55       push   %rbp
 756:    48 89 e5     mov    %rsp,%rbp
 759:    48 83 ec 30      sub    $0x30,%rsp
 75d:    48 89 7d d8      mov    %rdi,-0x28(%rbp)
 761:    64 48 8b 04 25 28 00     mov    %fs:0x28,%rax
 768:    00 00
 76a:    48 89 45 f8      mov    %rax,-0x8(%rbp)
 76e:    31 c0        xor    %eax,%eax
 770:    c7 45 f4 00 00 00 00     movl   $0x0,-0xc(%rbp)
 777:    eb 2e        jmp    7a7 
 779:    8b 05 99 08 20 00        mov 0x200899(%rip),%eax    # 
201018 

 77f:    83 c0 01     add    $0x1,%eax
 782:    89 05 90 08 20 00        mov %eax,0x200890(%rip)    # 
201018 

 788:    c7 45 ec 01 00 00 00     movl   $0x1,-0x14(%rbp)
 78f:    8b 45 ec     mov    -0x14(%rbp),%eax
 792:    89 c2        mov    %eax,%edx
 794:    89 d0        mov    %edx,%eax
 796:    f0 0f c1 05 76 08 20     lock xadd %eax,0x200876(%rip)    
# 201014 

 79d:    00
 79e:    01 d0        add    %edx,%eax
 7a0:    89 45 f0     mov    %eax,-0x10(%rbp)
 7a3:    83 45 f4 01      addl   $0x1,-0xc(%rbp)
 7a7:    81 7d f4 e7 03 00 00     cmpl   $0x3e7,-0xc(%rbp)
 7ae:    7e c9        jle    779 
 7b0:    b8 00 00 00 00       mov    $0x0,%eax
 7b5:    48 8b 4d f8      mov    -0x8(%rbp),%rcx
 7b9:    64 48 33 0c 25 28 00     xor    %fs:0x28,%rcx
 7c0:    00 00
 7c2:    74 05        je 7c9 
 7c4:    e8 67 fe ff ff       callq  630 <__stack_chk_fail@plt>
 7c9:    c9       leaveq
 7ca:    c3       retq



Cheers !

On 6/4/22 22:00, Davidson Francis wrote:

Hi,
I was checking the Atomics support in the TCC (mob) and realized that
while atomic functions work fine, they don't get generated if I use
'implicitly' like in:

atomic_int foo;
foo += 5;

no errors are generated either. Is this some sort of bug, or is the
Atomics support in TCC not complete yet?

A complete example (which works in GCC and Clang) taken from [1]:

#include 
#include 
#include 

atomic_int acnt;
int cnt;
 
int f(void* thr_data) {

for (int n = 0; n < 1000; ++n) {
++cnt;
++acnt;
}
return 0;
}
 
int main(void) {

thrd_t thr[10];

Re: [Tinycc-devel] Re : Re: Re : Some questions regarding of TCC's optimizations.

[Domingo Alvarez Duarte]

Hello Brian !

I just applied you changes to my fork of tcc made fully reentrant here 
https://github.com/mingodad/tinycc and tested with the script shown 
bellow building sqlite3 with tcc and gcc -O0.


The resulting sqlite3 was tested creating a database from 150MB of sql 
and the resulting databases were the same (sqlite3-tcc/sqlite3-gcc) then 
the final test shown here was done with a memory database instead of disk.


Result:



bin                    old new   diff %reduction 
(old/new)

---                 ---               ---   --
sqlite3-tcc        1449540    1412676    36864    2.60
sqlite3-gcc   1408080    1408080    0    0



Script to run the test:



sqlh=$HOME/dev/dadbiz++/third-party/dad/sqlite3-orig
showCPUSpeed() {
    cat /proc/cpuinfo | grep '^[c]pu MHz'
}

doIt() {
showCPUSpeed
echo compiling sqlite3 with tcc
/usr/bin/time ./tcc -o sqlite3-tcc $sqlh/sqlite3.c $sqlh/shell.c -lm 
-lpthread -ldl

ls -l sqlite3-tcc
#dbsql=$HOME/dev/AMPL/dad/sql/y-mod-sql/y103-hard-dat.db.sql
#dbsql=$HOME/dev/SquiLu/db-api/ourbiz.db.sql
dbsql=$HOME/dev/SquiLu/db-api/companies_uk_RG.db.sql
dbtcc=sdb-tcc.db
#rm $dbtcc
showCPUSpeed
#/usr/bin/time ./sqlite3-tcc $dbtcc  < $dbsql
echo running sqlite3-tcc
/usr/bin/time ./sqlite3-tcc  < $dbsql

showCPUSpeed
echo compiling sqlite3 with gcc
/usr/bin/time gcc -O0 -o sqlite3-gcc $sqlh/sqlite3.c $sqlh/shell.c -lm 
-lpthread -ldl

ls -l sqlite3-gcc
db0=sdb-gcc.db
showCPUSpeed
#rm $db0
#/usr/bin/time ./sqlite3-gcc $db0  < $dbsql
echo running sqlite3-gcc
/usr/bin/time ./sqlite3-gcc  < $dbsql
showCPUSpeed
}
doIt
doIt



Output before changes:



cpu MHz        : 1043.890
cpu MHz        : 955.076
cpu MHz        : 1368.369
cpu MHz        : 1202.189
cpu MHz        : 997.435
cpu MHz        : 1118.064
cpu MHz        : 1330.976
cpu MHz        : 972.875
compiling sqlite3 with tcc
0.10user 0.01system 0:00.11elapsed 100%CPU (0avgtext+0avgdata 
15840maxresident)k

0inputs+2832outputs (0major+3916minor)pagefaults 0swaps
-rwxrwxr-x 1 mingo mingo 1449540 abr  6 20:08 sqlite3-tcc
cpu MHz        : 2776.711
cpu MHz        : 2657.025
cpu MHz        : 3145.106
cpu MHz        : 3028.188
cpu MHz        : 3135.120
cpu MHz        : 2681.011
cpu MHz        : 2891.677
cpu MHz        : 2840.370
running sqlite3-tcc
12.10user 0.12system 0:12.23elapsed 99%CPU (0avgtext+0avgdata 
180488maxresident)k

0inputs+2976outputs (0major+44895minor)pagefaults 0swaps
cpu MHz        : 2712.282
cpu MHz        : 2700.523
cpu MHz        : 2700.011
cpu MHz        : 2706.670
cpu MHz        : 2699.597
cpu MHz        : 2699.745
cpu MHz        : 2699.178
cpu MHz        : 2699.843
compiling sqlite3 with gcc
4.00user 0.15system 0:04.16elapsed 100%CPU (0avgtext+0avgdata 
234052maxresident)k

0inputs+2752outputs (0major+87170minor)pagefaults 0swaps
-rwxrwxr-x 1 mingo mingo 1408080 abr  6 20:09 sqlite3-gcc
cpu MHz        : 2978.379
cpu MHz        : 2820.748
cpu MHz        : 2880.415
cpu MHz        : 2804.540
cpu MHz        : 2853.414
cpu MHz        : 2834.585
cpu MHz        : 2811.112
cpu MHz        : 2841.551
running sqlite3-gcc
10.86user 0.06system 0:10.93elapsed 100%CPU (0avgtext+0avgdata 
179924maxresident)k

0inputs+2976outputs (0major+44880minor)pagefaults 0swaps
cpu MHz        : 2700.364
cpu MHz        : 2700.918
cpu MHz        : 2699.985
cpu MHz        : 2700.143
cpu MHz        : 2699.869
cpu MHz        : 2700.273
cpu MHz        : 2700.024
cpu MHz        : 2699.606
cpu MHz        : 2700.364
cpu MHz        : 2700.918
cpu MHz        : 2699.985
cpu MHz        : 2700.143
cpu MHz        : 2699.869
cpu MHz        : 2700.273
cpu MHz        : 2700.024
cpu MHz        : 2699.606
compiling sqlite3 with tcc
0.10user 0.00system 0:00.11elapsed 100%CPU (0avgtext+0avgdata 
15952maxresident)k

0inputs+2832outputs (0major+3917minor)pagefaults 0swaps
-rwxrwxr-x 1 mingo mingo 1449540 abr  6 20:09 sqlite3-tcc
cpu MHz        : 3143.321
cpu MHz        : 2982.310
cpu MHz        : 3187.922
cpu MHz        : 2955.090
cpu MHz        : 2770.887
cpu MHz        : 2942.430
cpu MHz        : 3012.071
cpu MHz        : 3283.026
running sqlite3-tcc
12.04user 0.13system 0:12.18elapsed 99%CPU (0avgtext+0avgdata 
180600maxresident)k

0inputs+2976outputs (0major+44895minor)pagefaults 0swaps
cpu MHz        : 2700.171
cpu MHz        : 2700.743
cpu MHz        : 2700.004
cpu MHz        : 2700.256
cpu MHz        : 2700.178
cpu MHz        : 2700.150
cpu MHz        : 2699.892
cpu MHz        : 2697.367
compiling sqlite3 with gcc
4.02user 0.13system 0:04.16elapsed 99%CPU (0avgtext+0avgdata 
234080maxresident)k

0inputs+2752outputs (0major+87125minor)pagefaults 0swaps
-rwxrwxr-x 1 mingo mingo 1408080 abr  6 20:09 sqlite3-gcc
cpu MHz        : 2799.667
cpu MHz        : 2915.447
cpu MHz        : 2942.032
cpu MHz        : 2726.340
cpu MHz        : 2654.825
cpu MHz        : 2850.573
cpu MHz        : 2919.901
cpu MHz        : 2873.281
running sqlite3-gcc
10.74user 0.10system 0:10.85elapsed 99%CPU 

Re: [Tinycc-devel] Re : Re: Re : Some questions regarding of TCC's optimizations.

[Domingo Alvarez Duarte]

Hello Elijah !

I searched the mailing list and found this one 
https://lists.nongnu.org/archive/html/tinycc-devel/2013-10/msg00013.html 
that seems to be the one you describe.


Cheers !

On 4/4/22 20:04, Elijah Stone wrote:
A while ago, somebody worked on improving the quality of tcc's code 
generation.  Apparently the resulting code performed similarly to gcc 
-O0. This was specific to the (32-bit) x86 backend, but feasible to 
port to others.  I don't have a pointer handy, but you should be able 
to find it by searching the mailing list archives.


On Mon, 4 Apr 2022, Domingo Alvarez Duarte wrote:


Hello Brian !

I understand what you are saying and based on that TCC basically 
doesn't do basically any optmization and based on the basic idea of 
search/look through the generated assembly (trough objdump) trying 
recognize easy hanging fruits and if finding any and localizing the 
generating point add a similar code to the one you described to alter 
the generated code instead of modify/replace/remove the already 
generated one.


Thank you so much for your nice and useful blog post !

Cheers !

On 4/4/22 18:15, Brian Callahan wrote:

Hello --

I am on this list, you know :)

There may well be opportunities in tcc for a peephole optimizer
approach, but I'll caution that each compiler is different and that 
blog

post was examining QBE, so it wouldn't necessarily be a direct 1:1
mapping. QBE does a lot of optimization itself before writing out its
final assembly.

~Brian

On 4/4/2022 10:26 AM, Domingo Alvarez Duarte wrote:

After reading this https://briancallahan.net/blog/20220330.html and
using a citation on this list about dumping the ASM generated by TCC
using objdump maybe we can find patterns on the generated code and
identify where it's produced and update then.

On 31/3/22 20:16, rempas via Tinycc-devel wrote:

31 Μαρ 2022, 19:35 Από david.k...@libertysurf.fr:


Have a look : https://github.com/adorad/tcc and
https://github.com/adorad/adorad

- Mail d'origine -
De: rempas via Tinycc-devel 
À: Tinycc Devel 
Cc: rem...@tutanota.com, Tinycc Devel 
Envoyé: Tue, 29 Mar 2022 21:12:37 +0200 (CEST)
Objet: Re: [Tinycc-devel]  Re :  Some questions regarding of TCC's
optimizations.


Thanks a lot! I will look at it!


___
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 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 mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Re : Re: Re : Some questions regarding of TCC's optimizations.

[Domingo Alvarez Duarte]

Hello Brian !

I understand what you are saying and based on that TCC basically doesn't 
do basically any optmization and based on the basic idea of search/look 
through the generated assembly (trough objdump) trying recognize easy 
hanging fruits and if finding any and localizing the generating point 
add a similar code to the one you described to alter the generated code 
instead of modify/replace/remove the already generated one.


Thank you so much for your nice and useful blog post !

Cheers !

On 4/4/22 18:15, Brian Callahan wrote:

Hello --

I am on this list, you know :)

There may well be opportunities in tcc for a peephole optimizer
approach, but I'll caution that each compiler is different and that blog
post was examining QBE, so it wouldn't necessarily be a direct 1:1
mapping. QBE does a lot of optimization itself before writing out its
final assembly.

~Brian

On 4/4/2022 10:26 AM, Domingo Alvarez Duarte wrote:

After reading this https://briancallahan.net/blog/20220330.html and
using a citation on this list about dumping the ASM generated by TCC
using objdump maybe we can find patterns on the generated code and
identify where it's produced and update then.

On 31/3/22 20:16, rempas via Tinycc-devel wrote:

31 Μαρ 2022, 19:35 Από david.k...@libertysurf.fr:


Have a look : https://github.com/adorad/tcc and
https://github.com/adorad/adorad

- Mail d'origine -
De: rempas via Tinycc-devel 
À: Tinycc Devel 
Cc: rem...@tutanota.com, Tinycc Devel 
Envoyé: Tue, 29 Mar 2022 21:12:37 +0200 (CEST)
Objet: Re: [Tinycc-devel]  Re :  Some questions regarding of TCC's
optimizations.


Thanks a lot! I will look at it!


___
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 mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Re : Re: Re : Some questions regarding of TCC's optimizations.

[Domingo Alvarez Duarte]

After reading this https://briancallahan.net/blog/20220330.html and 
using a citation on this list about dumping the ASM generated by TCC 
using objdump maybe we can find patterns on the generated code and 
identify where it's produced and update then.


On 31/3/22 20:16, rempas via Tinycc-devel wrote:

31 Μαρ 2022, 19:35 Από david.k...@libertysurf.fr:


Have a look : https://github.com/adorad/tcc and https://github.com/adorad/adorad

- Mail d'origine -
De: rempas via Tinycc-devel 
À: Tinycc Devel 
Cc: rem...@tutanota.com, Tinycc Devel 
Envoyé: Tue, 29 Mar 2022 21:12:37 +0200 (CEST)
Objet: Re: [Tinycc-devel]  Re :  Some questions regarding of TCC's 
optimizations.


Thanks a lot! I will look at it!


___
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] A Patch for -dumpmachine Option

[Domingo Alvarez Duarte]

Looking at the patch I think that somehow it can be a good idea to 
create a new header/source to hold all (or as much as possible) of the 
platforms machinery in one place instead of spread through everywhere, 
like the functionality of "-dumpmachine" would be on that header/source.


On 24/3/22 11:35, Ziyao wrote:

Hi list,

I have made a small patch which adds option "-dumpmachine" support to
TinyCC.This option is widely supported by both gcc and clang.Some configure
scripts detect the platform information by passing this option to the
C compiler,such as musl libc.

And by the way,what is the proper way to contribute? Just send patches to
this maillist or what?Should I send a normal patch or formatted patch?
Thanks for answering.

(To avoid messing the plaintext mail readers up,I add my patch to the bottom
of this mail.)

Cheers,
Ziyao

--

diff --git a/libtcc.c b/libtcc.c
index b6dbb01..6e5cf17 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1456,6 +1456,7 @@ enum {
  TCC_OPTION_g,
  TCC_OPTION_c,
  TCC_OPTION_dumpversion,
+TCC_OPTION_DUMPMACHINE,
  TCC_OPTION_d,
  TCC_OPTION_static,
  TCC_OPTION_std,
@@ -1488,7 +1489,7 @@ enum {
  TCC_OPTION_MMD,
  TCC_OPTION_x,
  TCC_OPTION_ar,
-TCC_OPTION_impdef,
+TCC_OPTION_impdef
  };
  
  #define TCC_OPTION_HAS_ARG 0x0001

@@ -1518,6 +1519,7 @@ static const TCCOption tcc_options[] = {
  { "g", TCC_OPTION_g, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
  { "c", TCC_OPTION_c, 0 },
  { "dumpversion", TCC_OPTION_dumpversion, 0},
+{ "dumpmachine", TCC_OPTION_DUMPMACHINE , 0 },
  { "d", TCC_OPTION_d, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
  { "static", TCC_OPTION_static, 0 },
  { "std", TCC_OPTION_std, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
@@ -1952,6 +1954,8 @@ reparse:
  printf ("%s\n", TCC_VERSION);
  exit(0);
  break;
+case TCC_OPTION_DUMPMACHINE:
+return OPT_DUMPMACHINE;
  case TCC_OPTION_x:
  x = 0;
  if (*optarg == 'c')
diff --git a/tcc.c b/tcc.c
index 42a251b..ed9c143 100644
--- a/tcc.c
+++ b/tcc.c
@@ -95,6 +95,7 @@ static const char help2[] =
  "  -isystem dir  add 'dir' to system include path\n"
  "  -static   link to static libraries (not 
recommended)\n"
  "  -dumpversion  print version\n"
+"  -dumpmachine  print platform information\n"
  "  -print-search-dirsprint search paths\n"
  "  -dt   with -run/-E: auto-define 'test_...' 
macros\n"
  "Ignored options:\n"
@@ -289,6 +290,47 @@ redo:
  return 0;
  ++opt;
  }
+
+if (opt == OPT_DUMPMACHINE) {
+fputs(
+#ifdef TCC_TARGET_I386
+"i386"
+#elif defined TCC_TARGET_X86_64
+"x86_64"
+#elif defined TCC_TARGET_C67
+"c67"
+#elif defined TCC_TARGET_ARM
+"arm"
+# ifdef TCC_ARM_EABI
+" eabi"
+#  ifdef TCC_ARM_HARDFLOAT
+"hf"
+#  endif
+# endif
+#elif defined TCC_TARGET_ARM64
+"aarch64"
+#elif defined TCC_TARGET_RISCV64
+"riscv64"
+#endif
+   "-"
+#ifdef TCC_TARGET_PE
+"windows"
+#elif defined(TCC_TARGET_MACHO)
+"darwin"
+#elif TARGETOS_FreeBSD || TARGETOS_FreeBSD_kernel
+"freebsd"
+#elif TARGETOS_OpenBSD
+"openbsd"
+#elif TARGETOS_NetBSD
+"netbsd"
+#else
+"linux"
+#endif
+"-tcc\n",stdout);
+return 0;
+
+}
+
  if (opt == OPT_HELP2) {
  fputs(help2, stdout);
  return 0;
diff --git a/tcc.h b/tcc.h
index 9724848..3812241 100644
--- a/tcc.h
+++ b/tcc.h
@@ -1279,6 +1279,7 @@ ST_FUNC char *tcc_load_text(int fd);
  #define OPT_PRINT_DIRS 4
  #define OPT_AR 5
  #define OPT_IMPDEF 6
+#define OPT_DUMPMACHINE 7
  #define OPT_M32 32
  #define OPT_M64 64


___
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] NULL pointer dereference due to unchecked return from fdopen()

[Domingo Alvarez Duarte]

+1 To "just write a tcc_fdopen()"

On 28/2/22 13:46, Steffen Nurpmeso wrote:

Vincent Lefevre wrote in
  <20220228103710.ga33...@zira.vinc17.org>:
  |On 2022-02-28 10:50:29 +0100, grischka wrote:
  |> Christian Jullien wrote:
  |>> Thanks,
  |>> This is unfortunately not the only case where returned value is \
  |>> not tested, just for fdopen, if maintainers agree, we can probably \
  |>> apply:
  |>> Wdyt?
  |>
  |> The rule is, as always:  don't write code that you cannot test.
  |
  |Various other error cases are probably not tested.
  |Has anyone checked code coverage?
  |
  |Testing the code can be done once by adding "fp = NULL;" and checking
  |that the error is correctly handled. Otherwise, perhaps with LD_PRELOAD
  |to define a fdopen wrapper that will simulate an error for some calls.
  |
  |> Can you?
  |>
  |> Otherwise, can we stop suggesting sloppily crafted quick patches
  |> addressing non-existent problems?
  |
  |fdopen() may fail. So this is a real problem. However, the check for
  |errors should be done on the other related function calls too.
  |
  |Not checking errors may yield obscure errors in user code and/or
  |data loss/corruption (this happened to me with GCC, which did not
  |check some write errors, so that data were randomly silently missing
  |on NFS and my scripts were failing with errors difficult to debug).

Let's just write a tcc_fdopen() the same way myriads of projects
create their local xmalloc()?

   #?0|kent:tcc.git$ git grep fdopen mob
   mob:lib/tcov.c:return fdopen (fd, "r+");
   mob:tcccoff.c:f = fdopen(fd, "rb");
   mob:tccelf.c:f = fdopen(fd, "wb");
   mob:tcclib.h:FILE *fdopen(int fildes, const char *mode);
   mob:tccmacho.c:fp = fdopen(fd, "wb");
   mob:tcctools.c:depout = fdopen(1, "w");
   mob:win32/include/stdio.h:  FILE *__cdecl fdopen(int _FileHandle,const char 
*_Mode);
   mob:win32/include/stdio.h:  _CRTIMP FILE *__cdecl _fdopen(int 
_FileHandle,const char *_Mode);
   mob:win32/include/stdio.h:  _CRTIMP FILE *__cdecl _wfdopen(int _FileHandle 
,const wchar_t *_Mode);
   mob:win32/include/stdio.h:  FILE *__cdecl fdopen(int _FileHandle,const char 
*_Format);
   mob:win32/include/tchar.h:#define _tfdopen _wfdopen
   mob:win32/include/tchar.h:#define _tfdopen fdopen
   mob:win32/include/tchar.h:#define _tfdopen _fdopen
   mob:win32/include/wchar.h:  _CRTIMP FILE *__cdecl _wfdopen(int _FileHandle 
,const wchar_t *_Mode);
   mob:win32/lib/msvcrt.def:_fdopen
   mob:win32/lib/msvcrt.def:_wfdopen

Shouldn't take longer than the quarter of an hour.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
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] Re : Re: Re : Re: Extend tcc to use viable.

[Domingo Alvarez Duarte]

Hello Steffen !

Thank you for pointing out 
https://directory.fsf.org/wiki/Lightweight_C++ I just downloaded it and 
fixed several compilers warnings/errors but but there is a need to add 
code to handle/ignore "__attribute__" for the preprocessed headers.


I'm making my fixes available here 
https://github.com/mingodad/cfront-3/issues/6


Cheers !

On 25/2/22 15:54, david.k...@libertysurf.fr wrote:

Yeah, nice project to add some "c++" support to tcc almost for "free".

The dude disappeared after version 1.3.2 in 2008, he perhaps would have 
improved it some more.

The "instrumentation/decoration" of header files is getting really ridiculous.

I pity the preprocessor sometimes, it might see some really horrible things.

I'm wondering if it doesn't commit suicide during some builds.

Regards.

- Mail d'origine -
De: Steffen Nurpmeso 
À: tinycc-devel@nongnu.org
Envoyé: Fri, 25 Feb 2022 15:15:59 +0100 (CET)
Objet: Re: [Tinycc-devel]  Re : Re:  Extend tcc to use viable.

david.k...@libertysurf.fr wrote in
  <1238558077.310183504.1645790418505.javamail.r...@zimbra30-e5.priv.proxa\
  d.net>:
  |Try this : https://directory.fsf.org/wiki/Lightweight_C++

Downloaded it and looked, and wow that is overly impressive!
Some students really go the D. E. Knuth way it seems.
Making it compile is no hard work, but it seems modern C library
headers are instrumented so much it cannot grasp them.
Maybe some day i try to hack it and make that thing work, remove
exceptions and all that.  _That_ language would really be the C++
i like!  (At least in practice, my templates have never been
anything else but typesafe wrappers for generic C types.)
Of course things tend to become more complicated in real life :)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
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 mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Using tcc for reflection

[Domingo Alvarez Duarte]

Every day is a day to learn something new (even if it's old) !

On 1/2/22 22:07, rempas via Tinycc-devel wrote:

This is deceptive!  The GNU libc headers unconditionally define 
'__attribute__()' to nothing if the compiler isn't GCC, and not just 
internally, so a declaration like:


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Using tcc for reflection

[Domingo Alvarez Duarte]

Hello Elijah !

On 1/2/22 6:30, Elijah Stone wrote:

‘cleanup’ variable attribute


It doesn't seem that tinycc has this implemented properly because 
testing it with this example 
https://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html 
I can build and execute it but there is no output (with gcc there is the 
expected output).


Cheers !


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] CFront for TinyCC?

[Domingo Alvarez Duarte]

Hello Christian !

As you said it's for "historical research purposes only" and for fun.

I could get it to compile and bootstrap on Linux 32/64 bits, Windows 
32/64 bits cross compiling with mingw64 and wine and also OSX the output 
of all of then can be viewed here 
https://github.com/mingodad/cfront-3/actions/runs/1421141006 .


And some pending issues here https://github.com/mingodad/cfront-3/issues .

Again any comments/suggestion/pull requests are welcome !

Cheers !

On 2/11/21 14:51, Christian Jullien wrote:

Hi Domingo,
This is very interesting but I wonder what it will be used for?

Stroustrup and others explicitly say that CFront should not be used for any 
purpose except for historical research purpose:

http://www.softwarepreservation.org/projects/c_plus_plus/index.html#release_30
"The source code in this section is posted with the permission of the copyright 
owner for historical research purposes only."

It's fine if you use it within this scope otherwise you should not promote this dev. as a 
way to have a "kind of" C++ on top of tcc.

Christian


-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Domingo Alvarez Duarte
Sent: Tuesday, November 02, 2021 14:07
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] CFront for TinyCC?

Hello !

After making tinycc fully reentrant here
https://github.com/mingodad/tinycc I decided to have a look at cfront
and after a week of work on a fork from seiko2 I've got it to build for
32/64 bits for linux here https://github.com/mingodad/cfront-3 , it also
build on OSX and MYSYS2 with a bit of dirty tweaking that I need to
figure out how to clean up.

I also fixed the parser to build with bison but the generated parser
doesn't work as expected, need more investigation because bison doesn't
find the same conflicts as byacc in a few places.

I already read the prior messages and understand the implications of the
license, but for research and history preservation I think it was worth
the trouble so far.

It can build itself through valgrind without any invalid memory access
(of course it leaks memory as usual for this kind of software and it's
epoch).

If anyone want/can give it a try and give any feedback I appreciate and
thank you in advance !

Cheers !


___
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 mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] CFront for TinyCC?

[Domingo Alvarez Duarte]

Hello !

After making tinycc fully reentrant here 
https://github.com/mingodad/tinycc I decided to have a look at cfront 
and after a week of work on a fork from seiko2 I've got it to build for 
32/64 bits for linux here https://github.com/mingodad/cfront-3 , it also 
build on OSX and MYSYS2 with a bit of dirty tweaking that I need to 
figure out how to clean up.


I also fixed the parser to build with bison but the generated parser 
doesn't work as expected, need more investigation because bison doesn't 
find the same conflicts as byacc in a few places.


I already read the prior messages and understand the implications of the 
license, but for research and history preservation I think it was worth 
the trouble so far.


It can build itself through valgrind without any invalid memory access 
(of course it leaks memory as usual for this kind of software and it's 
epoch).


If anyone want/can give it a try and give any feedback I appreciate and  
thank you in advance !


Cheers !


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Making tinycc fully reentrant

[Domingo Alvarez Duarte]

Hello grischka !

Thanks for pointing out the problem !

After reviewing again I found several other remaining globals/static 
that I now fixed.


I also added a script to invoke gdb on the generate cross compilers to 
show global variables (after changing the build flags to add debug 
info), here is the relevant outuput for one of then:


globals-i386-tcc.txt

=

All defined variables:

File i386-asm.c:
222:    static const ASMInstr asm_instrs[303];
242:    static const uint16_t op0_codes[95];
166:    static const uint8_t reg_to_size[9];
213:    static const uint8_t segment_prefixes[6];
180:    static const uint8_t test_bits[30];

File i386-gen.c:
370:    static const uint8_t fastcall_regs[3];
371:    static const uint8_t fastcallw_regs[2];

File libtcc.c:
1661:    static const FlagDef options_W[7];
1671:    static const FlagDef options_f[8];
1682:    static const FlagDef options_m[2];
1581:    static const TCCOption tcc_options[56];

File tcc.c:
27:    static const char help[2088];
86:    static const char help2[2551];
153:    static const char version[55];

File tcc.h:
1795:    static const int reg_classes[5];
1794:    static const char * const target_machine_defs;

File tccgen.c:
86:    static const struct {
    int type;
    const char *name;
} default_debug[27];

File tccpp.c:
3139:    static const char ab_month_name[12][4];
3635:    static const char * const target_os_defs;
31:    static const char tcc_keywords[6211];

38:    static const unsigned char tok_two_chars[67];

=

With respect to "any tinycc practical project exists" I consider libtcc 
the main project and tcc and all cross compiler variants as usage 
examples of it.


Again any feedback pull request is welcome !

Cheers !

On 25/10/21 0:25, grischka wrote:

Domingo Alvarez Duarte wrote:

Hello again grischka !

I finally managed to get a github workflow to build my reentrant fork of
tinycc on linux, osx and windows.

Actually there is two builds:

- one with CONFIG_TCC_SEMLOCK set to ONE here
https://github.com/mingodad/tinycc/actions/runs/1378248438

- and another with CONFIG_TCC_SEMLOCK set to ZERO here
https://github.com/mingodad/tinycc/actions/runs/1378259299 and it seems
that in both all tests pass.

Obs: You can clcik on individual builds to see the build/test output.

Please if anyone is willing to test it and give any feedback I'll
appreciate.


Sorry, forgot to mention i386-windows.  The problem seen obviously
was caused by the 2 static globals still present in i385-gen.c.

So with that corrected I can report that the 3rd test of
libtcc_test_mt
    "running tcc.c in threads to run fib"
actually runs faster with your version (here, with 2 CPU cores.
~1600ms, compared to ~2600ms with the semaphore lock).

Whether any practical project exists or ever will exist that would
benefit from that is another question.  One could think of a tcc
able to compile several files in parallel for example, but maybe
people will more likely stick to make -j instead.

--- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Making tinycc fully reentrant

[Domingo Alvarez Duarte]

Hello Christian !

Thank you for reply !

I also noticed that there was some problems when trying to compile for 
arm64 on Android under termux.


I'll put my changes here now https://github.com/mingodad/tinycc.

I did reverted all my changes !

Cheers !

On 22/10/21 6:00, Christian Jullien wrote:

Hi Domingo,
Thank you for your attempt to make tcc better. However, please never commit 
huge changes like this without making a branch before **and** ask maintainers 
if they agree (I'm not a maintainer but an enthusiast user).
So I strongly suggest you revert your all changes as, among others, it breaks

- Windows:
../tccpe.c:871: warning: assignment from incompatible pointer type
In file included from ../tcc.c:25:
../tcctools.c:442: error: 'S' undeclared

- macOS
In file included from tcc.c:21:
In file included from ./tcc.h:362:
./libtcc.h:28:16: error: typedef redefinition with different types ('long' vs 
'__darwin_off_t' (aka 'long long'))
   typedef long off_t;
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_off_t.h:31:33:
 note: previous definition is here
typedef __darwin_off_t  off_t;

Christian

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Domingo Alvarez Duarte
Sent: Thursday, October 21, 2021 20:19
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Making tinycc fully reentrant

Hello !

I did it once in the past and did again moving almost all global
variables to TCCState and on Ubuntu 18.04 x86_64 all tests from "make
test" pass.

It's a massive refactoring (3 full working days).

Any comments/suggestions are welcome !

Cheers !


___
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 mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Making tinycc fully reentrant

[Domingo Alvarez Duarte]

Hello !

I did it once in the past and did again moving almost all global 
variables to TCCState and on Ubuntu 18.04 x86_64 all tests from "make 
test" pass.


It's a massive refactoring (3 full working days).

Any comments/suggestions are welcome !

Cheers !


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Mach-O (i.e. MacOS) support

[Domingo Alvarez Duarte]

I think that if it's not too hard to maintain 32bits it shouldn't be 
removed, because there is still working machines that run 32bits code 
(used and usable second hand).


On 21/6/20 6:56, Christian Jullien wrote:

Hello Matz,

Amazing!! I'm glad to be the first to tell you it works ROOTB including all
tests. (I'll do more tests with OpenLisp but I'm confident)
I think you can drop 32bit support as Apple no longer supports 32bit
binaries on latest OS version.

I tested this port on

- MacBook Air 2011 running High-Sierra
jullien@jacquet:~/tinycc $ uname -a
Darwin jacquet.local 17.7.0 Darwin Kernel Version 17.7.0: Wed May 27
17:00:02 PDT 2020; root:xnu-4570.71.80.1~1/RELEASE_X86_64 x86_64
jullien@jacquet:~/tinycc $ clang -v
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin17.7.0
jullien@jacquet:~/tinycc $ file tcc
tcc: Mach-O 64-bit executable x86_64

- MacBook Pro 2012 running Catalina (fully up to date)
jullien@byas tinycc % uname -a
Darwin byas.local 19.5.0 Darwin Kernel Version 19.5.0: Tue May 26 20:41:44
PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64
jullien@byas tinycc % clang -v
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.5.0
jullien@byas tinycc % file tcc
tcc: Mach-O 64-bit executable x86_64

I only get the following warning when running the tests suite:

 memtest 
In file included from ../tcc.c:23:
In file included from ../libtcc.c:22:
../tccpp.c:1439:33: warning: adding 'int' to a string does not append to the
   string [-Wstring-plus-int]
 fprintf(s->ppfp, "\n[%s]\n" + !(s->dflag & 32), p), fflush(s->ppfp);
  ~~~^~
../tccpp.c:1439:33: note: use array indexing to silence this warning
 fprintf(s->ppfp, "\n[%s]\n" + !(s->dflag & 32), p), fflush(s->ppfp);
 ^
  &  [ ]
../tccpp.c:3823:20: warning: adding 'int' to a string does not append to the
   string [-Wstring-plus-int]
 fprintf(fp, " %s" + s, get_tok_str(t, )), s = 1;
 ~~^~~
../tccpp.c:3823:20: note: use array indexing to silence this warning
 fprintf(fp, " %s" + s, get_tok_str(t, )), s = 1;
   ^
 & [  ]
In file included from ../tcc.c:23:
In file included from ../libtcc.c:24:
../tccelf.c:1421:36: warning: adding 'int' to a string does not append to
the
   string [-Wstring-plus-int]
 set_local_sym(s1, "___rt_info" + !s1->leading_underscore, s, o);
   ~^
../tccelf.c:1421:36: note: use array indexing to silence this warning
 set_local_sym(s1, "___rt_info" + !s1->leading_underscore, s, o);
^
   &[]
In file included from ../tcc.c:23:
In file included from ../libtcc.c:25:
../tccrun.c:148:36: warning: adding 'int' to a string does not append to the
   string [-Wstring-plus-int]
 tcc_add_symbol(s1, "_exit" + !s1->leading_underscore, rt_exit);
^
../tccrun.c:148:36: note: use array indexing to silence this warning
 tcc_add_symbol(s1, "_exit" + !s1->leading_underscore, rt_exit);
^
&   []
4 warnings generated.
OK

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Michael Matz
Sent: Saturday, June 20, 2020 23:47
To: jull...@eligis.com; tinycc-devel@nongnu.org
Cc: Karl Yerkes
Subject: [Tinycc-devel] Mach-O (i.e. MacOS) support

Hello,

On Tue, 16 Jun 2020, Christian Jullien wrote:


Hi, it looks new and I?ve not tested this solution but it may help to
finally get a native tcc port on macOS. Image is around 200Gb

I've just pushed my macos port to mob.  It's lightly tested but seems to
work reasonably well, the testsuite is clean.  I.e. you can now create
proper Mach-O executable files, link against system .dylibs and such.  I
didn't bother implementing a Mach-O object file reader, so the support is
similar to Windows: you need to use TCC to compile C files into .o files
(which are ELF files), and then TCC to link those, which generates Mach-O
executables.

Generating shared libraries isn't implemented, neither are 32bit objects.
The generated executables should be runnable with relatively old MacOS
versions (dyld needs to support LC_MAIN, so 10.8 should be enough) but I've
developed and checked this only on 10.14 (Mojave).

You need at least the command line tools installed for system headers, but
you don't need to unpack them into /usr/include (modern MacOS deprecated
that one), the configure step tries to figure out the correct SDK directory
by using xcrun (which is then hardcoded into TCC as search path for now).

For emulation I started with

Re: [Tinycc-devel] make tcc reentrant

[Domingo Alvarez Duarte]

Hello !

We can have direct measure using https://github.com/mingodad/tinycc that 
already does/did the transformation to make tinycc reentrant and maybe 
revive it.


Cheers !

On 9/12/19 16:33, Michael Matz wrote:

Hi,

On Sat, 7 Dec 2019, Christian Jullien wrote:


2) slower code: most of the time the indirection through a pointer

variable (the state) in comparison to a direct access to a static
variable doesn't matter.

In fact, I experimented the opposite. When moving all global variables
to a struct, my Lisp was around 1% faster because globals are now close
together and more often accessible from L1 cache.

They are equally close in the .data section/segment, as long as you put
_all_ global data into that struct (which is what was proposed).  I do
believe you that it was faster, merely pointing out that it probably had
other reasons.

Either way, I measured with TCC itself, not some other program with
completely different behaviour.  Specifically the accesses to the token
hash table from the pre-processor (tokenization is the slowest part in
TCC, as it should be) currently needs only one register, because the
address of that table is an immediate.  Just changing this to be a pointer
(cached in a register), with otherwise similar code made the inner loop of
tokenization measurably slower (though I don't remember the percentage
anymore, but I was thinking "meeh").  The effect is that on x86-64 the
computation either needs a slow addressing mode, or multiple instructions
(which are dependend then), which alone caused this slowdown.

Of course, we could decide that a (say) 2% slowdown in compilation speed
is acceptable for the feature of multiple compiler states that don't have
to interact.

Or we could think long and hard about what we really want/need from our
APIs and try to get both.  E.g. it's not clear that the token hash table
really needs to become a non-singleton, even _if_ we'd allow multiple
TCCState objects.  It's just that the update to the token hash must not be
done concurrently.

So, we could for instance allow and support multiple TCCStates but
_without_ multi-threading.  Or (like grischka said) allow multi-threading,
but only on the API level (and serialize internally).

So, I think the latter is the solution with the most bang for the buck:
allow multiple TCCStates, but don't necessarily move all global data into
the state, under the assumption that at its core TCC remains
single-threaded.

We'd also still have to decide what multiple TCCStates really mean: e.g.
I'd say this is only for compiling to memory.  That would mean that it's
not really necessary for the code from different states to be generated
into different sections.  Though finalization needs to be per state, so
maybe it's unavoidable, but that needs to be tried.  There might be other
global data (e.g. the memory allocator) that also could remain shared
between different states.  (Again, all with the assumption that
multi-threading is serialized high in the API level).


Ciao,
Michael.


It has of course no effect when global is a pointer which introduces the
same indirection. It is true for aggressive optimizers which are likely
to put struct pointer to a register. So it may be faster for tcc
compiled by gcc, clang or vc++ but slower when tcc is compiled by tcc.

C.

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Michael Matz
Sent: Friday, December 06, 2019 16:42
To: TCC mailing list
Subject: Re: [Tinycc-devel] make tcc reentrant

Hello,

On Tue, 3 Dec 2019, Ulrich Schmidt wrote:


i try to write a lua binding for tcc. To work out propperly, the tcc lib
needs to be reentrant.

As demonstrated down-thread, that isn't correct.  It doesn't _need_ to be,
it would be an feature.  As usual with features it needs to be measured
against the downsides.  The downsides for your proposed changes are the
following at least:
1) more complicated/boiler-platy source code of TCC (a TCCState
argument almost everywhere)
2) slower code: most of the time the indirection through a pointer
variable (the state) in comparison to a direct access to a static
variable doesn't matter.  But it does matter for the symbol/token
table (and potentially for the register/evaluation stack).  I have
measured this years ago for the token table, so this might or might not
still be the case.

So, while I can see the wish for this feature, I don't necessarily see
that tcc should be changed to accomodate.

If anything I would expect a _complete_ transition to exist, in order to
measure the impact.  The worst thing that could happen is if someone added
TCCState arguments everywhere, moved some static variables to that state,
and then leaves: none of the features of this whole excercise would be
had, but all the downsides would be there.

And yes, this is a big project.  I really think it would be better
if you simply write a wrapper for libtcc that ensures 

Re: [Tinycc-devel] make tcc reentrant

[Domingo Alvarez Duarte]

Hello !

I went to the trouble of making tcc fully reentrant but it was not 
accepted https://github.com/mingodad/tinycc which is sad.


Cheers !

On 6/12/19 22:16, Charles Lohr wrote:
Is there a reason you don't just compile tcc in tcc to make the tcc 
instance that is basically then reentrant?  I've used this trick a 
while on things other than tcc, turning all global or static variables 
in any C program into an object that can be created or deleted or 
duplicated in a process space.


Charles

On Fri, Dec 6, 2019 at 11:46 AM ag > wrote:


On Fri, Dec 06, at 03:42 Michael Matz wrote:
> Hello,
>
> On Tue, 3 Dec 2019, Ulrich Schmidt wrote:
>
> > i try to write a lua binding for tcc. To work out propperly,
the tcc lib
> > needs to be reentrant.
>
> As demonstrated down-thread, that isn't correct.  It doesn't
_need_ to be,
> it would be an feature.  As usual with features it needs to be
measured
> against the downsides.  The downsides for your proposed changes
are the
> following at least:
> 1) more complicated/boiler-platy source code of TCC (a TCCState
>    argument almost everywhere)
> 2) slower code: most of the time the indirection through a pointer
>    variable (the state) in comparison to a direct access to a
static
>    variable doesn't matter.  But it does matter for the
symbol/token
>    table (and potentially for the register/evaluation stack).  I
have
>    measured this years ago for the token table, so this might or
might not
>    still be the case.
>
> So, while I can see the wish for this feature, I don't
necessarily see
> that tcc should be changed to accomodate.
>
> If anything I would expect a _complete_ transition to exist, in
order to
> measure the impact.  The worst thing that could happen is if
someone added
> TCCState arguments everywhere, moved some static variables to
that state,
> and then leaves: none of the features of this whole excercise
would be
> had, but all the downsides would be there.
>
> And yes, this is a big project.  I really think it would be better
> if you simply write a wrapper for libtcc that ensures
single-threadedness
> and that regards TCCState as a singleton.  I think such thing
would be
> well-suited in the TCC sources itself.
>
> (In a way it seems prudent for a tiny C compiler to only be
usable as a
> singleton)

I maybe understand, that a C compiler would be best as a
singleton, as a
state can influence unexpectedly the other states (unless (perhaps
like in
this case as it would be under Lua control) there is a mechanism
to handle
gracefully any errors)), and i can trust you about the "direct
access to static
variables", but how about an (probably predefined (even with a
compile option)
__array__ of states (under a single-thread), and expose it
generiously and with
a pleasure to the user responsibility, without tcc guilties (if any)?
Perhaps can even implement this mechanism (to have a control of
the environment)
by it's own.

Anyway C is unsafe by default (if it is that worry).

> Ciao,
> Michael.

Best,
  Αγαθοκλής

> >
> > I took a look into the sources and found some comments
(XXX:...) and
> > started with removing
> >
> > the static var tcc_state. As a result allmost all lib
functions needs a
> > 1st parameter of
> >
> > type TCCState*. I did this in my own local branch and tcc is still
> > running :).
> >
> > But this is a really HUGE change. in addition most of the
local vars in
> > tccpp, tccgen, ... needs
> >
> > to be moved to TCCState. I can do that but at some points i
will have
> > some questions and i
> >
> > can only test on windows and probably on linux.
> >
> > My 1st question is: Are you interested in these changes or
should i do
> > this locally?
> >
> > I would like to this together with you.
> >
> >
> > Greetings.
> >
> > Ulrich.

___
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 mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] c extensions

[Domingo Alvarez Duarte]

I like your idea in principle, have you thought to use a tool like led/peg
parser http://piumarta.com/software/peg/ using a C grammar like
http://www.romanredz.se/freesoft.htm#C, you'll have more freedom to express
your ideas.

Also maybe you already know this:

- http://milgra.com/classc/
- pcc http://pcc.ludd.ltu.se/ has the beginings of a c++ made on top of c
uses bison/yacc.
- vala https://wiki.gnome.org/Projects/Vala
- Class-C source-to-source compiler http://www.milgra.com/classc
- https://github.com/ryanashcraft/Classified-C

Cheers !


On Fri, Apr 18, 2014 at 12:17 PM, mobi phil m...@mobiphil.com wrote:

 Hi,


 I know that this topic was here few times, last time I came with some
 questions.

 The goal of this email is both to purpose some simple tcc meta extension
 and to ask
 some further help to implement what I need.

 My intention is to extend C with some features for object (oriented)
 programming.
 In my previous email about the topic I mentioned that I wanted to
 implement those
 extensions with macros. Though I invested a lot of time, I realized that
 it was rather
 a stoic exercise and with the macros will be impossible to implement more
 powerful
 constructs like type checking.

 After lot of brainstorming, I have a better understanding of what
 extensions I would like
 to have and how I want to implement them.

 I will basically need 4 constructs:

 1. a struct like construct, black. This is the blackbox of the object.
 This will be mainly
 defined in the source file and holds private objects/members. So far did
 not find
 a better name. One candidate would be implementation, but it is also not
 really
 the implementation etc.

 example:

 black MyType
 {
type1 member1;
type2 member2;
type3 member3;
 };

 2. a struct like construct, white. Again, did not find a better name,
 interface could have
 been a candidate, but the real interface to the object will be the virtual
 methods declared
 inside the white block + the static methods that are defined outside of
 the block.

 white MyType: Object /* inheritance, though there will be no
 public/private keywoards for the moment */
 {
type1 aVirtualMethod();

type1 member1; /* this is the declaration of on accessor that will be
 bound to the one with
   same name from the /*black*/
 }

 3. a method declaration and definiton. This will be similar to the C++
 method definition.

 /* in the header file */
 type1 MyType:.aNonVirtualMethod();

 /* later in the implementation file */
 type1 MyType:.aNonVirtualMethod();

 note here the usage of the :. instead of :: as the semantic is a bit
 different than in C++

 4. method call

 type1 object;
 object..aVirtualMethod();

 the token here is .. instead of . or -
 This is again has different semantics. But would not bother with details
 for the moment.

 Further new constructs are in my mind for fibers, continuations (yes they
 will be different) and and.
 Decided to call this babel C, so files will probably have extension
 bh/bc (header/implementation)

 The bc file will be translated into pure C by the modified tcc. A
 construct like 1. will be translated into
 a C struct with some additional part etc + some glue code. (Will not go
 into details, but will publish soon the details).
 Construct 2 will be also translated into a struc + some glue code, the
 same with 3. and 4.

 I studied the tcc parser and compiler bit more in depth. Found more or
 less where I should patch. I kept things easy,
 (you remember wanted to use some special syntax with @  etc. etc.), so
 that my stuff fits easyl
 into the parsers logic.

 What I need now and this is the minimum that would be probably nice to see
 it going upstream.
 My first naiv approach wast to save a pointer in the input buffer and:
 - anything that is normal C syntax, after successful parsing of a
 declaration or part of a declaration,
 send the input to the output
 - anything that is syntax extension, fill in a kind of template and send
 the result to the output.
 This task became though a bit complex for me due to the pre-processing.
 Got a bit lost with token managemnt,
 but probably after further hours could find the solution. Though some
 hints would be welcome.

 I got the suggestion to separate the code from original tcc, keep the
 parser and implement my code generation.
 Not sure that this would make my life easier. Do not think this is a good
 idea as the assembly code generation
 bits would not disturb me (the part that would be redundant for me).

 My own first question seems to be confusing as it is not easy to ask it
 :)... I am rather expecting some hints..
 The second question if you could suggest some basic changes in the parser
 and supporting code that
 would make life easier to implement such extensions for code generation.

 thanks a lot,
 mobi phil

 ___
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Is this ok on commit Use proper PLT/GOT for -run

[Domingo Alvarez Duarte]

Hello !

When applying this commit to my fork, I'm not sure if it's correct:



 arm: Use proper PLT/GOT for
-run.http://repo.or.cz/w/tinycc.git/commit/01c041923474750a236da02561f0f8835445848bhttp://repo.or.cz/w/tinycc.git/commit/01c041923474750a236da02561f0f8835445848b
[tinycc.git]http://repo.or.cz/w/tinycc.git/tree/01c041923474750a236da02561f0f8835445848b/
tcc.hhttp://repo.or.cz/w/tinycc.git/blob_plain/01c041923474750a236da02561f0f8835445848b:/tcc.h
  diff --git 
a/tcc.hhttp://repo.or.cz/w/tinycc.git/blob/76f25bd5e7950f470b3d7bcafa8a0dc467a0ed9d:/tcc.h
b/tcc.hhttp://repo.or.cz/w/tinycc.git/blob/5033b19bd6a285df2988843fe03c99b479dafc9e:/tcc.h
 index 
76f25bdhttp://repo.or.cz/w/tinycc.git/blob/76f25bd5e7950f470b3d7bcafa8a0dc467a0ed9d:/tcc.h
..5033b19http://repo.or.cz/w/tinycc.git/blob/5033b19bd6a285df2988843fe03c99b479dafc9e:/tcc.h100644(file)
 --- 
a/tcc.hhttp://repo.or.cz/w/tinycc.git/blob/76f25bd5e7950f470b3d7bcafa8a0dc467a0ed9d:/tcc.h
+++ 
b/tcc.hhttp://repo.or.cz/w/tinycc.git/blob/5033b19bd6a285df2988843fe03c99b479dafc9e:/tcc.h
@@ 
-712,7http://repo.or.cz/w/tinycc.git/blob/76f25bd5e7950f470b3d7bcafa8a0dc467a0ed9d:/tcc.h#l712
+712,7http://repo.or.cz/w/tinycc.git/blob/5033b19bd6a285df2988843fe03c99b479dafc9e:/tcc.h#l712@@
 struct TCCState {
 void *write_mem;
 unsigned long mem_size;
 # endif
-# if !defined TCC_TARGET_PE  (defined TCC_TARGET_ARM)
+# if !defined TCC_TARGET_PE  (0)  is this correct
?
 /* write PLT and GOT here */
 char *runtime_plt_and_got;
 unsigned runtime_plt_and_got_offset;
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Is this ok on commit Use proper PLT/GOT for -run

[Domingo Alvarez Duarte]

Ok I can see in the next commit that this is removed completely !


On Sun, Apr 6, 2014 at 11:19 AM, Domingo Alvarez Duarte
mingo...@gmail.comwrote:

 Hello !

 When applying this commit to my fork, I'm not sure if it's correct:

 

  arm: Use proper PLT/GOT for 
 -run.http://repo.or.cz/w/tinycc.git/commit/01c041923474750a236da02561f0f8835445848bhttp://repo.or.cz/w/tinycc.git/commit/01c041923474750a236da02561f0f8835445848b
 [tinycc.git]http://repo.or.cz/w/tinycc.git/tree/01c041923474750a236da02561f0f8835445848b/
 tcc.hhttp://repo.or.cz/w/tinycc.git/blob_plain/01c041923474750a236da02561f0f8835445848b:/tcc.h
   diff --git 
 a/tcc.hhttp://repo.or.cz/w/tinycc.git/blob/76f25bd5e7950f470b3d7bcafa8a0dc467a0ed9d:/tcc.h
 b/tcc.hhttp://repo.or.cz/w/tinycc.git/blob/5033b19bd6a285df2988843fe03c99b479dafc9e:/tcc.h
  index 
 76f25bdhttp://repo.or.cz/w/tinycc.git/blob/76f25bd5e7950f470b3d7bcafa8a0dc467a0ed9d:/tcc.h
 ..5033b19http://repo.or.cz/w/tinycc.git/blob/5033b19bd6a285df2988843fe03c99b479dafc9e:/tcc.h100644(file)
  --- 
 a/tcc.hhttp://repo.or.cz/w/tinycc.git/blob/76f25bd5e7950f470b3d7bcafa8a0dc467a0ed9d:/tcc.h
 +++ 
 b/tcc.hhttp://repo.or.cz/w/tinycc.git/blob/5033b19bd6a285df2988843fe03c99b479dafc9e:/tcc.h
 @@ 
 -712,7http://repo.or.cz/w/tinycc.git/blob/76f25bd5e7950f470b3d7bcafa8a0dc467a0ed9d:/tcc.h#l712
 +712,7http://repo.or.cz/w/tinycc.git/blob/5033b19bd6a285df2988843fe03c99b479dafc9e:/tcc.h#l712@@
  struct TCCState {
  void *write_mem;
  unsigned long mem_size;
  # endif
 -# if !defined TCC_TARGET_PE  (defined TCC_TARGET_ARM)
 +# if !defined TCC_TARGET_PE  (0)  is this correct
 ?
  /* write PLT and GOT here */
  char *runtime_plt_and_got;
  unsigned runtime_plt_and_got_offset;

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Is this ok on commit Use proper PLT/GOT for -run

[Domingo Alvarez Duarte]

On win32 with mingw64 I'm getting this error:
-
gcc -o i386-win32/tiny_libmaker.exe ../win32/tools/tiny_libmaker.c -I..
 -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare
-Wno-unused-result -fPIC -DTCC_TARGET_I386 -DTCC_TARGET_PE
../win32/tools/tiny_libmaker.c:1:0: warning: -fPIC ignored for target (all
code is position independent) [enabled by default]
 /*
 ^
i386-win32/tiny_libmaker.exe rcs ../libtcc1.a i386-win32/libtcc1.o
i386-win32/alloca86.o i386-win32/alloca86-bt.o i386-win32/bcheck.o
i386-win32/crt1.o i386-win32/wincrt1.o i386-win32/dllcrt1.o
i386-win32/dllmain.o i386-win32/chkstk.o
Unsupported Elf Class: i386-win32/alloca86.o
Makefile:103: recipe for target `../libtcc1.a' failed
make[1]: *** [../libtcc1.a] Error 2
make[1]: Leaving directory `/home/IEUser/dev/tinycc/lib'
Makefile:229: recipe for target `libtcc1.a' failed


On Sun, Apr 6, 2014 at 11:50 AM, Michael Matz matz@frakked.de wrote:

 Hi,


 On Sun, 6 Apr 2014, Domingo Alvarez Duarte wrote:

  Ok I can see in the next commit that this is removed completely !


 Yep, I was trying to separate cleanups from implementing features also for
 the commits, makes bisecting a tad easier.  (And of course removing chunks
 of dead code without much else just feels wonderful :) ).


 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] Tinycc for ARM help needed !

[Domingo Alvarez Duarte]

Thanks for the help !

Testing on my linux X86_64 give me this error:

-
~/dev/c/tinycc/tests$ ../tcc -B.. -I.. -I.. -I../include
-DCONFIG_LDDIR=\lib\ -DCONFIG_MULTIARCHDIR=\x86_64-linux-gnu\
-DTCC_TARGET_X86_64 -DONE_SOURCE -o tcc.tcc ../tcc.c -ldl

~/dev/c/tinycc/tests$ valgrind --tool=memcheck ./tcc.tcc
==5044== Memcheck, a memory error detector
==5044== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==5044== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==5044== Command: ./tcc.tcc
==5044==

valgrind: m_debuginfo/readelf.c:2352 (vgModuleLocal_read_elf_debug_info):
Assertion 'crc_offset + sizeof(UInt) = debuglink_escn.szB' failed.
==5044==at 0x3804F522: ??? (in
/home/mingo/local/lib/valgrind/memcheck-amd64-linux)

sched status:
  running_tid=0


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.


On Thu, Apr 3, 2014 at 5:07 PM, Michael Matz matz@frakked.de wrote:

 Hi,

 On Wed, 2 Apr 2014, Domingo Alvarez Duarte wrote:

  1- Inconsistency detected by ld.so: rtld.c: 1292: dl_main: Assertion
  `_rtld_local._dl_rtld_map.l_libname' failed! for this one I found a
  workaround making a change on tccelf.c (it's on the mob but commented
  because it has a side effect of programs generated with debug information
  and stripped afterwards segfaults).

 I think I've fixed this one.  TCC was emitting ELF files that aren't liked
 by binutils strip, and creating a PT_PHDR exposed those problems.  mob
 since f2c8491 should work (at least valgrind before and after stripping
 executables for x86 and x86-64 do).


 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] Tinycc for ARM help needed !

[Domingo Alvarez Duarte]

This error appear only when the program is compiled with tinycc without
debug info, with debug info valgrind runs fine without errors, and striping
the program then the program and valgrind also works fine.


On Thu, Apr 3, 2014 at 5:41 PM, Domingo Alvarez Duarte
mingo...@gmail.comwrote:

 Thanks for the help !

 Testing on my linux X86_64 give me this error:

 -
 ~/dev/c/tinycc/tests$ ../tcc -B.. -I.. -I.. -I../include
 -DCONFIG_LDDIR=\lib\ -DCONFIG_MULTIARCHDIR=\x86_64-linux-gnu\
 -DTCC_TARGET_X86_64 -DONE_SOURCE -o tcc.tcc ../tcc.c -ldl

 ~/dev/c/tinycc/tests$ valgrind --tool=memcheck ./tcc.tcc
 ==5044== Memcheck, a memory error detector
 ==5044== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
 ==5044== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
 ==5044== Command: ./tcc.tcc
 ==5044==

 valgrind: m_debuginfo/readelf.c:2352 (vgModuleLocal_read_elf_debug_info):
 Assertion 'crc_offset + sizeof(UInt) = debuglink_escn.szB' failed.
 ==5044==at 0x3804F522: ??? (in
 /home/mingo/local/lib/valgrind/memcheck-amd64-linux)

 sched status:
   running_tid=0


 Note: see also the FAQ in the source distribution.
 It contains workarounds to several common problems.
 In particular, if Valgrind aborted or crashed after
 identifying problems in your program, there's a good chance
 that fixing those problems will prevent Valgrind aborting or
 crashing, especially if it happened in m_mallocfree.c.

 If that doesn't help, please report this bug to: www.valgrind.org

 In the bug report, send all the above text, the valgrind
 version, and what OS and version you are using.  Thanks.


 On Thu, Apr 3, 2014 at 5:07 PM, Michael Matz matz@frakked.de wrote:

 Hi,

 On Wed, 2 Apr 2014, Domingo Alvarez Duarte wrote:

  1- Inconsistency detected by ld.so: rtld.c: 1292: dl_main: Assertion
  `_rtld_local._dl_rtld_map.l_libname' failed! for this one I found a
  workaround making a change on tccelf.c (it's on the mob but commented
  because it has a side effect of programs generated with debug
 information
  and stripped afterwards segfaults).

 I think I've fixed this one.  TCC was emitting ELF files that aren't liked
 by binutils strip, and creating a PT_PHDR exposed those problems.  mob
 since f2c8491 should work (at least valgrind before and after stripping
 executables for x86 and x86-64 do).


 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] tcc i386 test failures after commit ea2805f

[Domingo Alvarez Duarte]

Indeed I did so on my repository
https://github.com/mingodad/tinycc/commit/74840e25b5d2bde099dbd3e7088cfef49bb172ce


On Thu, Apr 3, 2014 at 8:55 PM, Domingo Alvarez Duarte
mingo...@gmail.comwrote:

 I propose to remove bounds check from tests/build till we have a good
 solution/implementation to it.


 On Thu, Apr 3, 2014 at 8:34 PM, Ramsay Jones 
 ram...@ramsay1.demon.co.ukwrote:

 Hi Michael,

 tcc on i386 has been failing a couple of tests for a while.
 For example, commit 3e56584 (Allow local redefinition of enumerator,
 31-03-2014), fails like so:

   $ make test
   ...
    test1b 
   ../tcc -B.. -I.. -I.. -I../include -b -run tcctest.c  test.out1
   --- test.ref  2014-04-03 20:09:19.207429405 +0100
   +++ test.out1 2014-04-03 20:09:19.879432730 +0100
   @@ -538,7 +538,7 @@
Test C99 VLA 2 (ptrs substract): PASSED
Test C99 VLA 3 (ptr add): PASSED
Test C99 VLA 4 (ptr access): PASSED
   -Test C99 VLA 5 (bounds checking (might be disabled)): PASSED PASSED
 PASSED PASSED PASSED PASSED PASSED PASSED
   +Test C99 VLA 5 (bounds checking (might be disabled)): FAILED PASSED
 FAILED PASSED FAILED PASSED FAILED PASSED
sizeof(int) = 4
sizeof(unsigned int) = 4
sizeof(long) = 4
   make[1]: *** [test1b] Error 1
   make[1]: Leaving directory `/home/ramsay/tinycc/tests'
   make: *** [test] Error 2
   $

 After commit ea2805f (shared libs: Build libtcc1.a with -fPIC,
 02-04-2014),
 this now fails like so:

   $ make test
   ...
    test1b 
   ../tcc -B.. -I.. -I.. -I../include -b -run tcctest.c  test.out1
   Runtime error: dereferencing invalid pointer
   at 0x9a6dc23 __bound_init()
   Segmentation fault
   make[1]: *** [test1b] Error 139
   make[1]: Leaving directory `/home/ramsay/tinycc/tests'
   make: *** [test] Error 2
   $

 Also, running 'make -k test', show other (bounds) tests failing in
 a similar fashion (test3b and btest).

 I don't have time to investigate this myself (sorry!).

 HTH

 ATB,
 Ramsay Jones




 ___
 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] Valgrind Inconsistency detected by ld.so: rtld.c:

[Domingo Alvarez Duarte]

Hello Daniel !

Just in case do you want to look at it too, I discovered other issue with
sqlite3 compiled with tcc on arm,
running the query bellow on sqlite3-gcc takes 1 second but doing the same
on sqlite3-tcc takes for ever,
if we remove the call to datetime and use only the field mtime the the
sqlite3-tcc works almost like sqlite3-gcc.

Obs.: fossil.fossil is the database of fossil-scm local repository.

sqlite3-gcc fossil.fossil  query.sql
sqlite3-tcc fossil.fossil  query.sql


-
--EXPLAIN
SELECT
  datetime(event.mtime) AS timestamp
  --mtime
 FROM event
ORDER BY 1 --event.mtime
DESC
LIMIT 20;
-


On Mon, Mar 31, 2014 at 11:14 PM, Domingo Alvarez Duarte mingo...@gmail.com
 wrote:

 Hello Daniel !

 I'm still looking at why fossil-scm compiled by tcc do not work properly
 and found that now the problem is with the sqlite3 sources compiled with
 tcc, in a place where we have a fossil repository database I run this:

 -
 #include stdio.h
 #include stdarg.h
 #include src/sqlite3.h

 static int mydb_exists(sqlite3 *db, const char *zSql, ...){
   va_list ap;
   int rc;
   va_start(ap, zSql);
   sqlite3_stmt *pStmt;
   rc = sqlite3_prepare_v2(db, zSql, -1, pStmt, 0);
   va_end(ap);
 printf(%s:%d - %d %s\n, __FILE__, __LINE__, rc, zSql);
   rc = sqlite3_step(pStmt);
 printf(%s:%d - %d %s\n, __FILE__, __LINE__, rc, zSql);
   if( rc !=SQLITE_ROW ) {
 rc = 0;
   }else{
 rc = 1;
   }
   sqlite3_finalize(pStmt);
   return rc;
 }

 static const char *sql = SELECT 
   blob.rid AS blobRid, 
   uuid AS uuid, 
   datetime(event.mtime) AS timestamp, 
   coalesce(ecomment, comment) AS comment, 
   coalesce(euser, user) AS user, 
   blob.rid IN leaf AS leaf, 
   bgcolor AS bgColor, 
   event.type AS eventType, 
   (SELECT group_concat(substr(tagname,5), ', ') FROM tag, tagxref 
 WHERE tagname GLOB 'sym-*' AND tag.tagid=tagxref.tagid 
   AND tagxref.rid=blob.rid AND tagxref.tagtype0) AS tags, 
   tagid AS tagid, 
   brief AS brief, 
   event.mtime AS mtime 
  FROM event CROSS JOIN blob 
 WHERE blob.rid=event.objid 
  AND NOT EXISTS(SELECT 1 FROM tagxref WHERE tagid=5 AND tagtype0 AND
 rid=blob.rid) ORDER BY event.mtime DESC LIMIT 20;


 int main() {

 sqlite3 *db;
 int rc = sqlite3_open_v2(
fossil.fossil, db,
SQLITE_OPEN_READWRITE, NULL);
 printf(%d Exists %d\n, rc, mydb_exists(db, sql));
  sqlite3_close(db);
 return 0;
 }
 -

 compiling it with this script:

 -
 gcc -o test-query-gcc test-query.c src/sqlite3.c -ldl -lpthread
 tcc -o test-query-tcc test-query.c src/sqlite3.c -ldl -lpthread
 -

 And get results from the test-query-gcc but no results from
  test-query-tcc, now I'll try to get more close to the problem.

 Cheers !


 On Sat, Mar 29, 2014 at 5:57 PM, Domingo Alvarez Duarte 
 mingo...@gmail.com wrote:

 Hello Daniel !

 With your commit tcc can compile and run the server but it's not all
 functional, like the timeline shows nothing.

 I'll further invetigate why and send you more details about what can be
 now.

 Thanks so much !


 On Sat, Mar 29, 2014 at 5:20 PM, Daniel Glöckner daniel...@gmx.netwrote:

 On Fri, Mar 28, 2014 at 12:27:39PM +, Domingo Alvarez Duarte wrote:
  For arm experts, it gets a segfault on translate.c:98

 Please try again with current mob.
 I fixed a bug that might be the cause for your segfault.

 Best regards,

   Daniel


 P.S.: I wonder if a better fix would be to use convert_parameter_type in
   gfunc_param_typed.

 ___
 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] improving get_tok_str

[Domingo Alvarez Duarte]

Hello Thomas !

What do you mean by old version of tcc there is other newer versions
elsewhere ?

Cheers !


On Mon, Mar 31, 2014 at 3:26 PM, Thomas Preudhomme robo...@celest.frwrote:

 Le 2014-03-30 21:18, Domingo Alvarez Duarte a écrit :

 That would be nice !

 I would like to see the implementation of

 qcc http://lists.nongnu.org/archive/html/tinycc-devel/
 2011-09/txtYogaFhDvlT.txt
 [3] and any documentation will help on it, someone asked before about

 tinycc generate an intermediate pcode that would make things easier
 for qcc.

 When I started tinycc-noglobals it was because I was looking at a jit
 library and found libjit very nice but its not maintained and only the

 x86 and x86_64 backends are implemented (arm is only a draft that
 doesnt work), then I started playing with it and found the

 instructions to construct jitted code a bit complicated, knowing
 tinycc I thought why complicate my life when I already know C and
 tinycc generates executable code onthefly/jit ? Then I actualized my
 virtual io on top of tinycc:mob and then started looking at the tinycc
 code in more detail, when I found global variables like ch, file,
 tok it was clear that the potential for name clashing/bugs using it
 as is would be huge.

 Thats why tinycc-noglobals came to existence, then I found that the

 backends of tinycc was not in good shape, it can compile some simple
 programs in general but when we try to compile something a bit more
 complex like fossil-scm it failed.

 Then searchin the net I found the http://landley.net/qcc/ [4] ,
 http://elinux.org/CELF_Project_Proposal/Combine_tcg_with_tcc [5] and

 looked at qemu tcg Tiny Code Generator and thought what a great
 idea !!

 I propose to try make it a reality, any volunteers ???


 Sorry I don't have much free time and I cannot work on qemu due to IP
 issues related to my work. But the idea sounds interesting. It's just a bit
 sad to use an old version of tcc as the frontend though.

 Thomas


 ___
 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] improving get_tok_str

[Domingo Alvarez Duarte]

Not at all I propose using the current tinycc for that !


On Mon, Mar 31, 2014 at 4:00 PM, Thomas Preudhomme robo...@celest.frwrote:

 Le 2014-03-31 22:50, Domingo Alvarez Duarte a écrit :

  Hello Thomas !

 What do you mean by old version of tcc there is other newer versions
 elsewhere ?


 No. I meant qcc would be tcg + old version of tcc (not the current one).

 Cheers,


 Thomas

 ___
 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] improving get_tok_str

[Domingo Alvarez Duarte]

About documentation and looking at the Tiny code generator
http://wiki.qemu.org/Documentation/TCG/backend-ops and
http://wiki.qemu.org/Documentation/TCG/frontend-ops , something like that
for the actual tinycc would be useful for new people to understand code
generation.

Cheers !


On Mon, Mar 31, 2014 at 4:46 PM, mobi phil m...@mobiphil.com wrote:

 Thomas,

 Another alternative is: I could go through the code and add comments
 in form of questions.


 Please no. A git source code repository is not a wiki. Maybe some kind of
 code review platform would be nice: you could tag specific line in the code
 and ask for comments. I'd be open to participate to such an experiment.
 Although don't expect me to set this up.


 Was not proposing to commit this into the main repo, just a very simple
 way to tag lines that probably need some more comments.
 The experts then just could do a diff and see those points, remove the
 tag and/or add comment.
 Thought this would be a very simple channel for this goal.

 Do you have any specific code review platform, that could be well
 integrated with git and a simple editor like vim?


 Can I push the result somewhere? I do not have mob access etc. Shall I
 setup my own tcc git repo?


 Everybody has mob access. That's the whole concept of mob access. But
 only pushes fix, features, etc... No questions in the code, even in a
 separate file.

 Honestly never used mob. On http://repo.or.cz/h/mob.html, *only* if you
 add a mob user and statement made me thinking that I need
 some access grant. Will read again the documentation.


 ___
 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] Valgrind Inconsistency detected by ld.so: rtld.c:

[Domingo Alvarez Duarte]

Hello Daniel !

I'm still looking at why fossil-scm compiled by tcc do not work properly
and found that now the problem is with the sqlite3 sources compiled with
tcc, in a place where we have a fossil repository database I run this:

-
#include stdio.h
#include stdarg.h
#include src/sqlite3.h

static int mydb_exists(sqlite3 *db, const char *zSql, ...){
  va_list ap;
  int rc;
  va_start(ap, zSql);
  sqlite3_stmt *pStmt;
  rc = sqlite3_prepare_v2(db, zSql, -1, pStmt, 0);
  va_end(ap);
printf(%s:%d - %d %s\n, __FILE__, __LINE__, rc, zSql);
  rc = sqlite3_step(pStmt);
printf(%s:%d - %d %s\n, __FILE__, __LINE__, rc, zSql);
  if( rc !=SQLITE_ROW ) {
rc = 0;
  }else{
rc = 1;
  }
  sqlite3_finalize(pStmt);
  return rc;
}

static const char *sql = SELECT 
  blob.rid AS blobRid, 
  uuid AS uuid, 
  datetime(event.mtime) AS timestamp, 
  coalesce(ecomment, comment) AS comment, 
  coalesce(euser, user) AS user, 
  blob.rid IN leaf AS leaf, 
  bgcolor AS bgColor, 
  event.type AS eventType, 
  (SELECT group_concat(substr(tagname,5), ', ') FROM tag, tagxref 
WHERE tagname GLOB 'sym-*' AND tag.tagid=tagxref.tagid 
  AND tagxref.rid=blob.rid AND tagxref.tagtype0) AS tags, 
  tagid AS tagid, 
  brief AS brief, 
  event.mtime AS mtime 
 FROM event CROSS JOIN blob 
WHERE blob.rid=event.objid 
 AND NOT EXISTS(SELECT 1 FROM tagxref WHERE tagid=5 AND tagtype0 AND
rid=blob.rid) ORDER BY event.mtime DESC LIMIT 20;


int main() {

sqlite3 *db;
int rc = sqlite3_open_v2(
   fossil.fossil, db,
   SQLITE_OPEN_READWRITE, NULL);
printf(%d Exists %d\n, rc, mydb_exists(db, sql));
sqlite3_close(db);
return 0;
}
-

compiling it with this script:

-
gcc -o test-query-gcc test-query.c src/sqlite3.c -ldl -lpthread
tcc -o test-query-tcc test-query.c src/sqlite3.c -ldl -lpthread
-

And get results from the test-query-gcc but no results from
 test-query-tcc, now I'll try to get more close to the problem.

Cheers !


On Sat, Mar 29, 2014 at 5:57 PM, Domingo Alvarez Duarte
mingo...@gmail.comwrote:

 Hello Daniel !

 With your commit tcc can compile and run the server but it's not all
 functional, like the timeline shows nothing.

 I'll further invetigate why and send you more details about what can be
 now.

 Thanks so much !


 On Sat, Mar 29, 2014 at 5:20 PM, Daniel Glöckner daniel...@gmx.netwrote:

 On Fri, Mar 28, 2014 at 12:27:39PM +, Domingo Alvarez Duarte wrote:
  For arm experts, it gets a segfault on translate.c:98

 Please try again with current mob.
 I fixed a bug that might be the cause for your segfault.

 Best regards,

   Daniel


 P.S.: I wonder if a better fix would be to use convert_parameter_type in
   gfunc_param_typed.

 ___
 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] Bounds mixing non malloced strings is the reason to make tests fail on linux 32bits

[Domingo Alvarez Duarte]

Thanks for your comments !


Here is a small program that shows how bounds check fails with literals
too, due to what we've been discussing do far:

#include stdlib.h
#include stdio.h

int main(int argc, char **argv)
{
printf(Size of \..\ = %d\n, strlen(..));

return 0;
}

../tcc -B.. -I.. -I.. -I../include -b -DCONFIG_LDDIR=\lib\
-DCONFIG_MULTIARCHDIR=\i386-linux-gnu\ -DTCC_TARGET_I386 -DONE_SOURCE
-run ../tcc.c -B.. -I.. -I.. -I../include -b -DCONFIG_LDDIR=\lib\
-DCONFIG_MULTIARCHDIR=\i386-linux-gnu\ -DTCC_TARGET_I386 -DONE_SOURCE
-run ../tcc.c -B.. -I.. -I.. -I../include -b -DCONFIG_LDDIR=\lib\
-DCONFIG_MULTIARCHDIR=\i386-linux-gnu\ -DTCC_TARGET_I386 -DONE_SOURCE
-run ../tcc.c -B.. -I.. -I.. -I../include -b -run bcheck-test.c
Runtime error: bad pointer in strlen()
at 0xb75037a0 __bound_strlen()
../libtcc.c:1452: by 0xb74fb232 tcc_set_lib_path() (included from ../tcc.c)
../libtcc.c:1880: by 0xb74fc1b9 tcc_parse_args() (included from ../tcc.c)
../tcc.c:355: by 0xb74fd411 main()


By the way on my linux 32 bits it always never pass make test because of
bounds check others pass fine when using make test -i:

 make test
make -C tests test 'PROGS_CROSS=x86_64-linux-gnu-tcc i386-w64-mingw32-tcc
x86_64-w64-mingw32-tcc arm-linux-fpa-tcc arm-linux-fpa-ld-tcc
arm-linux-gnu-tcc arm-linux-gnueabi-tcc c67-tcc'
make[1]: Entering directory `/home/mingo/dev/tinycc-dad/tests'
 hello-exe 
../tcc -B.. -I.. -I.. -I../include ../examples/ex1.c -o hello || (../tcc
-vv; exit 1)  ./hello
Hello World
 hello-run 
../tcc -B.. -I.. -I.. -I../include -run ../examples/ex1.c
Hello World
 libtest 
./libtcc_test lib_path=..
Hello World!
fib(32) = 2178309
add(32, 64) = 96
 test3 
../tcc -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib\
-DCONFIG_MULTIARCHDIR=\i386-linux-gnu\ -DTCC_TARGET_I386 -DONE_SOURCE
-run ../tcc.c -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib\
-DCONFIG_MULTIARCHDIR=\i386-linux-gnu\ -DTCC_TARGET_I386 -DONE_SOURCE
-run ../tcc.c -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib\
-DCONFIG_MULTIARCHDIR=\i386-linux-gnu\ -DTCC_TARGET_I386 -DONE_SOURCE
-run ../tcc.c -B.. -I.. -I.. -I../include -run tcctest.c  test.out3
Auto Test3 OK
 test1b 
../tcc -B.. -I.. -I.. -I../include -b -run tcctest.c  test.out1
--- test.ref 2014-03-30 09:47:52.834804132 +0100
+++ test.out1 2014-03-30 10:01:30.806812775 +0100
@@ -538,7 +538,7 @@
 Test C99 VLA 2 (ptrs substract): PASSED
 Test C99 VLA 3 (ptr add): PASSED
 Test C99 VLA 4 (ptr access): PASSED
-Test C99 VLA 5 (bounds checking (might be disabled)): PASSED PASSED PASSED
PASSED PASSED PASSED PASSED PASSED
+Test C99 VLA 5 (bounds checking (might be disabled)): FAILED PASSED FAILED
PASSED FAILED PASSED FAILED PASSED
 sizeof(int) = 4
 sizeof(unsigned int) = 4
 sizeof(long) = 4
make[1]: *** [test1b] Error 1
make[1]: Leaving directory `/home/mingo/dev/tinycc-dad/tests'
make: *** [test] Error 2



On Sun, Mar 30, 2014 at 4:50 AM, Thomas Preudhomme robo...@celest.frwrote:

 Le 2014-03-30 01:01, Domingo Alvarez Duarte a écrit :

  Hello all !

 I followed the code and could see that mixing strings malloced and not
 malloced by tcc is the reason for the test to fail on linux 32 bits.


 Have you tried compiling with -b switch? There is still some bugs in bound
 checking code.



 On that particular case we are mixing a string from program argv[]
 with the tcc bounds checking, the later expect all strings to have
 been malloced by __bound_malloc that adds an extra byte to the size,
 but the strings from program parameters argv[] seem to be allocated
 without __bound_malloc and then the false BAD_POINTER is raised.

 Who did this ?


 Mmmh, that's me. There was bound checking when doing *argv and that made
 the bound checking work in this case. But indeed, I didn't think about when
 accessed as array. I fail to see how it could work before. For objects
 defined in a different compilation unit, there is no way to know if it will
 be compiled by tcc or not. So either you don't do any bound checking for
 object not defined within the compilation unit you are compiling, or you do
 it on all objects but it will fail for those not compiled by tcc.

 I was trying to make at least argv and arge work as they are probably the
 most frequently encountered object comming from outside a program (I assume
 usually people compile a whole program with tcc). To make it a more general
 solution we could teach the bound checking code about all the memory region
 used by libraries and tcc. If a pointer is in program area, normal bound
 checking occurs, else if it's in a library area it just returns without
 error and if outside it returns -2 like now. I'll think about how to
 discover the mapping at runtime and see if I can implement this for 0.9.27.




 If we do the tests without compiled tcc by tcc it works fine, I
 propose to move those tests to the compiled tcc instead

Re: [Tinycc-devel] Code refactoring to remove globals phase1 done.

[Domingo Alvarez Duarte]

For the people that checked out my repository at
https://github.com/mingodad/tinycc.git I'll try explain what my virtual
io is for.

I've tried on the past achieve something like etcl did, I mean a self
contained interpreter with the ability to mix c code.

I've tried to use libtcc but it depends on auxiliary files been installed
on a specific folder and nee be distributed along side the
interpreter/embedded application.

Then I started this virtual io and with a bin2c program that allow
incorporate the auxiliary files directly inside the library/interpreter.

To test the idea and achieve a self contained tcc that doesn't depend on
auxiliary files installed elsewhere I've created a small script that does
that mk-it on my distribution, to achieve a small self contained tcc it's
best to edit config.mak and change CFLAGS=-Os and run ./mk-it the
result tcc is self contained and can be used from anywhere without any
auxiliary files/folder.

Cheers !


On Sat, Mar 29, 2014 at 7:13 PM, grischka gris...@gmx.de wrote:

 Domingo Alvarez Duarte wrote:

 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.


 For the lazy typers and in order not to go to far past 80 cpl
 I'd suggest 's1' instead of 'tcc_state' all over the place.

 Not sure whether vtop (and all that) needs to become tccgen_vtop
 etc.

 Section stuff (text_section etc.) would more logically belong
 to tccelf rather than tccgen.  (I once wanted to move those,
 and add some interfaces such as elf_new()/elf_delete(), but ...)

 C99 declarations past statement or declaration of size_t in
 user code hurts other compilers.

 Your 'virtual io' should maybe go in a 'contrib' directory, and
 have some readme explanation. (otherwise it is useless for
 other people).  Though, struct fd is NOT nice.  There are
 probably much less intrusive ways, say with 3 simple #defines
 on top and instead slightly more intelligent custom functions
 that supports int fd's).

 If any possible avoid mixing the refactoring with other fixes
 or improvements, whatever those are.

 Btw. did you use some special tools (and if yes, which) or
 just findreplace?

 --- grischka


  Thanks for your time, attention and great work !



 ___
 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] Is --enable-cross of any use in its current form?

[Domingo Alvarez Duarte]

For kick/dirty tests purposes --enable-cross is a good option when making
changes to tinycc itself.


On Sun, Mar 30, 2014 at 1:28 PM, Thomas Preudhomme robo...@celest.frwrote:

 Hi there,

 TL;DR: remove --enable-cross and use build arch != target arch to detect
 the cross-compiling case

 When packaging tinycc 0.9.27 for Debian I want to create a separate
 package with tinycc cross compilers. However, the current mechanism to
 build the cross compilers, --enable-cross in the configure switch, is not
 adapted because it builds all the cross compilers at once and thus apply
 the same configuration for all of them. This is a problem in the multiarch
 world because the library path would be different for each compiler. It
 would be include in the path i386-linux-gnu for i386, x86_64-linux-gnu for
 x86-64, arm-linux-gnueabi for arm softfloat, arm-linux-gnueabihf for ARM
 hardfloat, etc... So for arm hardfloat you'd have
 /usr/lib/arm-linux-gnueabihf then /usr/lib then /lib/arm-linux-gnueabihf,
 then /lib, then /usr/local/lib/arm-linux-gnueabihf and to finish
 /usr/local/lib.

 Right now this is detected in the native build case and you'd have to set
 it for cross-building. But since cross-building builds all compiler, this
 is not practical. Therefore I was thinking about removing --enable-cross
 and instead decide whether we are building a cross-compiler or not by
 comparing what's in $cpu with what's coming from uname -m and decide based
 on that. Agreed, I'm conflating host arch and build arch together but I'm
 not sure we support the case of build != host arch well right now anyway.

 Is there any people relying on --enable-cross? If yes we could still keep
 it and also add the detection mechanism which would allow to either build
 all cross-compilers or just one. Has anyone an objection to that?

 For information, that's one of the last of the blocker for me to start the
 call for testing of tcc 0.9.27. The other blocker is the testsuite to work
 on all arch without error (not the case on i386 right now).

 Best regards,

 Thomas

 ___
 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] improving get_tok_str

[Domingo Alvarez Duarte]

That would be nice !

I would like to see the implementation of qcc
http://lists.nongnu.org/archive/html/tinycc-devel/2011-09/txtYogaFhDvlT.txtand
any documentation will help on it, someone asked before about tinycc
generate an intermediate pcode that would make things easier for qcc.

When I started tinycc-noglobals it was because I was looking at a jit
library and found libjit very nice but it's not maintained and only the x86
and x86_64 backends are implemented (arm is only a draft that doesn't
work), then I started playing with it and found the instructions to
construct jitted code a bit complicated, knowing tinycc I thought why
complicate my life when I already know C and tinycc generates executable
code onthefly/jit ? Then I actualized my virtual io on top of tinycc:mob
and then started looking at the tinycc code in more detail, when I found
global variables like ch, file, tok it was clear that the potential for
name clashing/bugs using it as is would be huge.

That's why tinycc-noglobals came to existence, then I found that the
backends of tinycc was not in good shape, it can compile some simple
programs in general but when we try to compile something a bit more complex
like fossil-scm it failed.

Then searchin the net I found the http://landley.net/qcc/ ,
http://elinux.org/CELF_Project_Proposal/Combine_tcg_with_tcc and looked at
qemu tcg Tiny Code Generator and thought what a great idea !!

I propose to try make it a reality, any volunteers ???


On Sun, Mar 30, 2014 at 1:54 PM, mobi phil m...@mobiphil.com wrote:

 What I was suggesting was to add, if possible more comments around core
 types and the core
 design. It would be pity not to get the information from you in form of a
 NOTSURE tag if
 you are not sure about certain detail. But indeed, as you pointed out the
 balance is the keyword.

 But you are right if you do not know what a newcomer needs, you cannot
 help.

 What about a FAQ to add as a file to the repo? I will start to write
 simple questions around core
 types and basic architecture.

 greeTZ
 Mobi

 ___
 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] Improve generated .stabs to make easy to debug tinycc generated code

[Domingo Alvarez Duarte]

Hello all !

I'm trying to figure out why the fossil-scm compiled with tinycc on arm
doesn't work as expected and again with my previous experience trying to
figure out why tinycc was generating bad code on X86_64 I found that having
function names on the generated .stabs is better than nothing but when we
step through the code with gdb to find bugs it's a pain not been able to
see parameters and local variables values.

I looked at the code and found that maybe would not be so hard to add more
.stabs info in this function:
-
static void put_func_debug(TCCState* tcc_state, Sym *sym)
{
char buf[512];

/* stabs info */
/* XXX: we put here a dummy type */
snprintf(buf, sizeof(buf), %s:%c1,
 tcc_state-tccgen_funcname, sym-type.t  VT_STATIC ? 'f' :
'F');
put_stabs_r(tcc_state, buf, N_FUN, 0, tcc_state-tccpp_file-line_num,
0,
tcc_state-tccgen_cur_text_section, sym-c);
/* //gr gdb wants a line at the function */
put_stabn(tcc_state, N_SLINE, 0, tcc_state-tccpp_file-line_num, 0);
tcc_state-tccgen_last_ind = 0;
tcc_state-tccgen_last_line_num = 0;
}
-

But as we was talking on other thread not knowing how the information is
stored in the AST to use it here is sad.

Can someone with more knowledge do this or shed a light here ?

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

[Domingo Alvarez Duarte]

First of all thanks for Daniel for the fix !

I followed the code on fossil-scm with printfs on va_start/va_end using the
previous tcc stdargs implementation and it showed me that both the parent
and child do va_end on the same pointer that's why the segfault.

And as I looked on the generated code by gcc/clang/pcc all of then do not
us alloc/call all is inlined so no problem of double free.

So I'll not bother look any further on fossil-scm to find why it happens
with the old tcc stdarg implementation.

Thanks again for all of you for this great work !


On Sat, Mar 29, 2014 at 11:37 PM, Michael Matz matz@frakked.de wrote:

 Hi,


 On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:

  clang and pcc also generates inline assembly instead of call/alloc.


 Yes.  I haven't said the relevant stdarg functions have to use malloc.
 They just need to interoperate with what the ABI says (and that's passing
 by pointer).  Daniel downthread is correct in that va_list itself doesn't
 have to be a pointer, that was merely TCCs way of fulfilling the ABI
 requirements.  So he fixed it meanwhile, so I'm fine.

 The fossil-scm issue should still be investigated somewhen.  TCCs old
 implementation of stdarg was conforming, so changing it to something else
 shouldn't affect any correctly written code (meaning that I'd suspect
 either some different bug in TCC that now is merely hidden, or a bug in
 fossil-scm (perhaps in their usage of stdarg functions) that's now hidden).



 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] Tinycc failing to compile fossil-scm on ubuntu 13.10 arm

[Domingo Alvarez Duarte]

Hello all !

Trying to find why fossil-scm compiled with tinycc do not work properly on
ubuntu 13.10 arm inside a nexus5 and trying to use the debugger I've got
the messages shown bellow, on my ubuntu 12.04 X86_64 gdb works fine with
fossil-scm compiled by tinycc, it's here just in case someone can have a
clue of what's the problem.

-
mingo@localhost:~/dev/fossil$ gdb --args ./fossil server
GNU gdb (GDB) 7.6.1-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as arm-linux-gnueabihf.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/mingo/dev/fossil/fossil...done.
(gdb) set follow-fork-mode child
(gdb) b page_timeline
Breakpoint 1 at 0xade6c: file bld/timeline_.c, line 1059.
(gdb) r
Starting program: /home/mingo/dev/fossil/./fossil server

Program received signal SIGILL, Illegal instruction.
0xb6ec53c8 in ?? () from /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
(gdb) bt
#0  0xb6ec53c8 in ?? () from /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
Cannot access memory at address 0x0
#1  0xb6ec3090 in OPENSSL_cpuid_setup ()
   from /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
#2  0xb6feb028 in call_init (env=0xbefff790, argv=0xbefff784, argc=2,
l=optimized out) at dl-init.c:84
#3  call_init (l=optimized out, argc=2, argv=0xbefff784, env=0xbefff790)
at dl-init.c:34
#4  0xb6feb0a8 in _dl_init (main_map=0xb6fff958, argc=2, argv=0xbefff784,
env=0xbefff790) at dl-init.c:133
#5  0xb6fe0c62 in _dl_start_user () from /lib/ld-linux-armhf.so.3
#6  0xb6fe0c62 in _dl_start_user () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] improving get_tok_str

[Domingo Alvarez Duarte]

It's not better to have two different functions/entry points, one for when
we have/need a CValue and other without it ?


On Sat, Mar 29, 2014 at 5:26 PM, Michael Matz matz@frakked.de wrote:

 Hi,


 On Sat, 29 Mar 2014, grischka wrote:

  Thomas Preudhomme wrote:

 Le 2014-03-15 20:10, mobi phil a écrit :

 Hi,

 get_tok_str is called in several places with second parameter NULL,

 though inside members (thus dereferencing NULL) is possible.

 Probably this combination bad never happens, but would like to use
 this function to understand the code.


 Yes, it ought to be fixed. The solution would be simple:

 CValue cval;

 if (!cv) {
 cval.ull = 0;
 cv = cval;
 }


 That doesn't fix anything except that it allows adding invalid
 code more easily. ;)


 Actually it does.  get_tok_str only needs a CValue for certain tokens,
 exactly those that aren't self-describing (keywords and identifiers are,
 numbers for instance aren't).  So depending on the caller of get_tok_str
 (usually warning or error message printers) it's quite normal to simply not
 have any CValue and only a token.  It would be unreasonable to require such
 callers to pass an invented CValue.  Such invention can also be hidden
 centrally inside get_tok_str.


 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

[Domingo Alvarez Duarte]

Thanks a lot for your explanation of unions on big endian, with that in
mind I can see now that we have a bigger problem that what I thought at
first, the problem that you explained seem to not been taken in account in
several places in tinycc.

How do you propose to solve this specific problem ?


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);
}



/* store a value or an expression directly in global data or in local array */
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;
break;





On Sat, Mar 29, 2014 at 5:20 PM, Michael Matz matz@frakked.de wrote:

 Hi,


 On Fri, 28 Mar 2014, Domingo Alvarez Duarte wrote:

  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


 I see no errors on x86_64, I do see these errors on i386:

 --
 -Test C99 VLA 5 (bounds checking (might be disabled)): PASSED PASSED
 PASSED PASSED PASSED PASSED PASSED PASSED
 +Test C99 VLA 5 (bounds checking (might be disabled)): FAILED PASSED
 FAILED PASSED FAILED PASSED FAILED PASSED
 ...
 -I.. -I../include -b -run tcctest.c  test.out3
 Runtime error: bad pointer in strlen()
 at 0xf74e7f60 __bound_strlen()
 ../libtcc.c:255: by 0xf74dd261 tcc_strdup() (included from ../tcc.c)
 --

 Everything else works.

 I see these error right before your commit 4bc83ac39 (CValue clearing),
 and also with that commit, so for me it's not fixing anything.  So, again,
 please give us a testcase for the suspected bug you're trying to fix.


  And I did not create that code I only found it as is an the bug pointed


 Yes, it's pre-existing code, and yes, it _may_ contain a bug somewhere. If
 there's a bug then it is accessing the wrong union member.  Up to now the
 bug hasn't been found.


  and found this solution to be a good programming pratice.


 Well, not if it merely hides a real bug that therefore then goes unfixed.


  Now again can you explain me why zeroing CValues will produce incorrect
 results on big-endian platforms, I didn't found this anywhere !


 Sure, easy.  Given:

 union { int i; long long l;} u;

 (assume 32bit int and 64bit long long)

 Setting u.i=1 on little endian will make reading out u.l come out as 1 as
 well.  On big endian setting u.i will have set the _high_ 32 bit of u.l,
 and hence reading out u.l will come out as 1LL32.  You simply can't
 transfer values via different-sized members of unions.  That's why the real
 bug must be found and fixed.


 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] Valgrind Inconsistency detected by ld.so: rtld.c:

[Domingo Alvarez Duarte]

Hello Daniel !

With your commit tcc can compile and run the server but it's not all
functional, like the timeline shows nothing.

I'll further invetigate why and send you more details about what can be now.

Thanks so much !


On Sat, Mar 29, 2014 at 5:20 PM, Daniel Glöckner daniel...@gmx.net wrote:

 On Fri, Mar 28, 2014 at 12:27:39PM +, Domingo Alvarez Duarte wrote:
  For arm experts, it gets a segfault on translate.c:98

 Please try again with current mob.
 I fixed a bug that might be the cause for your segfault.

 Best regards,

   Daniel


 P.S.: I wonder if a better fix would be to use convert_parameter_type in
   gfunc_param_typed.

 ___
 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

[Domingo Alvarez Duarte]

Ok now I understand your point, here is the minimal program that I was
using to trace it:


int main() {
int x;
static void *label_return = lbl_return;
//printf(label_return = %p\n, label_return);
goto *label_return; // here segfault on linux X86_64 without the
memset on vset
//printf(unreachable\n);
lbl_return:
return 0;
}



On Sat, Mar 29, 2014 at 5:57 PM, Michael Matz matz@frakked.de wrote:

 Hi,


 On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:

  How do you propose to solve this specific problem ?

 
 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);
 }
 

 
 /* store a value or an expression directly in global
 data or in local array
  */
 static void init_putv(TCCState* tcc_state, CType *
 type, Section *sec, unsig
 ned 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_DA
 TA_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;
 break;
 


 There is no specific problem with the above snippets.  It's simply two
 unrelated functions, one setting cval1.i and another accessing cval2.ull.
 There is only a problem when the cval set by vset is used in init_putv in
 the VT_PTR case.  _That_ would be a problem, but from the above two
 snippets it's not clear that this happens.  That's why I asked for a
 testcase, we need to know _which_ vset call (only setting .i) leaks into
 init_putv.  E.g. such code would be okay:

 vset (type, 0, 42);
 vtop-c.ull = 42;
 ...
 init_putv called accessing above vtop.


 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

[Domingo Alvarez Duarte]

Not at all, now you also could see what I saw there and then decided for
the short path to see it working, probably you don't see the problem
because it's erratic depending on what exists on the stack at the function
call and for some reason on my machine it always have garbage there and
always the same 0xff7f .

That's why I put memset on every call that use CValue on the stack without
explicitly initialize/zero/reset it, as we know use of non initialized
variables can lead to erratic results.

Cheers !


On Sun, Mar 30, 2014 at 12:19 AM, Michael Matz matz@frakked.de wrote:

 Hi,

 On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:

  Ok now I understand your point, here is the minimal program that I was
 using
 to trace it:
 
 int main() {
 int x;
 static void *label_return = lbl_return;
 //printf(label_return = %p\n, label_return);
 goto *label_return; // here segfault on linux X86_64 without the
 memset
 on vset
 //printf(unreachable\n);
 lbl_return:
 return 0;
 }
 


 Thanks.  While it doesn't crash for me on x86-64 (with rev aa561d70, i.e.
 before your memset patch) I do see the wrong vset flowing into init_putv;
 it's unary(), case TOK_LAND, which does

 vset(s-type, VT_CONST | VT_SYM, 0);
 vtop-sym = s;
 next();
 break;

 Where s-type will be VT_PTR.  Indeed vset as it is right now cannot be
 used to initialize values of such type.  One could extend vset (together
 with vpush64 the only routine that accepts an arbitrary type but sets a
 specific CValue member) to check for the type and initialize the correct
 member.  Possibly it's better to try to get rid of as many explicit vset
 calls as possible (many of the current ones actually don't need the
 immediate value, as it's always zero, and those others that actually pass
 some offset or location seem mostly dubious in that they might incorrectly
 truncate the value while passing it to vset).  Needs some pondering ...


 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

[Domingo Alvarez Duarte]

I even thought of using a static const initialized CValue and then when
declaring CValues on the stack do this:

CValue cv = ConstInitializedCValue;

But as you've pointed out it doesn't solve the real problem of setting one
member of the union and trying to get another meber of different size.

And even thought about using macros to set/get CValues that will check for
the correct values with an assert and then forbid as a rule to use get/set
CValues directly.

Cheers !


On Sun, Mar 30, 2014 at 12:40 AM, Domingo Alvarez Duarte mingo...@gmail.com
 wrote:

 Not at all, now you also could see what I saw there and then decided for
 the short path to see it working, probably you don't see the problem
 because it's erratic depending on what exists on the stack at the function
 call and for some reason on my machine it always have garbage there and
 always the same 0xff7f .

 That's why I put memset on every call that use CValue on the stack without
 explicitly initialize/zero/reset it, as we know use of non initialized
 variables can lead to erratic results.

 Cheers !


 On Sun, Mar 30, 2014 at 12:19 AM, Michael Matz matz@frakked.dewrote:

 Hi,

 On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:

  Ok now I understand your point, here is the minimal program that I was
 using
 to trace it:
 
 int main() {
 int x;
 static void *label_return = lbl_return;
 //printf(label_return = %p\n, label_return);
 goto *label_return; // here segfault on linux X86_64 without the
 memset
 on vset
 //printf(unreachable\n);
 lbl_return:
 return 0;
 }
 


 Thanks.  While it doesn't crash for me on x86-64 (with rev aa561d70, i.e.
 before your memset patch) I do see the wrong vset flowing into init_putv;
 it's unary(), case TOK_LAND, which does

 vset(s-type, VT_CONST | VT_SYM, 0);
 vtop-sym = s;
 next();
 break;

 Where s-type will be VT_PTR.  Indeed vset as it is right now cannot be
 used to initialize values of such type.  One could extend vset (together
 with vpush64 the only routine that accepts an arbitrary type but sets a
 specific CValue member) to check for the type and initialize the correct
 member.  Possibly it's better to try to get rid of as many explicit vset
 calls as possible (many of the current ones actually don't need the
 immediate value, as it's always zero, and those others that actually pass
 some offset or location seem mostly dubious in that they might incorrectly
 truncate the value while passing it to vset).  Needs some pondering ...


 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] Valgrind Inconsistency detected by ld.so: rtld.c:

[Domingo Alvarez Duarte]

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

[Domingo Alvarez Duarte]

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] Zeroing stack variables CValue

[Domingo Alvarez Duarte]

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.

[Domingo Alvarez Duarte]

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] trying tinycc on several hundred projects (results)

[Domingo Alvarez Duarte]

Hello Austin !

We did some fixes to tinycc, some of then could be the reason for so may
failures on your tests, can you try then again with the tinycc from git to
see how it have improved ?

Thanks in advance for your time and attention !


On Wed, Mar 26, 2014 at 3:31 AM, Austin English austinengl...@gmail.comwrote:

 Howdy all,

 I was curious how well TinyCC performs on real world projects, so I
 decided to test it on my gentoo machine. I've written a small script
 (rebuild_tcc.sh, attached) that will attempt to build all currently
 installed packages with tcc. It works by testing that all installed
 packages A) use a C compiler, B) work with clang and gcc, then finally C)
 building with tcc.

 Note: I'm emerging binary packages, essentially building then discarding
 each program, so the tcc compiled binaries aren't used for compiling other
 packages.

 The first few rounds of tests help to reduce the noise ratio. For
 instance, on my system, I have 855 packages installed. Of that, only 591
 used a C compiler.

 Reducing down, that gave me a list of 473 packages that built using gcc
 and clang. Of those, after
 http://repo.or.cz/w/tinycc.git/commitdiff/ba286136bf8e48c71ffd6c2fd9ce97e64a6eeeb1,
 231 packages build with tcc, with 242 failed.

 I've attached the good/bad lists and the log from building to this email,
 in case you want to try it yourself.

 I haven't tried looking through to see what the most common failures are,
 I'll leave that for someone else (along with fixing all the bugs it found
 ;) )

 --
 -Austin

 ___
 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

[Domingo Alvarez Duarte]

Not only vtop, tok, tokc, error message was one of the bigs as well, with
this first attempt I've tried to keep the name of variable and line numbers
in a way that is more or less easy to compare before and after code
refactoring.

After doing it I realize that a better design should be done, like trapping
error and warning messages to user defined function, prefix global
functions, structures to avoid name clashes with third party
libraries/code, a better connection between code generation specific for
each platform, ...

As I said this was a first attempt and is somehow working, now the
community have one start point to decide and compare the pros  cons of a
such code change.

Cheers !


On Thu, Mar 27, 2014 at 3:44 PM, Thomas Preudhomme robo...@celest.frwrote:

 Le 2014-03-27 07:23, Domingo Alvarez Duarte a écrit :

  Again my mistake, it does pass vla tests on linux 32 bits, the bounds
 check tests fail with garbage being passed to strlen.
 On arm it also works.


 Hi Domingo,

 I took a look at your patch and although I agree there is some problems, I
 find the approach a bit intrusive. For instance, in the vset case instead
 of zeroing the cval it would be better to fix the places that read the .ull
 field when it was initialized with vset. Normally a code would check the
 type before reading .ull and any caller of vset should do the right thing
 if the type needs to use the .ull field.

 There is also get_tok_str that would require fixing as (as was pointed out
 by mobi phil) many caller of that function gives NULL as second parameter.
 It would be easily fixed with:

 CValue cval;

 if (!cv) {
 cval.ull = 0;
 cv = cval;
 }

 The only place that should be fixed is when a variable is read but not
 initialized. When the wrong field of an union is read, either another field
 should be read or another field should have been set. Also, if tcc was used
 some day to compile on a big endian system the zeroing would also lead to
 garbage being read (only on little endian does it have no impact).

 By the way, I'll try my best to take a look at your patch after the
 release. We'll then figure out how to best merge it. Maybe it's better in
 one big commit, I need to look at it first. I guess vtop, tok and tok are
 the biggest reason to have TCCState sneak in all function prototype, is
 that it?

 Best regards,

 Thomas

 ___
 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

[Domingo Alvarez Duarte]

When I found this problem and looked at how CValue is defined I saw a
potential for later new field been added changed and then I decided to
always start with generic well known state (everything zeroed) otherwise
bugs like this one that can manifest randomly depending on the garbage at
the execution time, also any usage of unitialized structs/vars can
potentially be the source of hard to find bugs.

So I do not see your suggestion as a good replacement for zeroing then
before use, and I'm not aware about the difference it will make on
little/big endian machines the fact that structures are zeroed. Are you
sure about that ?

Cheers !


On Thu, Mar 27, 2014 at 3:44 PM, Thomas Preudhomme robo...@celest.frwrote:

 Le 2014-03-27 07:23, Domingo Alvarez Duarte a écrit :

  Again my mistake, it does pass vla tests on linux 32 bits, the bounds
 check tests fail with garbage being passed to strlen.
 On arm it also works.


 Hi Domingo,

 I took a look at your patch and although I agree there is some problems, I
 find the approach a bit intrusive. For instance, in the vset case instead
 of zeroing the cval it would be better to fix the places that read the .ull
 field when it was initialized with vset. Normally a code would check the
 type before reading .ull and any caller of vset should do the right thing
 if the type needs to use the .ull field.

 There is also get_tok_str that would require fixing as (as was pointed out
 by mobi phil) many caller of that function gives NULL as second parameter.
 It would be easily fixed with:

 CValue cval;

 if (!cv) {
 cval.ull = 0;
 cv = cval;
 }

 The only place that should be fixed is when a variable is read but not
 initialized. When the wrong field of an union is read, either another field
 should be read or another field should have been set. Also, if tcc was used
 some day to compile on a big endian system the zeroing would also lead to
 garbage being read (only on little endian does it have no impact).

 By the way, I'll try my best to take a look at your patch after the
 release. We'll then figure out how to best merge it. Maybe it's better in
 one big commit, I need to look at it first. I guess vtop, tok and tok are
 the biggest reason to have TCCState sneak in all function prototype, is
 that it?

 Best regards,

 Thomas

 ___
 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] This commit causes segfaults on make test

[Domingo Alvarez Duarte]

Hello !

I can understand you because it happen to me too, then makefile on tests
was not cleaning the generated files ending with -cc and -tcc and if
we've generated ones that worked before they will be used on tests instead
of generating new ones with the modification we did to tinycc sources.

And yes I'm testing on ubuntu 12.04 X86_64.

I've added a commit to mob that do clean then, after that try make clean,
make and make test then you probably will get the segfault:

../tcc -B.. -I.. -I.. -I../include -o abitest-tcc abitest.c ../libtcc.c
-I..  -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare
-Wno-unused-result -DCONFIG_LDDIR=\lib\
-DCONFIG_MULTIARCHDIR=\x86_64-linux-gnu\ -DTCC_TARGET_X86_64
-DONE_SOURCE -lm -ldl  -I..
 abitest 
./abitest-cc lib_path=.. include=../include
ret_int_test... success
ret_longlong_test... success
ret_float_test... success
ret_double_test... success
ret_longdouble_test... success
ret_2float_test... success
ret_2double_test... success
reg_pack_test... success
reg_pack_longlong_test... success
sret_test... success
one_member_union_test... success
two_member_union_test... success
many_struct_test... success
many_struct_test_2... success
stdarg_test... success
stdarg_struct_test... success
arg_align_test... success
./abitest-tcc lib_path=.. include=../include
Segmentation fault (core dumped)
make[1]: *** [abitest] Error 139
make[1]: Leaving directory `/home/mingo/dev/c/tinycc/tests'
make: *** [test] Error 2


Cheers !



On Wed, Mar 26, 2014 at 1:54 PM, Thomas Preudhomme robo...@celest.frwrote:

 Le 2014-03-26 07:58, Domingo Alvarez Duarte a écrit :

 Hello !


 Hi there,



 This commit Support GOT32 and PLT32 reloc for same symbol
 causes make test to segfault, also tcc compiles by itself segfault.


 Unfortunetely I cannot reproduce. Before uploading I tried on i386 target
 and tried again today on x86-64 without any segfault, except a bug in
 abitest for x86-64 that I have seen for months now.

 So to debug it I'll need some help. Can you tell me which test segfaults?
 If it's the hello program (examples/ex1.c), can you run readelf -a and show
 me the output over there? Else, can you try to compile the program (instead
 of executing it with -run switch) and see if it still segfaults. If that is
 the case, can you show me the output of readelf -a on the program?

 Best regards,

 Thomas

 ___
 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] Zeroing stack variables CValue

[Domingo Alvarez Duarte]

Hello !

On my commit I posted that it solves the vla tests on linux 32bits, it was
a mistake from my part, the vla test still fail with garbage.

Probably what the comments say is happening:
/* Overwrite a VLA. This will overwrite the return address if SP is
incorrect */

Cheers !
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Zeroing stack variables CValue

[Domingo Alvarez Duarte]

Again my mistake, it does pass vla tests on linux 32 bits, the bounds check
tests fail with garbage being passed to strlen.
On arm it also works.


On Wed, Mar 26, 2014 at 8:30 PM, Domingo Alvarez Duarte
mingo...@gmail.comwrote:

 Hello !

 On my commit I posted that it solves the vla tests on linux 32bits, it was
 a mistake from my part, the vla test still fail with garbage.

 Probably what the comments say is happening:
 /* Overwrite a VLA. This will overwrite the return address if SP is
 incorrect */

 Cheers !

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] This commit causes segfaults on make test

[Domingo Alvarez Duarte]

Hello !

This commit Support GOT32 and PLT32 reloc for same symbol causes make
test to segfault, also tcc compiles by itself segfault.

Cheers !
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Tinycc without globals first try

[Domingo Alvarez Duarte]

The problem is with jump to a computed goto:
void goto_test()
{
int i;
static void *label_table[3] = { label1, label2, label3 };
...
for(i=0;i3;i++) {
goto *label_table[i];  here is the crash but on arm it works
fine ?


On Mon, Mar 24, 2014 at 12:36 AM, Domingo Alvarez Duarte mingo...@gmail.com
 wrote:

 I found a few more problems with my code refactoring and fixed then, now I
 found that the test goto_test() is the one that crash if I comment it all
 others pass.

 Testing on arm all tests pass including the goto_test(), so is something
 with the labels calculation/generation.

 I'm trying to figure out what the problem is, meanwhile if someone with
 more knowledge on tinycc can give a help it's welcome.

 Thanks again for your time and attention !



 On Sun, Mar 23, 2014 at 12:28 AM, Domingo Alvarez Duarte 
 mingo...@gmail.com wrote:

 Hello !

 I've been refactoring tinycc to remove global variables and work only
 with TCCState after several attempts I finaly got it on a initial working
 state using netbeans to do most of the refactoring work.

 Testing it on a nexus five running Ubuntu 13.10 with make test all
 tests pass

 On Ubuntu 12.04 X86_64 the tcctest.c segfault the with make test -i
 then others seem to passs

 I hosted on https://github.com/mingodad/tinycc it is a big patch because
 it adds TCCState parameter to most of the functions.

 I hope it can be accepted to be incorparated to the main the official
 repository after it stabilize, any help/sugestion are welcome.

 Thanks in advance for your time and attention !



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Tinycc without globals first try

[Domingo Alvarez Duarte]

Hello !

I've been refactoring tinycc to remove global variables and work only with
TCCState after several attempts I finaly got it on a initial working state
using netbeans to do most of the refactoring work.

Testing it on a nexus five running Ubuntu 13.10 with make test all tests
pass

On Ubuntu 12.04 X86_64 the tcctest.c segfault the with make test -i then
others seem to passs

I hosted on https://github.com/mingodad/tinycc it is a big patch because it
adds TCCState parameter to most of the functions.

I hope it can be accepted to be incorparated to the main the official
repository after it stabilize, any help/sugestion are welcome.

Thanks in advance for your time and attention !
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] test failure on Linux

[Domingo Alvarez Duarte]

Talking about crt*.o I remember having problem to link on Android.
Has someone discovered how to link on Android ?

Thanks !


On Wed, Feb 13, 2013 at 3:30 PM, arn...@skeeve.com wrote:

 Thomas Preud'homme robo...@celest.fr wrote:

  Why not but strike multiarch from that as I don't see how we could
  detect it by compiling a C program.

 Use the output of ldd to tell you where the C library is.

 HTH,

 Arnold

 ___
 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] Small patch

[Domingo Alvarez Duarte]

On Thu, Jan 31, 2013 at 12:19 PM, grischka gris...@gmx.de wrote:



  -h = elf_hash(name) % nbuckets;
 +h = name ? elf_hash(name) % nbuckets : 0;


 This is counterproductive IMO because when you read this you get
 the wrong impression that there are cases where name is NULL.
 But in fact there is no such case.  So the naive reader is misled,
 while the knowledgeable reader must conclude that the writer didn't
 know what s/he was doing.


I totally agree with you !
But look some lines above on this same function !

/* return the symbol number */
ST_FUNC int put_elf_sym(Section *s, uplong value, unsigned long size,
int info, int other, int shndx, const char *name)
{
int name_offset, sym_index;
int nbuckets, h;
ElfW(Sym) *sym;
Section *hs;

sym = section_ptr_add(s, sizeof(ElfW(Sym)));
if (name)
/ This mean
name can be null ?
name_offset = put_elf_str(s-link, name);
else
name_offset = 0;
/* XXX: endianness */
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Small patch

[Domingo Alvarez Duarte]

On Thu, Jan 31, 2013 at 12:36 PM, Thomas Preud'homme robo...@celest.frwrote:

 Le jeudi 31 janvier 2013 13:19:59, grischka a écrit :
 
-strcpy(buf, __bound_);
-strcat(buf, name);
+snprintf(buf, sizeof(buf), __bound_%s, name);
 
  There are cases where we might want to use pstrcpy instead of strcpy.
  This is no such case because __bound_memcpy cannot overflow buf[32].
  Same with
pstrcpy(buf, sizeof buf, a.out);
  Because a.out cannot overflow buf[1024].

 sprintf could be used  then to save some space

 
  --- grischka


Maybe you didn't noticed that snprintf guarantee no buffer overflow while
sprintf doesn't 
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Small patch

[Domingo Alvarez Duarte]

Hello !
I'm looking again on the reports done with Coverity Scan and found several
things one of it is this:

static void asm_expr_prod(TCCState *s1, ExprValue *pe)
{
int op;
ExprValue e2;

asm_expr_unary(s1, pe);
for(;;) {
op = tok;
if (op != '*'  op != '/'  op != '%' 
op != TOK_SHL  op != TOK_SAR)
break;
next();
asm_expr_unary(s1, e2);
if (pe-sym || e2.sym)
tcc_error(invalid operation with label);
switch(op) {
case '*':
pe-v *= e2.v;
break;
case '/':
if (e2.v == 0) {
div_error:
tcc_error(division by zero);
}
pe-v /= e2.v;
break;
case '%':
if (e2.v == 0)
goto div_error;
pe-v %= e2.v;
break;
case TOK_SHL:
pe-v = e2.v;
break;
default:
case TOK_SAR:this case
after default what does it mean ??
pe-v = e2.v;
break;
}
}
}



On Wed, Jan 30, 2013 at 11:08 PM, Ivo van Poorten ivo...@gmail.com wrote:

 Error:

 $ ./configure --cc=tcc
 Binary  directory   /usr/local/bin
 TinyCC directory/usr/local/lib/tcc
 Library directory   /usr/local/lib
 Include directory   /usr/local/include
 Manual directory/usr/local/share/man
 Info directory  /usr/local/share/info
 Doc directory   /usr/local/share/doc/tcc
 Target root prefix
 Source path  /home/ivo/git/tinycc
 C compiler   tcc
 Target OSLinux
 CPU  x86
 Big Endian   no
 gprof enabledno
 cross compilers  no
 use libgcc   no
 Creating config.mak and config.h
 $ make
 [..snip..]
 gcc -c lib/bcheck.c -o bcheck.o -I. -I/home/ivo/git/tinycc -Wall -g -O2
 -mpreferred-stack-boundary=2 -m386 -malign-functions=0 -m32 cc1: error:
 unrecognized command line option -m386


 88888888

 diff --git a/Makefile b/Makefile
 index d257464..0333ebe 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -232,7 +232,7 @@ libtcc1.a : FORCE
  lib/%/libtcc1.a : FORCE $(PROGS_CROSS)
 @$(MAKE) -C lib cross TARGET=$*
  bcheck.o : lib/bcheck.c
 -   gcc -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
 +   $(CC) -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
  FORCE:

  # install

 ___
 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] Small patch

[Domingo Alvarez Duarte]

Here is some that I found simple to make:

Author: mingodad mingo...@gmail.com  2013-01-31 01:17:50
Committer: mingodad mingo...@gmail.com  2013-01-31 01:17:50
Parent: 1b1e7ee1fd2f269872128dc5e8b830bd55dfa80c (Fix cross-compilation
out-of-tree build)
Branch: vio_patch
Follows: release_0_9_25
Precedes:

Alerts found using Coverity Scan

--- libtcc.c
---
index b0a9b1a..69d9e0d 100644
@@ -479,8 +479,7 @@ ST_FUNC void put_extern_sym2(Sym *sym, Section *section,
 case TOK_strlen:
 case TOK_strcpy:
 case TOK_alloca:
-strcpy(buf, __bound_);
-strcat(buf, name);
+snprintf(buf, sizeof(buf), __bound_%s, name);
 name = buf;
 break;
 }

--- tccelf.c
---
index a4dee19..479b2fa 100644
@@ -114,7 +114,7 @@ ST_FUNC int put_elf_sym(Section *s, uplong value,
unsigned long size,
 if (ELFW(ST_BIND)(info) != STB_LOCAL) {
 /* add another hashing entry */
 nbuckets = base[0];
-h = elf_hash(name) % nbuckets;
+h = name ? elf_hash(name) % nbuckets : 0;
 *ptr = base[2 + h];
 base[2 + h] = sym_index;
 base[1]++;
@@ -3052,7 +3052,7 @@ static int ld_add_file_list(TCCState *s1, const char
*cmd, int as_needed)
 ret = -1;
 goto lib_parse_error;
 }
-strcpy(libname, filename[1]);
+snprintf(libname, sizeof(libname), %s, filename[1]);
 libname_to_filename(s1, libname, filename);
 } else if (t != LD_TOK_NAME) {
 tcc_error_noabort(filename expected);

--- tccgen.c
---
index 4300403..e06a932 100644
@@ -361,6 +361,7 @@ void vpush64(int ty, unsigned long long v)
 CValue cval;
 CType ctype;
 ctype.t = ty;
+ctype.ref = 0;
 cval.ull = v;
 vsetc(ctype, VT_CONST, cval);
 }
@@ -1734,6 +1735,7 @@ ST_FUNC void gen_op(int op)
 }
 vswap();
 type1.t = t;
+type1.ref = 0;
 gen_cast(type1);
 vswap();
 /* special case for shifts and long long: we keep the shift as
@@ -2717,6 +2719,7 @@ static void struct_decl(CType *type, int u)
 v = anon_sym++;
 }
 type1.t = a;
+type1.ref = 0;
 /* we put an undefined size for struct/union */
 s = sym_push(v | SYM_STRUCT, type1, 0, -1);
 s-r = 0; /* default alignment is zero as gcc */
@@ -3396,6 +3399,7 @@ static void gfunc_param_typed(Sym *func, Sym *arg)
 /* default casting : only need to convert float to double */
 if ((vtop-type.t  VT_BTYPE) == VT_FLOAT) {
 type.t = VT_DOUBLE;
+type.ref = 0;
 gen_cast(type);
 }
 } else if (arg == NULL) {
@@ -3592,6 +3596,7 @@ ST_FUNC void unary(void)
 if ((vtop-r  (VT_VALMASK | VT_LVAL | VT_SYM)) == VT_CONST) {
 CType boolean;
 boolean.t = VT_BOOL;
+boolean.ref = 0;
 gen_cast(boolean);
 vtop-c.i = !vtop-c.i;
 } else if ((vtop-r  VT_VALMASK) == VT_CMP)
@@ -4101,6 +4106,7 @@ static void expr_cond(void)
 CType boolean;
 int c;
 boolean.t = VT_BOOL;
+boolean.ref = 0;
 vdup();
 gen_cast(boolean);
 c = vtop-c.i;
@@ -5574,7 +5580,7 @@ ST_FUNC void gen_inline_functions(void)
 str = fn-token_str;
 fn-sym = NULL;
 if (file)
-strcpy(file-filename, fn-filename);
+snprintf(file-filename, sizeof(file-filename), %s,
fn-filename);
 sym-r = VT_SYM | VT_CONST;
 sym-type.t = ~VT_INLINE;




On Thu, Jan 31, 2013 at 1:13 AM, Domingo Alvarez Duarte
mingo...@gmail.comwrote:

 Also on this function:

 CID 968150 (#1 of 1): Unchecked return value (CHECKED_RETURN)6.
 check_return: Calling function parse_btype(CType *, AttributeDef *)
 without checking return value (as is done elsewhere 7 out of 8 times).


 /* enum/struct/union declaration. u is either VT_ENUM or VT_STRUCT */
 static void struct_decl(CType *type, int u)
 {
 ...
 bit_pos = 0;
 offset = 0;
 while (tok != '}') {
 parse_btype(btype, ad);  no check made here
 ?
 while (1) {
 bit_size = -1;
 v = 0;
 type1 = btype;



 On Thu, Jan 31, 2013 at 1:07 AM, Domingo Alvarez Duarte 
 mingo...@gmail.com wrote:

 Also here :

 static void asm_expr_logic(TCCState *s1, ExprValue *pe)
 {
 int op;
 ExprValue e2;

 asm_expr_prod(s1, pe);

 for(;;) {
 op = tok;
 if (op != ''  op != '|'  op != '^')
 break;
 next

Re: [Tinycc-devel] Small patch

[Domingo Alvarez Duarte]

Also on this function:

CID 968150 (#1 of 1): Unchecked return value (CHECKED_RETURN)6.
check_return: Calling function parse_btype(CType *, AttributeDef *)
without checking return value (as is done elsewhere 7 out of 8 times).


/* enum/struct/union declaration. u is either VT_ENUM or VT_STRUCT */
static void struct_decl(CType *type, int u)
{
...
bit_pos = 0;
offset = 0;
while (tok != '}') {
parse_btype(btype, ad);  no check made here
?
while (1) {
bit_size = -1;
v = 0;
type1 = btype;



On Thu, Jan 31, 2013 at 1:07 AM, Domingo Alvarez Duarte
mingo...@gmail.comwrote:

 Also here :

 static void asm_expr_logic(TCCState *s1, ExprValue *pe)
 {
 int op;
 ExprValue e2;

 asm_expr_prod(s1, pe);

 for(;;) {
 op = tok;
 if (op != ''  op != '|'  op != '^')
 break;
 next();
 asm_expr_prod(s1, e2);

 if (pe-sym || e2.sym)
 tcc_error(invalid operation with label);
 switch(op) {
 case '':
 pe-v = e2.v;
 break;
 case '|':
 pe-v |= e2.v;
 break;
 default:
 case '^':  ///what this case
 after default mean 
 pe-v ^= e2.v;
 break;
 }
 }
 }



 On Thu, Jan 31, 2013 at 1:06 AM, Domingo Alvarez Duarte 
 mingo...@gmail.com wrote:

 Hello !
 I'm looking again on the reports done with Coverity Scan and found
 several things one of it is this:

 static void asm_expr_prod(TCCState *s1, ExprValue *pe)
 {
 int op;
 ExprValue e2;

 asm_expr_unary(s1, pe);
 for(;;) {
 op = tok;
 if (op != '*'  op != '/'  op != '%' 
 op != TOK_SHL  op != TOK_SAR)
 break;
 next();
 asm_expr_unary(s1, e2);
 if (pe-sym || e2.sym)
 tcc_error(invalid operation with label);
 switch(op) {
 case '*':
 pe-v *= e2.v;
 break;
 case '/':
 if (e2.v == 0) {
 div_error:
 tcc_error(division by zero);
 }
 pe-v /= e2.v;
 break;
 case '%':
 if (e2.v == 0)
 goto div_error;
 pe-v %= e2.v;
 break;
 case TOK_SHL:
 pe-v = e2.v;
 break;
 default:
 case TOK_SAR:this
 case after default what does it mean ??
 pe-v = e2.v;
 break;
 }
 }
 }



 On Wed, Jan 30, 2013 at 11:08 PM, Ivo van Poorten ivo...@gmail.comwrote:

 Error:

 $ ./configure --cc=tcc
 Binary  directory   /usr/local/bin
 TinyCC directory/usr/local/lib/tcc
 Library directory   /usr/local/lib
 Include directory   /usr/local/include
 Manual directory/usr/local/share/man
 Info directory  /usr/local/share/info
 Doc directory   /usr/local/share/doc/tcc
 Target root prefix
 Source path  /home/ivo/git/tinycc
 C compiler   tcc
 Target OSLinux
 CPU  x86
 Big Endian   no
 gprof enabledno
 cross compilers  no
 use libgcc   no
 Creating config.mak and config.h
 $ make
 [..snip..]
 gcc -c lib/bcheck.c -o bcheck.o -I. -I/home/ivo/git/tinycc -Wall -g -O2
 -mpreferred-stack-boundary=2 -m386 -malign-functions=0 -m32 cc1: error:
 unrecognized command line option -m386


 88888888

 diff --git a/Makefile b/Makefile
 index d257464..0333ebe 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -232,7 +232,7 @@ libtcc1.a : FORCE
  lib/%/libtcc1.a : FORCE $(PROGS_CROSS)
 @$(MAKE) -C lib cross TARGET=$*
  bcheck.o : lib/bcheck.c
 -   gcc -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
 +   $(CC) -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
  FORCE:

  # install

 ___
 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] Small patch

[Domingo Alvarez Duarte]

Also here :

static void asm_expr_logic(TCCState *s1, ExprValue *pe)
{
int op;
ExprValue e2;

asm_expr_prod(s1, pe);
for(;;) {
op = tok;
if (op != ''  op != '|'  op != '^')
break;
next();
asm_expr_prod(s1, e2);
if (pe-sym || e2.sym)
tcc_error(invalid operation with label);
switch(op) {
case '':
pe-v = e2.v;
break;
case '|':
pe-v |= e2.v;
break;
default:
case '^':  ///what this case
after default mean 
pe-v ^= e2.v;
break;
}
}
}



On Thu, Jan 31, 2013 at 1:06 AM, Domingo Alvarez Duarte
mingo...@gmail.comwrote:

 Hello !
 I'm looking again on the reports done with Coverity Scan and found several
 things one of it is this:

 static void asm_expr_prod(TCCState *s1, ExprValue *pe)
 {
 int op;
 ExprValue e2;

 asm_expr_unary(s1, pe);
 for(;;) {
 op = tok;
 if (op != '*'  op != '/'  op != '%' 
 op != TOK_SHL  op != TOK_SAR)
 break;
 next();
 asm_expr_unary(s1, e2);
 if (pe-sym || e2.sym)
 tcc_error(invalid operation with label);
 switch(op) {
 case '*':
 pe-v *= e2.v;
 break;
 case '/':
 if (e2.v == 0) {
 div_error:
 tcc_error(division by zero);
 }
 pe-v /= e2.v;
 break;
 case '%':
 if (e2.v == 0)
 goto div_error;
 pe-v %= e2.v;
 break;
 case TOK_SHL:
 pe-v = e2.v;
 break;
 default:
 case TOK_SAR:this case
 after default what does it mean ??
 pe-v = e2.v;
 break;
 }
 }
 }



 On Wed, Jan 30, 2013 at 11:08 PM, Ivo van Poorten ivo...@gmail.comwrote:

 Error:

 $ ./configure --cc=tcc
 Binary  directory   /usr/local/bin
 TinyCC directory/usr/local/lib/tcc
 Library directory   /usr/local/lib
 Include directory   /usr/local/include
 Manual directory/usr/local/share/man
 Info directory  /usr/local/share/info
 Doc directory   /usr/local/share/doc/tcc
 Target root prefix
 Source path  /home/ivo/git/tinycc
 C compiler   tcc
 Target OSLinux
 CPU  x86
 Big Endian   no
 gprof enabledno
 cross compilers  no
 use libgcc   no
 Creating config.mak and config.h
 $ make
 [..snip..]
 gcc -c lib/bcheck.c -o bcheck.o -I. -I/home/ivo/git/tinycc -Wall -g -O2
 -mpreferred-stack-boundary=2 -m386 -malign-functions=0 -m32 cc1: error:
 unrecognized command line option -m386


 88888888

 diff --git a/Makefile b/Makefile
 index d257464..0333ebe 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -232,7 +232,7 @@ libtcc1.a : FORCE
  lib/%/libtcc1.a : FORCE $(PROGS_CROSS)
 @$(MAKE) -C lib cross TARGET=$*
  bcheck.o : lib/bcheck.c
 -   gcc -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
 +   $(CC) -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
  FORCE:

  # install

 ___
 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] Call for testing

[Domingo Alvarez Duarte]

I didn't found a way to get a report like the one bellow using clang-build
make CC=/usr/share/clang/scan-build/ccc-analyzer.

Here we have another set of problems and anyone can install clang and run
it.

tinycc-dad-git - scan-build resultsUser:mingo@mingo-Aspire-5315
Working Directory:/home/mingo/dev/tinycc-dad-git
Command Line:make CC=/usr/share/clang/scan-build/ccc-analyzer
Date:Fri Jan 18 19:57:11 2013

Bug SummaryBug TypeQuantityDisplay?
All Bugs31
API
Argument with 'nonnull' attribute passed null1
Dead code
Idempotent operation6
Dead store
Dead assignment5
Logic error
Assigned value is garbage or undefined2
Dereference of null pointer14
Division by zero1
Result of operation is garbage or undefined2

ReportsBug GroupBug Type ▾FileLinePath Length
APIArgument with 'nonnull' attribute passed nulltcc.c367
22View ReportReport BugOpen File
Logic errorAssigned value is garbage or undefinedtccgen.c
334711View ReportReport BugOpen File
Logic errorAssigned value is garbage or undefinedi386-asm.c
92158View ReportReport BugOpen File
Dead storeDead assignmenttccgen.c1571View Report
Report BugOpen File
Dead storeDead assignmenti386-asm.c13081View Report
Report BugOpen File
Dead storeDead assignmenttccgen.c12671View Report
Report BugOpen File
Dead storeDead assignmenti386-asm.c8621View Report
Report BugOpen File
Dead storeDead assignmenti386-gen.c7871View Report
Report BugOpen File
Logic errorDereference of null pointertccpp.c276434View
ReportReport BugOpen File
Logic errorDereference of null pointertccgen.c466727
View ReportReport BugOpen File
Logic errorDereference of null pointertccgen.c485136
View ReportReport BugOpen File
Logic errorDereference of null pointertccgen.c385369
View ReportReport BugOpen File
Logic errorDereference of null pointertcc.c42922View
ReportReport BugOpen File
Logic errorDereference of null pointertccgen.c48108View
ReportReport BugOpen File
Logic errorDereference of null pointertccpp.c275033View
ReportReport BugOpen File
Logic errorDereference of null pointertccgen.c583357
View ReportReport BugOpen File
Logic errorDereference of null pointertccgen.c48347View
ReportReport BugOpen File
Logic errorDereference of null pointertccgen.c454015
View ReportReport BugOpen File
Logic errorDereference of null pointertccgen.c464326
View ReportReport BugOpen File
Logic errorDereference of null pointertccgen.c552311
View ReportReport BugOpen File
Logic errorDereference of null pointertccgen.c454717
View ReportReport BugOpen File
Logic errorDereference of null pointertccpp.c31178View
ReportReport BugOpen File
Logic errorDivision by zerotccasm.c15311View Report
Report BugOpen File
Dead codeIdempotent operationi386-asm.c5075View
ReportReport BugOpen File
Dead codeIdempotent operationi386-asm.c3575View
ReportReport BugOpen File
Dead codeIdempotent operationi386-gen.c6261View
ReportReport BugOpen File
Dead codeIdempotent operationi386-asm.c3617View
ReportReport BugOpen File
Dead codeIdempotent operationi386-gen.c6954View
ReportReport BugOpen File
Dead codeIdempotent operationi386-asm.c3596View
ReportReport BugOpen File
Logic errorResult of operation is garbage or undefinedi386-asm.c
87757View ReportReport BugOpen File
Logic errorResult of operation is garbage or undefinedi386-asm.c
81448View ReportReport BugOpen File


On Fri, Jan 18, 2013 at 6:33 PM, grischka gris...@gmx.de wrote:

 Domingo Alvarez Duarte wrote:

 Please someone here that administer this project can open a free account
 for opensource projects on http://scan.coverity.com/ and submit tinycc
 build to verify for defects, I did with my account and I've got this:

 There is much more details available about this problems on the account
 pages, if someone want to see then tell me and I can add a new user to see
 then on my account.


 Is there a way to let everyone participate?  If so I'd suggest to just
 post the details here.

 Thanks,

 --- grischka



 __**_
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/**mailman/listinfo/tinycc-develhttps://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Call for testing

[Domingo Alvarez Duarte]

Please someone here that administer this project can open a free account
for opensource projects on http://scan.coverity.com/ and submit tinycc
build to verify for defects, I did with my account and I've got this:

There is much more details available about this problems on the account
pages, if someone want to see then tell me and I can add a new user to see
then on my account.

CIDTypeImpactStatusFirst DetectedOwner
ClassificationSeverityActionComponentCategoryFile
Function
968207Uninitialized scalar variableHighNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOther
Uninitialized variables/tccgen.cvpush64
968206Uninitialized scalar variableHighNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOther
Uninitialized variables/tccgen.cunary
968205Uninitialized pointer readHighNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOtherMemory -
illegal accesses/tccgen.cstruct_decl
968204Uninitialized scalar variableHighNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOther
Uninitialized variables/tccgen.cgv
968203Uninitialized scalar variableHighNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOther
Uninitialized variables/tccgen.cgfunc_param_typed
968202Uninitialized scalar variableHighNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOther
Uninitialized variables/tccgen.cgen_op
968201Uninitialized scalar variableHighNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOther
Uninitialized variables/tccgen.cexpr_cond
968200Uninitialized scalar variableHighNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOther
Uninitialized variables/tccgen.cexpr_cond
968199Untrusted loop boundMediumNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOtherInsecure
data handling/win32/tools/tiny_libmaker.cmain
968198Untrusted loop boundMediumNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOtherInsecure
data handling/win32/tools/tiny_impdef.cget_export_names
968197Untrusted array index readMediumNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOtherInsecure
data handling/tccpp.cnext_nomacro1
968196VariousMediumNew1/17/2013Unassigned
UnclassifiedUnspecifiedUndecidedOtherInsecure data
handling/tccpe.cpe_load_res
968195VariousMediumNew1/17/2013Unassigned
UnclassifiedUnspecifiedUndecidedOtherInsecure data
handling/tccelf.ctcc_load_object_file
968194VariousMediumNew1/17/2013Unassigned
UnclassifiedUnspecifiedUndecidedOtherInsecure data
handling/tccelf.ctcc_load_dll
968193Untrusted loop boundMediumNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOtherInsecure
data handling/tccelf.ctcc_load_alacarte
968192Destination buffer too smallHighNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOtherMemory -
corruptions/tccpe.cpe_write
968191Copy into fixed size bufferLowNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOtherSecurity
best practices violations/tccpe.cpe_load_def
968190Copy into fixed size bufferLowNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOtherSecurity
best practices violations/tccpe.cpe_find_import
968189Copy into fixed size bufferLowNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOtherSecurity
best practices violations/tccpe.cpe_assign_addresses
968188Copy into fixed size bufferLowNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOtherSecurity
best practices violations/tccgen.cgen_inline_functions
968187Copy into fixed size bufferLowNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOtherSecurity
best practices violations/tccelf.cld_add_file_list
968186Copy into fixed size bufferLowNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOtherSecurity
best practices violations/libtcc.cput_extern_sym2
968185String not null terminatedHighNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOtherMemory -
illegal accesses/win32/tools/tiny_libmaker.cmain
968184String not null terminatedHighNew1/17/2013
UnassignedUnclassifiedUnspecifiedUndecidedOtherMemory -
illegal accesses/tccelf.c

Re: [Tinycc-devel] Added virtual io to tinycc

[Domingo Alvarez Duarte]

You've got the idea and the possibilities it allow.

As you can see I've tried a balance between simplicity and functionality,
and found that with a small change on int fds to struct fds I could
achieve what I was looking at first place with minimal complications.


On Mon, Jan 14, 2013 at 2:54 AM, Jared Maddox absinthdr...@gmail.comwrote:

  Date: Sat, 12 Jan 2013 23:33:48 +0100
  From: grischka gris...@gmx.de
  To: tinycc-devel@nongnu.org
  Subject: Re: [Tinycc-devel] Added virtual io to tinycc
  Message-ID: 50f1e4cc.6000...@gmx.de
  Content-Type: text/plain; charset=UTF-8; format=flowed
 
  Domingo Alvarez Duarte wrote:
  Let's see if I can explain it better.
 
  The modifications I did was replace:
  fd - fd or fd-fd depending on the context
  [...]
 
  Indeed switching tinycc to cope with struct fd was a bad decision
  to begin with.  Under any circumstances I'd recommend to switch your
  wrappers to int fd instead and thus to the same prototypes as
  the original functions.  Not a big deal, really.
 
  And the question (or suggestion, if you prefer) still is:
 
  Can you make this work with all your extra files put in a
  subdirectory
 
  contrib/choose your name
 
  and with only the most minimal required change to our existing
 files?
 
  I suppose it could be three lines such as
 
  #ifdef TCC_CONTRIB_WHATEVER
  # include contrib/whatever/some.h
  #endif
 
  or maybe even less.
 
  --- grischka
 

 I think that Domingo sees that as a problem because his modification
 doesn't currently use the same function prototypes. By switching the
 fds to ints that correspond to an element in an array or tree (I can
 donate a tree implementation if desired, though the balancing is still
 off) it should be possible to mostly use the same prototypes. However,
 there may be some reason why he's giving extra arguments to open
 (perhaps he wants to enable TCCState-level customizations), so there
 would be at least one prototype change regardless.

 Though, honestly, it should be possible to do a five line
 conventional-input converter if the int fd change goes through, so I
 think that it makes sense. The change will definitely affect all of
 the file i/o calls, but only by one added argument, and changing all
 of the struct fds to ints.



 Now on to the actual capability. Note that what I'm suggesting WOULD
 belong in something like contrib/virtual_fs/vfs.h. From my
 perspective a full file and mount system should be provided by
 anything like this. I won't say that it's zero-effort, but it isn't
 too bad either. Basically you take a virtual filesystem (I can
 describe how this sort of thing works if you need some help with it:
 I've looked at writing them before), extend it's file/folder structure
 to support overrides (thereby allowing you to mount another virtual
 filesystem at arbitrary points without un-linking the previous data
 there), and if you just don't find a file or folder then the code
 resorts to the fallback that the current virtual filesystem
 structure is configured with (which could be yet another virtual
 filesystem or a file not found error). If you want access to the
 real filesystem then you just write an appropriate wrapper and mount
 it in the right place. If you want to overlay a real or a virtual
 filesystem on each other then you decide which you prefer to get your
 files from, and set the other as the fallback. Here's an example of
 how the structures might look:

 typedef struct vfs vfs;
 typedef struct vnode vnode;

 struct vfs {
  size_t elements;
  char **names;
  vnode *nodes;
  vfs *fallback;
   /* You might try int (*node_open)( void*, const char**, int,  vfs** ),
  for a recursion-free try again style. */
  int (*node_open)( void*, const char*, int );
 };
 struct vnode {
  enum {
   vnode_file = 1,
   vnode_directory = 2
  } type;
  vfs *dirmount;
  void *nodemount_data; int (*nodemount_open)( void*, const char*, int );
  void *node_data;
 };

 The main nuisance is that searching for the right file will be slow.
 If you want speed AND flexibility, then you want to write a
 string-table implementation so that your file/folder searches go
 faster. Really, most of the complexity is in making it go faster, not
 in making it work.

 ___
 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] Added virtual io to tinycc

[Domingo Alvarez Duarte]

Let's see if I can explain it better.

The modifications I did was replace:
fd - fd or fd-fd depending on the context
fd = -1; - void vio_initialize(vio_fd *fd);
fd = open(file_name, mode) - int vio_open(struct TCCState *s, vio_fd
*fd, const char *fn, int oflag);
pos = lseek(fd, offset, whence); - off_t vio_lseek(vio_fd fd, off_t
offset, int whence);
size = read(fd, buf, count); - size_t vio_read(vio_fd fd, void *buf,
size_t bytes);
close(fd); - int vio_close(vio_fd *fd);

And add a new API function LIBTCCAPI void tcc_set_vio_module(TCCState *s,
vio_module_t *vio_module) that allow install a module that will handle the
read io operations required by tcc.

bin2c: is a utility used on one implementation of vio_module.

---
/* virtual io */

struct vio_module_t;

typedef struct vio_fd {
int fd;
void *vio_udata;
struct vio_module_t *vio_module;
} vio_fd;

#define CALL_VIO_OPEN_FIRST 0x01
#define CALL_VIO_OPEN_LAST 0x02

typedef struct vio_module_t {
void *user_data;
struct TCCState *tcc_state;
int call_vio_open_flags; /*CALL_VIO_OPEN_FIRST, CALL_VIO_OPEN_LAST, one
or both */
int (*vio_open)(vio_fd *fd, const char *fn, int oflag) ;
off_t (*vio_lseek)(vio_fd fd, off_t offset, int whence);
size_t (*vio_read)(vio_fd fd, void *buf, size_t bytes);
int (*vio_close)(vio_fd *fd);
} vio_module_t;

LIBTCCAPI void tcc_set_vio_module(TCCState *s, vio_module_t *vio_module){
s-vio_module = vio_module;
vio_module-tcc_state = s;
}

void vio_initialize(vio_fd *fd) {
fd-fd = -1;
fd-vio_udata = NULL;
fd-vio_module = NULL;
}

int vio_open(struct TCCState *s, vio_fd *fd, const char *fn, int oflag) {
int rc;
vio_initialize(fd);
fd-vio_module = s-vio_module;
if(s-vio_module  (s-vio_module-call_vio_open_flags 
CALL_VIO_OPEN_FIRST)) {
rc =  s-vio_module-vio_open(fd, fn, oflag);
if(rc = 0) return rc;
}

fd-fd = open(fn, oflag);

if(fd-fd  0  s-vio_module  (s-vio_module-call_vio_open_flags 
CALL_VIO_OPEN_LAST)) {
rc =  s-vio_module-vio_open(fd, fn, oflag);
if(rc = 0) return rc;
}
//printf(vio_open = %d %s\n, fd-fd, fn);
return fd-fd;
}

off_t vio_lseek(vio_fd fd, off_t offset, int whence) {
if(fd.vio_udata) {
return fd.vio_module-vio_lseek(fd, offset, whence);
}
return lseek(fd.fd, offset, whence);
}

size_t vio_read(vio_fd fd, void *buf, size_t bytes) {
if(fd.vio_udata) {
return fd.vio_module-vio_read(fd, buf, bytes);
}
return read(fd.fd, buf, bytes);
}

int vio_close(vio_fd *fd) {
int rc = 0;
if(fd-vio_udata){
fd-vio_module-vio_close(fd);
} else rc = close(fd-fd);
vio_initialize(fd);
return rc;
}



On Sat, Jan 12, 2013 at 4:35 PM, grischka gris...@gmx.de wrote:

 Domingo Alvarez Duarte wrote:

 Added what I call virtual io to tinycc this way we can make a monolitic
 executable or library that contains all needed to compile programs, truly
 tinycc portable.

 [...]


 I hope this will improve the utility of tinycc.
 It's on mob:repository.

 Thanks in advance for any comments suggestions !


 Can you make this work with all your extra files put in a subdirectory

 contrib/choose your name

 and with only the most minimal required change to our existing files?

 I suppose it could be three lines such as

 #ifdef TCC_CONTRIB_WHATEVER
 # include contrib/whatever/some.h
 #endif

 or maybe even less.

 --- grischka



 __**_
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/**mailman/listinfo/tinycc-develhttps://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] Added virtual io to tinycc

[Domingo Alvarez Duarte]

The idea is the same, but I think that I did it in a more general adding
the virtual io to tinycc with any source can be easily used like databases,
compressed files,

Main code of vio:

/* virtual io */

LIBTCCAPI void tcc_set_vio_module(TCCState *s, vio_module_t *vio_module){
s-vio_module = vio_module;
vio_module-tcc_state = s;
}

void vio_initialize(vio_fd *fd) {
fd-fd = -1;
fd-vio_udata = NULL;
fd-vio_module = NULL;
}

int vio_open(struct TCCState *s, vio_fd *fd, const char *fn, int oflag) {
int rc;
vio_initialize(fd);
fd-vio_module = s-vio_module;
if(s-vio_module  (s-vio_module-call_vio_open_flags 
CALL_VIO_OPEN_FIRST)) {
rc =  s-vio_module-vio_open(fd, fn, oflag);
if(rc = 0) return rc;
}

fd-fd = open(fn, oflag);

if(fd-fd  0  s-vio_module  (s-vio_module-call_vio_open_flags 
CALL_VIO_OPEN_LAST)) {
rc =  s-vio_module-vio_open(fd, fn, oflag);
if(rc = 0) return rc;
}
//printf(vio_open = %d %s\n, fd-fd, fn);
return fd-fd;
}

off_t vio_lseek(vio_fd fd, off_t offset, int whence) {
if(fd.vio_udata) {
return fd.vio_module-vio_lseek(fd, offset, whence);
}
return lseek(fd.fd, offset, whence);
}

size_t vio_read(vio_fd fd, void *buf, size_t bytes) {
if(fd.vio_udata) {
return fd.vio_module-vio_read(fd, buf, bytes);
}
return read(fd.fd, buf, bytes);
}

int vio_close(vio_fd *fd) {
int rc = 0;
if(fd-vio_udata){
fd-vio_module-vio_close(fd);
} else rc = close(fd-fd);
vio_initialize(fd);
return rc;
}



On Fri, Jan 11, 2013 at 7:28 AM, u-tcc-u...@aetey.se wrote:

 Hello Domingo,

 On Fri, Jan 11, 2013 at 12:23:35AM +, Domingo Alvarez Duarte wrote:
  Added what I call virtual io to tinycc this way we can make a monolitic
  executable or library that contains all needed to compile programs, truly
  tinycc portable.
  Tested under linux exec the mk-it shell script and you'll end up
 with
  a portable tinycc executable that doesn't depend on anything else.

 Is it like

 http://ptspts.blogspot.se/2009/11/tiny-self-contained-c-compiler-using.html
 ?

 Hope you did it in a more general fashion. (I have no time slices now
 to look at/test you code, sorry).

 I always felt that such a thing should belong to tcc upstream, thanks for
 doing this.

  The idea is inspired by what http://www.evolane.com/software/etcl/ did,
  make a no dependency tinycc library that can be added to a project and
 work
  without need extra files or paths for basic c compilation.

 I am not a fan of including everything in an application package, I
 prefer global file systems when you always have at hand those parts
 which you _need_ but not have to keep with you all the parts you _might_
 need.

 Anyway, having a single executable which does all the job is sometimes
 very handy and tcc looks like a very suitable target.

 Cheers,
 Rl


 ___
 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] Added virtual io to tinycc

[Domingo Alvarez Duarte]

Added what I call virtual io to tinycc this way we can make a monolitic
executable or library that contains all needed to compile programs, truly
tinycc portable.
Tested under linux exec the mk-it shell script and you'll end up with
a portable tinycc executable that doesn't depend on anything else.

The idea is inspired by what http://www.evolane.com/software/etcl/ did,
make a no dependency tinycc library that can be added to a project and work
without need extra files or paths for basic c compilation.

All calls to open/read files are replaced by  a wrapper that checks on the
files included by the bin2c utility and if not found the go elsewhere.

At first no other changes on code was done.

I hope this will improve the utility of tinycc.
It's on mob:repository.

Thanks in advance for any comments suggestions !
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel