Re: [Tinycc-devel] Creating a debugger for my own language, in TinyCC?
If debugger information is available (I simply don't recall) then you
could open that particular section (note that every OS has a different
procedure for this) and parse it for the info that you want.
Otherwise, TinyCC doesn't currently support anything noteworthy on this
subject.
I was hoping for something like this... OK let's assume a function like this:
void Func (int* a, int* b) {
int c = 2 + a[0];
if (a==b) {
int e = c * b[0];
a[0] = e;
}
int d = a[0] + b[0];
return d + 1;
}
So... Some kind of Debug info to say this:
DEBUG INFO: Func
a 0 0
b 4 0
c 8 10 20
e 12 16 10
d 12 20 4
Something really simple like that.
For example if you read c, it means:
'For the function called func '...
There exists a variable on the stack... named c that relative to the
function's stack pointer... is 8 bytes ahead.
And... it is fully initialised when the program counter is 10 bytes
into the function's code.
And... it exists for 20 bytes length of program counter space.
You'll notice the params a b, exist at 0 bytes into the function's code
(I don't know if that's true but that's what I guessed.)
Also that e and d use the same register offset... because e's scope
actually ends, so it's position is re-used for d.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] pp should interpret #num as #line num
v2 of the patch, which uses strtoul() insteed of the parse_number() 2015-01-04 10:55 GMT+03:00, Sergey Korshunoff sey...@gmail.com: But after testing: if else removed then tcc can not handle a #line directive.And with first patch tcc process rigth all forms: # line XXX file_name # XXX file_name 2015-01-04 10:43 GMT+03:00, Sergey Korshunoff sey...@gmail.com: Yes, It looks like else is not needed when processing # line XXX filename We must only get a next token and parse it as number. 2015-01-04 0:36 GMT+03:00, Thomas Preudomme robo...@celest.fr: Le samedi 27 décembre 2014, 15:29:53 Sergey Korshunoff a écrit : A preprocessor should Interpret an input line # NUM FILENAME like #line NUM FILENAME A cpp from gcc do this. A test case: tcc -E tccasm.c -o tccasm.i tcc -E tccasm.i -o tccasm.ii After a patch the line numbers in tccasm.ii are the same as in tccasm.i @@ -1624,7 +1627,11 @@ } break; case TOK_LINE: -next(); +case TOK_PPNUM: + if (tok == TOK_LINE) + next(); + else + parse_number((char *)tokc.cstr-data); if (tok != TOK_CINT) tcc_error(#line); file-line_num = tokc.i - 1; /* the line number will be incremented after */ There is already all the logic to parse the line number after the next (obviously since otherwise TOK_LINE parsing would not be working). So I don't think there is any else statement needed. If you think parse_number is more appropriate than the current adhoc parsing please justify *and* use it for both cases. Best regards, Thomas 2014-12-27-01-pp-num-as-line-1.patch Description: Binary data ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] cpu detection
cpu detection, v3
* don't setup a cpu before scanning for --cpu=
* if cpu= and ARCH != then cpu=$ARCH else cpu=`uname -m`
* if cpu=x86-64 and sizeof(size_t) = 4 then cpu=x86
sizeof(size_t) is 8 inside a Windows 64 and inside a 64bit userland Linux.
sizeof(size_t) is 4 inside a 32bit userland Linux.
2015-01-06 9:01 GMT+03:00, Christian Jullien eli...@orange.fr:
Even on Windows x64 using x64 cl version, long is 4 bytes! This is by design
to 'ease' porting from x86 to x64.
#include stdio.h
int
main()
{
printf(%d\n, sizeof(long));
}
Using Microsoft (R) C/C++ Optimizing Compiler Version 18.00.30723 for x64
= 4
size_t gives a better result
#include stdio.h
int
main()
{
printf(%d\n, sizeof(size_t));
}
= 8 with x64
= 4 with x86
Christian
-Original Message-
From: tinycc-devel-bounces+eligis=orange...@nongnu.org
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of
Sergey Korshunoff
Sent: lundi 5 janvier 2015 20:08
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] [PATCH] cpu detection
Why? A main change of this patch is:
if (cpu=x86_64 sizeof(long)==4)
set cpu=x86
What wrong with this on Windows?
2015-01-05 20:08 GMT+03:00, Michael B. Smith
mich...@theessentialexchange.com:
I'm pretty sure this breaks Windows support.
-Original Message-
From: tinycc-devel-bounces+michael=theessentialexchange@nongnu.org
[mailto:tinycc-devel-bounces+michael=theessentialexchange.com@nongnu.o
rg] On Behalf Of Sergey Korshunoff
Sent: Monday, January 5, 2015 11:51 AM
To: Thomas Preud'homme
Cc: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] [PATCH] cpu detection
cpu detection v2
* don't setup a cpu before scanning for --cpu=
* if cpu= then
if ARCH != then cpu=$ARCH else cpu=`uname -m`
* if cpu=x86-64 and sizeof(long) = 4 then cpu=x86
2015-01-04 19:37 GMT+03:00, Sergey Korshunoff sey...@gmail.com:
As suggested on another forum, there is a setarch linux32 command
for changing ARCH reported by uname -m.
2015-01-04 2:45 GMT+03:00, Thomas Preud'homme robo...@celest.fr:
Le mardi 30 décembre 2014, 11:05:15 Sergey Korshunoff a écrit :
Problem: configure in 32bit userspace running on 64bit kernel is
trying to compile tcc for ARCH=x86_64. Expecting behavior: to
configure a tcc for ARCH=x86
This patch will allow to specify/configure a target cpu. Examples:
ARCH=x86 ./configure
ARCH=x86_64 ./configure
If ARCH is not specified then try to detect a current cpu type by
examining arch of the host_cc.
The principle is nice but the code style looks different from the
rest and a
bit complicated for what it is. Why using a subscript for instance?
Why not
nesting if?
Finally, you could instead of using readelf use a carefully crafted
conftest
that would give you whether userspace is 32bit of 64bit. The
structure would
then look like this:
if ARCH is defined, then use it
else use uname
if cpu is x86_64 and conftest gives 32bit, cpu=i386.
What do you think?
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 mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
2014-12-30-1-configure-arch.patch
Description: Binary data
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] [PATCH] Disable BTESTS completely
Hello, this is not a my patch, it is from a debian package. From: Matteo Cypriani m...@lm7.fr Date: Sun, 7 Sep 2014 12:32:27 -0400 Subject: Disable BTESTS completely These tests don't pass for now ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] v2, preprocess all files from a command line with a -E switch
pp-many-files, v2 Don't drop a preprocessor defines when tcc going to preprocess a next file in the same pass like tcc -E one.c two.c three.c -o combined.i This will allow to speed up a compilation process by using a commamd like tcc -E *.c | tcc -o program.exe -xc - Initialization from tcc_preprocess() is moved to tcc_add_file_internal(). Call to free_defines(define_start) in tcc_preprocess() is removed in assumption that free_defines(NULL) in tcc_cleanup() will free all defines. 2015-01-04 1:46 GMT+03:00, Thomas Preud'homme robo...@celest.fr: Le samedi 27 décembre 2014, 16:19:04 Sergey Korshunoff a écrit : Don't drop a preprocessor defines when tcc going to preprocess a next file in the same pass like tcc -E one.c two.c three.c -o combined.i Currently tcc don't handle such case. The new behavior is better then the current one. After a patch it is possible to compile combined.i in case: * include files are properly protected by #ifndef MY_INCLUDE_H #define MY_INCLUDE_H extern void func(); #endif * there is no incompatible declarations for the same name in *.c An archive for a test purpose is included Sorry but I'm not sure I like this functionality. When gcc compiles several .c files they are compiled independently: macro are not kept accross files. Doing this only for -E flag would make it not very consistent. Also I don't like the shape of the patch: initialization of the preprocessing should be split out of the function but anyway that is not worth discussing further given previous point. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] v2, preprocess all files from a command line with a -E switch
I forgot to attach a patch 2015-01-06 15:29 GMT+03:00, Sergey Korshunoff sey...@gmail.com: pp-many-files, v2 Don't drop a preprocessor defines when tcc going to preprocess a next file in the same pass like tcc -E one.c two.c three.c -o combined.i This will allow to speed up a compilation process by using a commamd like tcc -E *.c | tcc -o program.exe -xc - Initialization from tcc_preprocess() is moved to tcc_add_file_internal(). Call to free_defines(define_start) in tcc_preprocess() is removed in assumption that free_defines(NULL) in tcc_cleanup() will free all defines. 2015-01-04 1:46 GMT+03:00, Thomas Preud'homme robo...@celest.fr: Le samedi 27 décembre 2014, 16:19:04 Sergey Korshunoff a écrit : Don't drop a preprocessor defines when tcc going to preprocess a next file in the same pass like tcc -E one.c two.c three.c -o combined.i Currently tcc don't handle such case. The new behavior is better then the current one. After a patch it is possible to compile combined.i in case: * include files are properly protected by #ifndef MY_INCLUDE_H #define MY_INCLUDE_H extern void func(); #endif * there is no incompatible declarations for the same name in *.c An archive for a test purpose is included Sorry but I'm not sure I like this functionality. When gcc compiles several .c files they are compiled independently: macro are not kept accross files. Doing this only for -E flag would make it not very consistent. Also I don't like the shape of the patch: initialization of the preprocessing should be split out of the function but anyway that is not worth discussing further given previous point. Best regards, Thomas 2014-12-27-02-pp-many-files.patch Description: Binary data ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] v3, preprocess all files from a command line with a -E switch
pp-many-files, v3 Don't drop a preprocessor defines when tcc going to preprocess a next file in the same pass like tcc -E one.c two.c three.c -o combined.i This will allow to speed up a compilation process by using a commamd like tcc -E *.c | tcc -o program.exe -xc - It looks that multi-times initialization don't affect anything. Only call to the free_defines(define_start) in tcc_preprocess() is removed in assumption that free_defines(NULL) in tcc_cleanup() will free all defines. 2015-01-06 15:33 GMT+03:00, Sergey Korshunoff sey...@gmail.com: I forgot to attach a patch 2015-01-06 15:29 GMT+03:00, Sergey Korshunoff sey...@gmail.com: pp-many-files, v2 Don't drop a preprocessor defines when tcc going to preprocess a next file in the same pass like tcc -E one.c two.c three.c -o combined.i This will allow to speed up a compilation process by using a commamd like tcc -E *.c | tcc -o program.exe -xc - Initialization from tcc_preprocess() is moved to tcc_add_file_internal(). Call to free_defines(define_start) in tcc_preprocess() is removed in assumption that free_defines(NULL) in tcc_cleanup() will free all defines. 2015-01-04 1:46 GMT+03:00, Thomas Preud'homme robo...@celest.fr: Le samedi 27 décembre 2014, 16:19:04 Sergey Korshunoff a écrit : Don't drop a preprocessor defines when tcc going to preprocess a next file in the same pass like tcc -E one.c two.c three.c -o combined.i Currently tcc don't handle such case. The new behavior is better then the current one. After a patch it is possible to compile combined.i in case: * include files are properly protected by #ifndef MY_INCLUDE_H #define MY_INCLUDE_H extern void func(); #endif * there is no incompatible declarations for the same name in *.c An archive for a test purpose is included Sorry but I'm not sure I like this functionality. When gcc compiles several .c files they are compiled independently: macro are not kept accross files. Doing this only for -E flag would make it not very consistent. Also I don't like the shape of the patch: initialization of the preprocessing should be split out of the function but anyway that is not worth discussing further given previous point. Best regards, Thomas 2014-12-27-02-pp-many-files.patch Description: Binary data ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] pp should interpret #num as #line num
Le mardi 6 janvier 2015, 12:52:06 Sergey Korshunoff a écrit :
v2 of the patch, which uses strtoul() insteed of the parse_number()
As I said, I was just looking for some explanation about why the parse_number
was necessary. The reason is that when dealing with TOK_LINE, next() is
called. next() will call next_nomacro() and then execute this piece of code:
/* convert preprocessor tokens into C tokens */
if (tok == TOK_PPNUM
(parse_flags PARSE_FLAG_TOK_NUM)) {
parse_number((char *)tokc.cstr-data);
}
And at the top of the function preprocess that deal with TOK_LINE:
parse_flags = PARSE_FLAG_PREPROCESS | PARSE_FLAG_TOK_NUM |
PARSE_FLAG_LINEFEED;
So yeah, the next token after TOK_LINE becomes a number and can be found in
tokc.i. If dealing with a #N macro, it would be a TOK_PPNUM and you'd need to
use parse_number to turn it into a normal number.
Therefore the approach in your first patch was perfectly fine. One thing
though:
could you rather move parse_number just before preprocess rather than
predeclare it? Unless there is a reason for it to be at this place in the file
in which case you can at least move the prototype declaration close the
next_nomacro_spc () one.
Thanks for your patch.
Best regards,
Thomas
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] Don't break compilation process with unknow option
That would avoid rewriting the Makefile to only add switches to CFLAGS that are supported by the compiler as it should have been done ;-) (no blame, we all do this). After applying a disable DTEST patch to allow make test to pass a broken tests... ./configure --cc=tcc; make; make install; make test tcc -o tcctest.cc tcctest.c -I.. -I.. -w -DTCC_TARGET_I386 -std=gnu99 -O0 -fno-omit-frame-pointer tcc: error: invalid option -- '-std=gnu99' With a patch apllied a test can be performed with make CFLAGS=-Wunsuported test And your solution? What you will add to CFLAGS? 2015-01-05 0:01 GMT+03:00, RoboTux robo...@celest.fr: Le 2015-01-04 04:42, Sergey Korshunoff a écrit : GCC and clang also error out for unknown option. What option caused your program to fail to compile? The patch is for the case with -Wunsupported. In such case a user will is Don't trap, only warning. There are many gcc options which tcc don't support. But in many cases, this options are not important. Changing a Makefiles is not a solution when trying to use tcc insteed of gcc. And a patch test command is: /tcc -Wunsupported -traditional -E tcc.c -o tcc.i I'd prefer a patch that just gives a warning for unknown -W option. It would be just like if the detection was really bad. Doing the same for other options would be more risky IMHO. That would avoid rewriting the Makefile to only add switches to CFLAGS that are supported by the compiler as it should have been done ;-) (no blame, we all do this). Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] Don't break compilation process with unknow option
Am 07.01.2015 um 04:14 schrieb Sergey Korshunoff: After applying a disable DTEST patch to allow make test to pass a broken tests... ./configure --cc=tcc; make; make install; make test tcc -o tcctest.cc tcctest.c -I.. -I.. -w -DTCC_TARGET_I386 -std=gnu99 -O0 -fno-omit-frame-pointer tcc: error: invalid option -- '-std=gnu99' With a patch apllied a test can be performed with make CFLAGS=-Wunsuported test And your solution? The makefile (and/or configure) needs to be fixed to not hardcode potentially unknown compiler options. What you will add to CFLAGS? Nothing. The only sensible thing that tcc can to with completely unknown options is to error out on them. It can't simply ignore them, not even with a warning as the unknown option in question might have significant effects for code generation for a compiler understanding it (-std=gnu99 is on the border of being such option) and the author might _require_ that effect to happen for his compilations. Ignoring it would either generate unnecessary followup errors or silently generate code with the wrong semantics, which is worse. There is a case to be made to only warn for unknown options that influence diagnostics only. As it's unknown it's of course hard to know when exactly that is the case. If it starts with -W that might be a good enough heuristic in practice, so I'm with Thomas on this topic. If you absolutely hate fixing makefiles/configures for trying out tcc, instead of patching tcc to ignore all unkown options you could also simply write a wrapper script that removes _known_ unknown options that you happen to hit when you know they indeed aren't important. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] pp should interpret #num as #line num
2015-01-07 1:26 GMT+03:00, Thomas Preud'homme robo...@celest.fr:
Le mardi 6 janvier 2015, 12:52:06 Sergey Korshunoff a écrit :
v2 of the patch, which uses strtoul() insteed of the parse_number()
As I said, I was just looking for some explanation about why the
parse_number
was necessary. The reason is that when dealing with TOK_LINE, next() is
called. next() will call next_nomacro() and then execute this piece of
code:
/* convert preprocessor tokens into C tokens */
if (tok == TOK_PPNUM
(parse_flags PARSE_FLAG_TOK_NUM)) {
parse_number((char *)tokc.cstr-data);
}
And at the top of the function preprocess that deal with TOK_LINE:
parse_flags = PARSE_FLAG_PREPROCESS | PARSE_FLAG_TOK_NUM |
PARSE_FLAG_LINEFEED;
So yeah, the next token after TOK_LINE becomes a number and can be found in
tokc.i. If dealing with a #N macro, it would be a TOK_PPNUM and you'd need
to
use parse_number to turn it into a normal number.
Therefore the approach in your first patch was perfectly fine. One thing
though:
could you rather move parse_number just before preprocess rather than
predeclare it? Unless there is a reason for it to be at this place in the
file
in which case you can at least move the prototype declaration close the
next_nomacro_spc () one.
Thanks for your patch.
Best regards,
Thomas
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
