Lee Duhem | 25 Nov 17:04 2014
Picon

Is it still OK to push to mob directly?

Hi,

I made a few modifications to the tinycc sources that I thought others
may also want.

Should I push my commits to mob directly? (Is that still possible?) Or
should I post my
patches in this list?

Sincerely,
lee

apokalipsis028 | 24 Nov 08:29 2014
Picon

help with setlocale

Hi all!
Please tell me how to output the console in Russian.
SetLocale (LC_ALL, "Russian_Russia.1251");
Non-performing.

Carlos Montiers | 23 Nov 03:41 2014
Picon

__getmainargs compatibility checking success

Hello.
I modified again the crt1.c for check the success of the function __getmainargs

I investigate this function and I learn some things.

The current protoype is:
int __cdecl __getmainargs (int *pargc, char ***pargv, char ***penvp, int dowildcard, _startupinfo * startinfo)


and is for the version of msvcrt.dll version 7.0 that is present in windows xp

But I found that in the version 6.0 of that dll that is present in windows 98 the prototype was:
void __cdecl __getmainargs (int *pargc, char ***pargv, char ***penvp, int dowildcard, _startupinfo * startinfo)

I get the sources of both from the cd of visual studio 98 and visual studio 2010.

And reading the code and with test I found that the possible result of the function in:
v6.0 are: success or program termination with error code 255 calling function _amsg_exit because not memory available.
v7.0 success (returning 0) or return -1 or program termination with -1 calling function ExitProcess because not memory available. The difference in this last is if the dll was compiled with _SYSCRT definition. I do the test and in windows 7 and 8, and both on no memory available, end the program with -1 (using ExitProcess) but on windows xp, the function return -1.

In the 7.0 version after the error checking, argc and argv are assigned.

Thus, for compatibility with version 6.0 and 7.0 of __getmainargs I check the success of the function, assign NULL to argv, and after the call to the function check if argv is not NULL, because if the function not terminates ending the program, it assign a value to argv. I do test and if the function return -1 (win xp) it not assign a value to argv. Because this I initialize argv to NULL.

Initializing argv to NULL, call __getmainargs and check if argv is NULL is a valid way of check the success of the function, because argv always will point to a address different than 0 (NULL), pointing at least to the the command with which the program is invoked.

I compiled with tcc (without using TRY and the code of SEH) and run succesfully with this crt a program on windows 98.

I use this portion of code for full the heap and cause the failure of __getmainargs :
UINT cant = 1000000;
BYTE *p;
//Alert: fulling heap
while (cant > 1) {
    p = (BYTE *) malloc(cant);
    if (!p) {
        cant /= 2;
    }
}

And this is the portion of code with the call to __getmainargs and checking the success that works on windows 98 and windows xp and above :

argv = NULL;
__getmainargs(&argc, &argv, &env, 0, &start_info);
// check success comparing if argv now is not NULL
if (! argv)
{
    ExitProcess(-1);
}


Also, I found that in the comments of __getmainargs that it left _pgmptr pointing to the program name.
This is because it internally call to GetModuleFileName

Inside the main function you can use this (after success call to __getmainargs).
printf("The full path of the executing program is: %Fs\n", _pgmptr);

This works on both version 6.0 and 7.0 (I tested it on windows 98 and windows 8)

Note the files that have the source code of the functions are:
crtlib.c // __getmainargs
stdargv.c // _setargv (function used by __getmainargs)

With this way you can sure of the success of the function __getmainargs.


Carlos.
<div><div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Hello.<br>
</div>I modified again the crt1.c for check the success of the function __getmainargs<br><br>
</div>I investigate this function and I learn some things.<br><br>
</div>The current protoype is:<br>int __cdecl __getmainargs (int *pargc, char ***pargv, char ***penvp, int dowildcard, _startupinfo * startinfo)<br><br><br>
</div>and is for the version of msvcrt.dll version 7.0 that is present in windows xp<br><br>
</div>But I found that in the version 6.0 of that dll that is present in windows 98 the prototype was:<br>void __cdecl __getmainargs (int *pargc, char ***pargv, char ***penvp, int dowildcard, _startupinfo * startinfo)<br><br>
</div>I get the sources of both from the cd of visual studio 98 and visual studio 2010.<br><br>
</div>And reading the code and with test I found that the possible result of the function in:<br>
</div>v6.0 are: success or program termination with error code 255 calling function _amsg_exit because not memory available.<br>
</div>v7.0 success (returning 0) or return -1 or program termination with -1 calling function ExitProcess because not memory available. The difference in this last is if the dll was compiled with _SYSCRT definition. I do the test and in windows 7 and 8, and both on no memory available, end the program with -1 (using ExitProcess) but on windows xp, the function return -1.<br><br>
</div>
<div>In the 7.0 version after the error checking, argc and argv are assigned.<br>
</div>
<div><br></div>Thus, for compatibility with version 6.0 and 7.0 of __getmainargs I check the success of the function, assign NULL to argv, and after the call to the function check if argv is not NULL, because if the function not terminates ending the program, it assign a value to argv. I do test and if the function return -1 (win xp) it not assign a value to argv. Because this I initialize argv to NULL.<br><br>
</div>Initializing argv to NULL, call __getmainargs and check if argv is NULL is a valid way of check the success of the function, because argv always will point to a address different than 0 (NULL), pointing at least to the the command with which the program is invoked.<br><br>
</div>I compiled with tcc (without using TRY and the code of SEH) and run succesfully with this crt a program on windows 98.<br><br>
</div>I use this portion of code for full the heap and cause the failure of __getmainargs :<br>UINT cant = 1000000;<br>BYTE *p;<br>//Alert: fulling heap<br>while (cant &gt; 1) {<br>&nbsp;&nbsp;&nbsp; p = (BYTE *) malloc(cant);<br>&nbsp;&nbsp;&nbsp; if (!p) {<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; cant /= 2;<br>&nbsp;&nbsp;&nbsp; }<br>}<br><br>
</div>And this is the portion of code with the call to __getmainargs and checking the success that works on windows 98 and windows xp and above :<br><br>argv = NULL;<br>__getmainargs(&amp;argc, &amp;argv, &amp;env, 0, &amp;start_info);<br>// check success comparing if argv now is not NULL<br>if (! argv)<br>{<br>&nbsp;&nbsp;&nbsp; ExitProcess(-1);<br>}<br><div><br></div>
<div><br></div>
<div>Also, I found that in the comments of __getmainargs that it left _pgmptr pointing to the program name.<br>This is because it internally call to GetModuleFileName<br><br>
</div>
<div>Inside the main function you can use this (after success call to __getmainargs).<br>printf("The full path of the executing program is: %Fs\n", _pgmptr);<br>
</div>
<div>
<br>This works on both version 6.0 and 7.0 (I tested it on windows 98 and windows 8)<br><br>
</div>
<div>Note the files that have the source code of the functions are:<br>crtlib.c // __getmainargs<br>stdargv.c // _setargv (function used by __getmainargs)<br><br>
</div>
<div>With this way you can sure of the success of the function __getmainargs.<br><br><br>
</div>
<div>Carlos.<br>
</div>
</div></div>
Carlos Montiers | 21 Nov 21:53 2014
Picon

tiny c executable will run on windows 98, getmainargs ?

Hello. The executables compiled with tiny c should run on windows 98?.

I ask this, because, windows 98 use msvcrt.dll v6.0 and is different than msvcrt.dll v7.0

For example, the sources for the crt for __getmainargs function

in the visual studio 98 (v6.0) prototype is:
_CRTIMP void __cdecl __wgetmainargs
and in visual studio 2010 (v7.0) the prototype is:
_CRTIMP int __cdecl __wgetmainargs

v6.0 says:
Exit: No return value. Values for the arguments to main() are copied through the passed pointers.
And in the function _setargv (that call):
Exceptions: Terminates with out of memory error if no memory to allocate.

v7.0 says:
Exit: Returns 0 on success, negative if _*setargv returns an error. Values for the arguments to main() are copied through the passed pointers.

Because this, I think if we want compatibility with this two versions of msvcrt.dll we cannot use the return value for check success, because v6.0 return void.

I propose this way for check the success of the function:

    argv = NULL;
    __getmainargs(&argc, &argv, &env, 0, &start_info);
    // check success of __getmainargs comparing argv with NULL
    if (! argv) {
        ExitProcess(-1);
    }

Some comments about this?

Tiny c executables should run on windows 98 ?


Carlos


<div><div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Hello. The executables compiled with tiny c should run on windows 98?.<br><br>
</div>I ask this, because, windows 98 use msvcrt.dll v6.0 and is different than msvcrt.dll v7.0 <br><br>For example, the sources for the crt for __getmainargs function<br><br>
</div>in the visual studio 98 (v6.0) prototype is:<br>_CRTIMP void __cdecl __wgetmainargs<br>
</div>and in visual studio 2010 (v7.0) the prototype is:<br>_CRTIMP int __cdecl __wgetmainargs<br><br>
</div>v6.0 says:<br>Exit: No return value. Values for the arguments to main() are copied through the passed pointers.<br>
</div>And in the function _setargv (that call):<br>Exceptions: Terminates with out of memory error if no memory to allocate.<br><br>
</div>v7.0 says:<br>Exit: Returns 0 on success, negative if _*setargv returns an error. Values for the arguments to main() are copied through the passed pointers.<br><br>
</div>Because this, I think if we want compatibility with this two versions of msvcrt.dll we cannot use the return value for check success, because v6.0 return void.<br><br>
</div>I propose this way for check the success of the function:<br><br>&nbsp;&nbsp;&nbsp; argv = NULL;<br>&nbsp;&nbsp;&nbsp; __getmainargs(&amp;argc, &amp;argv, &amp;env, 0, &amp;start_info);<br>&nbsp;&nbsp;&nbsp; // check success of __getmainargs comparing argv with NULL<br>&nbsp;&nbsp;&nbsp; if (! argv) {<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ExitProcess(-1);<br>&nbsp;&nbsp;&nbsp; }<br><div><div><div>
<div><br></div>
<div>Some comments about this?<br><br>
</div>
<div>Tiny c executables should run on windows 98 ?<br><br><br>
</div>
<div>Carlos<br>
</div>
<div><div><div>
<br><br>
</div></div></div>
</div></div></div>
</div></div>
David Mertens | 5 Nov 23:16 2014
Picon

FreeBSD compilation issues

Hey everyone,

I've had a bug filed against the tcc built using my Perl Alien::TinyCC package. The poster claims that tcc cannot build viable executables on FreeBSD. I'm not a FreeBSD user and wouldn't know where to start, but I thought that tcc was supposed to build a viable executable on BSDs.

BTW, the current version of tinycc distributed with Alien::TinyCC is a bit out of date. I tried to update it a few months ago and the update broke things, so I'm sticking with an older version. When I have some time, I'll bring it back up to speed.

Does anybody care to work on this?

David

P. S. I've had tests against my package on MidnightBSD. My own patches indicate that we can get support for this system by adding a case for MidnightBSD that looks identical to the other BSD configurations in the vicinity of line 50 of the configure script.

--
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
<div><div dir="ltr">
<div>
<div>
<div>
<div>Hey everyone,<br><br>
</div>I've had <a href="https://github.com/run4flat/Alien-TinyCC/issues/8">a bug filed against the tcc built using my Perl Alien::TinyCC package</a>. The poster claims that tcc cannot build viable executables on FreeBSD. I'm not a FreeBSD user and wouldn't know where to start, but I thought that tcc was supposed to build a viable executable on BSDs.<br><br>
</div>BTW, the current version of tinycc distributed with Alien::TinyCC is a bit out of date. I tried to update it a few months ago and the update broke things, so I'm sticking with an older version. When I have some time, I'll bring it back up to speed.<br><br>
</div>
<div>Does anybody care to work on this?<br>
</div>
<div><br></div>David<br><br>
</div>P. S. I've had tests against my package on MidnightBSD. My own patches indicate that we can get support for this system by adding a case for MidnightBSD that looks identical to the other BSD configurations in the vicinity of line 50 of the configure script.<br clear="all"><div><div><div><div><div>
<br>-- <br><div class="gmail_signature">&nbsp;"Debugging is twice as hard as writing the code in the first place.<br>
 &nbsp; Therefore, if you write the code as cleverly as possible, you are,<br>
 &nbsp; by definition, not smart enough to debug it." -- Brian Kernighan<br>
</div>
</div></div></div></div></div>
</div></div>
James Buren | 3 Nov 23:34 2014

libtcc.dll on win32 issues

If this library is dynamically loaded when compiled with recent MinGW environments, it causes the host
process to crash when it exits. It seems to happen with any dll compiled with gcc if libgcc.so is linked to it
dynamically. The only known workaround I know of is to link with the -static-libgcc flag. I'm not sure how
this should be patched into the build environment if I were to try to send this to upstream. Thoughts?

James Buren | 3 Nov 23:24 2014

win32 fix implicit warning patch

I pushed a patch to the mob branch, as per the instructions. It fixes an implicit warning for 'ExitProcess'
usage in one of the win32 source files. See here:

http://repo.or.cz/w/tinycc.git/commit/1e07ea71d3f564beb7f71dd868499eef996ffbae

Please look into merging it with themaster branch. Thank you.

James Buren | 2 Nov 23:09 2014

libtcc memory leak

When using tcc_compile_string() to compile a simple function, I have found a memory leak that was reported
by valgrind. It appears to be allocated at line 5972 in function decl0 in the file tccgen.c. It appears to
happen after tcc_strdup() is called and the loop containing the asm_label variable ends, either via a
break or return statement. The pointer appears to be lost, thus leaking the memory allocated by tcc_strdup().

Here is my valgrind output:
==6286== Memcheck, a memory error detector
==6286== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==6286== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==6286== Command: ./test
==6286== Parent PID: 3345
==6286==
==6286==
==6286== HEAP SUMMARY:
==6286==     in use at exit: 97 bytes in 6 blocks
==6286==   total heap usage: 3,199 allocs, 3,193 frees, 822,391 bytes allocated
==6286==
==6286== 97 bytes in 6 blocks are definitely lost in loss record 1 of 1
==6286==    at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==6286==    by 0x40199F: tcc_malloc (libtcc.c:215)
==6286==    by 0x401A6B: tcc_strdup (libtcc.c:255)
==6286==    by 0x41639E: decl0 (tccgen.c:5972)
==6286==    by 0x416A38: decl (tccgen.c:6162)
==6286==    by 0x402D4A: tcc_compile (libtcc.c:791)
==6286==    by 0x402EA1: tcc_compile_string (libtcc.c:825)
==6286==    by 0x401755: main (in /home/ryuo/ndisapi/test)
==6286==
==6286== LEAK SUMMARY:
==6286==    definitely lost: 97 bytes in 6 blocks
==6286==    indirectly lost: 0 bytes in 0 blocks
==6286==      possibly lost: 0 bytes in 0 blocks
==6286==    still reachable: 0 bytes in 0 blocks
==6286==         suppressed: 0 bytes in 0 blocks
==6286==
==6286== For counts of detected and suppressed errors, rerun with: -v
==6286== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

I would fix it myself, but I am not familiar with the innards well enough to propose a viable patch. Thank you.

Feng Nauh | 24 Oct 06:20 2014
Picon

win64: stdarg va_start and va_arg fails

Self-compiled tcc output error like this on win64:
tcc -c file-not-exits.c
tcc: error: file 'file '%s' not found' not found

The output backtrace:
  libtcc.c:626: tcc_error
    libtcc.c:569: error1
      libtcc.c:561: strcat_printf
        libtcc.c:564: va_start(ap, fmt);
It seems ap get wrong address of fmt.

In stdarg.h:
#else /* _WIN64 */
typedef char *va_list;
#define va_start(ap,last) __builtin_va_start(ap,last)
#define va_arg(ap,type) (ap += 8, sizeof(type)<=8 ? *(type*)ap : **(type**)ap)

I notice va_arg not like the one in Windows SDK:
#define _crt_va_arg(ap, t)   \
    ( ( sizeof(t) > sizeof(__int64) || ( sizeof(t) & (sizeof(t) - 1) ) != 0 ) \
        ? **(t **)( ( ap += sizeof(__int64) ) - sizeof(__int64) ) \
        :  *(t  *)( ( ap += sizeof(__int64) ) - sizeof(__int64) ) )
It has 8 bytes offset.

Patch followed:
diff --git a/include/stdarg.h b/include/stdarg.h
index 5aa9d57..23f820f 100644
--- a/include/stdarg.h
+++ b/include/stdarg.h
<at> <at> -29,8 +29,8 <at> <at> void *__va_arg(__va_list_struct *ap, int arg_type, int size, int align);
 
 #else /* _WIN64 */
 typedef char *va_list;
-#define va_start(ap,last) __builtin_va_start(ap,last)
-#define va_arg(ap,type) (ap += 8, sizeof(type)<=8 ? *(type*)ap : **(type**)ap)
+#define va_start(ap,last) (__builtin_va_start(ap,last), ap += 8)
+#define va_arg(ap,type) (ap += 8, (sizeof(type)>8 || (sizeof(type)&(sizeof(type)-1))!=0) ? **(type**)(ap-8) : *(type*)(ap-8))
 #define va_copy(dest, src) ((dest) = (src))
 #define va_end(ap)
 #endif

Or someone can fix __builtin_va_start.

tests/abitest.c also works.

This problem does not happened with x86_64-w64-mingw-tcc or tcc-win32.
<div><div dir="ltr">
<div>Self-compiled tcc output error like this on win64:</div>
<div>tcc -c file-not-exits.c</div>
<div>tcc: error: file 'file '%s' not found' not found</div>
<div><br></div>
<div>The output backtrace:</div>
<div>&nbsp; libtcc.c:626: tcc_error</div>
<div>&nbsp;&nbsp;&nbsp; libtcc.c:569: error1</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; libtcc.c:561: strcat_printf</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; libtcc.c:564:&nbsp;va_start(ap, fmt);</div>
<div>It seems ap get wrong address of fmt.</div>
<div><br></div>
<div>In stdarg.h:</div>
<div>#else /* _WIN64 */<br>typedef char *va_list;<br>#define va_start(ap,last) __builtin_va_start(ap,last)<br>#define va_arg(ap,type) (ap += 8, sizeof(type)&lt;=8 ? *(type*)ap : **(type**)ap)</div>
<div><br></div>
<div>I notice va_arg not like the one in Windows SDK:</div>
<div>#define _crt_va_arg(ap, t)&nbsp;&nbsp; \<br>&nbsp;&nbsp;&nbsp; ( ( sizeof(t) &gt; sizeof(__int64) || ( sizeof(t) &amp; (sizeof(t) - 1) ) != 0 ) \<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ? **(t **)( ( ap += sizeof(__int64) ) - sizeof(__int64) ) \<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp; *(t&nbsp; *)( ( ap += sizeof(__int64) ) - sizeof(__int64) ) )<br>It has&nbsp;8 bytes offset.</div>
<div><br></div>
<div>Patch followed:</div>
<div>diff --git a/include/stdarg.h b/include/stdarg.h<br>index 5aa9d57..23f820f 100644<br>--- a/include/stdarg.h<br>+++ b/include/stdarg.h<br> <at>  <at>  -29,8 +29,8  <at>  <at>  void *__va_arg(__va_list_struct *ap, int arg_type, int size, int align);<br>&nbsp;<br>&nbsp;#else /* _WIN64 */<br>&nbsp;typedef char *va_list;<br>-#define va_start(ap,last) __builtin_va_start(ap,last)<br>-#define va_arg(ap,type) (ap += 8, sizeof(type)&lt;=8 ? *(type*)ap : **(type**)ap)<br>+#define va_start(ap,last) (__builtin_va_start(ap,last), ap += 8)<br>+#define va_arg(ap,type) (ap += 8, (sizeof(type)&gt;8 || (sizeof(type)&amp;(sizeof(type)-1))!=0) ? **(type**)(ap-8) : *(type*)(ap-8))<br>&nbsp;#define va_copy(dest, src) ((dest) = (src))<br>&nbsp;#define va_end(ap)<br>&nbsp;#endif<br><br>Or someone can fix __builtin_va_start.</div>
<p>tests/abitest.c also works.</p>
<div>This problem&nbsp;does not happened with x86_64-w64-mingw-tcc or tcc-win32.<br>
</div>
</div></div>
Picon

tcc as jit-compiler

hi all,
I would try to play with tcc as jit compiler
in a program working with win32 gui
and implementing a scripting language.

Something like a microscopic emacs,
where elisp functions are replaced by C compiled code.
tcc should compile and (most important) re-compile user-functions
in a quite large number and number of times.
(Probably C code coompiled by tcc will be the translation of an hl 
script lang).

Playing with the examples for tcclib it sounds promising to me,
but I just can't figure out which kind of problems will issue a massive
use of JIT compilation over the same execution session.

I'll appreciate any suggestions (...even "Emacs? forget it...").

best regards
paolo

Jared Maddox | 2 Oct 12:53 2014
Picon

Re: Tinycc-devel Digest, Vol 138, Issue 1

> Date: Wed, 01 Oct 2014 01:27:09 +0200
> From: JFC Morfin <jefsey@...>
> To: tinycc-devel@...
> Subject: Re: [Tinycc-devel] How to use char "\"
> Message-ID: <E1XZ6p5-00042o-QF@...>
> Content-Type: text/plain; charset="iso-8859-1"; format=flowed
>

> btw, would you know a clean and clear uptodate C
> documentation including internetworking tools?
>

To the best of my knowledge there aren't any STANDARD tools that
provide networking, but most networking systems are derived in one
sense or another from the Berkley Unix version. Common link:
http://beej.us/guide/bgnet/
Apple might be an exception.

You should be able to find a abstraction library.


Gmane