Re: [Tinycc-devel] [PATCH] Re: using gdb 6.6 on linux fail after dec18 2013
Le dimanche 4 janvier 2015, 08:10:40 Sergey Korshunoff a écrit : Return back a grischka patch which lost after Split elf_output_file in smaller functions Author: grischka grischka Date: Tue Feb 5 21:18:29 2013 +0100 tccelf: fix debug section relocation With: tcc -g hello.c gdb a.out b main gdb refused to know main because of broken dwarf info. I don't understand. The commit you mention (92024ab07ad8e1c4a05f90add3d3ca7932251016) contains the exact opposite patch. Also the patch I wrote to split elf_output_file in several functions didn't change this line. I quote the rest of the commit message: This partially reverts commit 0d598aca087e46ea67f97dda50df3eed522d5e7a. I don't remember what the problem was but it was the wrong way to fix it. So before we revert the revert it would be nice to have an explanation of why this is necessary. By this I mean an analysis of what's happening, not just it works after I revert. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] Re: using gdb 6.6 on linux fail after dec18 2013
Le dimanche 4 janvier 2015, 11:04:22 Sergey Korshunoff a écrit : A patch is applied to solve this bug. Hi Sergey, Shouldn't file-line_num be passed as the last parameter of put_stabs? Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] pp-defines
Le dimanche 4 janvier 2015, 07:53:44 Sergey Korshunoff a écrit : This patch seems unnecessary as tcc_define_symbol with a third argument NULL is equivalent as setting it to 1 (#define FOO is the same as #define FOO 1) I trying to be exactly the same as gcc. And this macros in gcc are as 1 not Do you have an example of where this difference matters? For all purpose #define FOO 1 and #define FOO should be identical. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] Re: using gdb 6.6 on linux fail after dec18 2013
Yes, you are right. I'm lost the ground trying to detect a point after which debugger don't do the work. tcc v0.9.25 was working. After a grischka patch a debugger don't work. And exactly with the same symptom: gdb refused to know main.I don't understand why, sorry. Did gdb work for you w/o a patch? PS: may be this is because I work in 32bit environment... 2015-01-04 16:36 GMT+03:00, Thomas Preud'homme robo...@celest.fr: Le dimanche 4 janvier 2015, 08:10:40 Sergey Korshunoff a écrit : Return back a grischka patch which lost after Split elf_output_file in smaller functions Author: grischka grischka Date: Tue Feb 5 21:18:29 2013 +0100 tccelf: fix debug section relocation With: tcc -g hello.c gdb a.out b main gdb refused to know main because of broken dwarf info. I don't understand. The commit you mention (92024ab07ad8e1c4a05f90add3d3ca7932251016) contains the exact opposite patch. Also the patch I wrote to split elf_output_file in several functions didn't change this line. I quote the rest of the commit message: This partially reverts commit 0d598aca087e46ea67f97dda50df3eed522d5e7a. I don't remember what the problem was but it was the wrong way to fix it. So before we revert the revert it would be nice to have an explanation of why this is necessary. By this I mean an analysis of what's happening, not just it works after I revert. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] Re: using gdb 6.6 on linux fail after dec18 2013
May be yes. I don't found a code where a line info is passed to the put_stabs... 2015-01-04 16:49 GMT+03:00, Thomas Preud'homme robo...@celest.fr: Le dimanche 4 janvier 2015, 11:04:22 Sergey Korshunoff a écrit : A patch is applied to solve this bug. Hi Sergey, Shouldn't file-line_num be passed as the last parameter of put_stabs? Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [BUG] tcc and INT64: wrong result of comparison (a test included)
By replacing a -2147483648 with a -2147483647 I can succesfully build a working nim compiler. But this is not so good... 2015-01-04 12:45 GMT+03:00, Sergey Korshunoff sey...@gmail.com: HI! A test attached is a snippet code from a nimrod compiler. Currenly tcc fails to compile it rigth. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] allow to tell a target ARCH to a configure script
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
Re: [Tinycc-devel] [BUG] tcc and INT64: wrong result of comparison (a test included)
It is possible to correct a case for -2147483648 ? A code generated by tcc and gcc is attached. 2015-01-04 19:18 GMT+03:00, Sergey Korshunoff sey...@gmail.com: By replacing a -2147483648 with a -2147483647 I can succesfully build a working nim compiler. But this is not so good... 2015-01-04 12:45 GMT+03:00, Sergey Korshunoff sey...@gmail.com: HI! A test attached is a snippet code from a nimrod compiler. Currenly tcc fails to compile it rigth. a code produced by tcc: ## -2147483648LL 2d: ba 00 00 00 80 mov$0x8000,%edx 32: 89 45 f4mov%eax,-0xc(%ebp) 35: b8 ff ff ff ff mov$0x,%eax 3a: 39 c1 cmp%eax,%ecx 3c: 0f 87 2e 00 00 00 ja 70 main+0x70 # jg 42: 0f 85 0b 00 00 00 jne53 main+0x53 # jl 48: 8b 45 f4mov-0xc(%ebp),%eax 4b: 39 d0 cmp%edx,%eax 4d: 0f 83 1d 00 00 00 jae70 main+0x70 ## -2147483647LL 2d: ba 01 00 00 80 mov$0x8001,%edx 32: 89 45 f4mov%eax,-0xc(%ebp) 35: b8 ff ff ff ff mov$0x,%eax 3a: 39 c1 cmp%eax,%ecx 3c: 0f 8f 2e 00 00 00 jg 70 main+0x70 42: 0f 85 0b 00 00 00 jne53 main+0x53 # jl 48: 8b 45 f4mov-0xc(%ebp),%eax 4b: 39 d0 cmp%edx,%eax 4d: 0f 83 1d 00 00 00 jae70 main+0x70 a code produced by gcc: ## -2147483648LL 3a: 83 7d fc ff cmpl $0x,-0x4(%ebp) # high word 3e: 7f 28 jg 68 main+0x68 40: 83 7d fc ff cmpl $0x,-0x4(%ebp) 44: 7c 09 jl 4f main+0x4f 46: 81 7d f8 00 00 00 80cmpl $0x8000,-0x8(%ebp) # low word 4d: 73 19 jae68 main+0x68 ## -2147483647L 3a: 83 7d fc ff cmpl $0x,-0x4(%ebp) 3e: 7f 28 jg 68 main+0x68 40: 83 7d fc ff cmpl $0x,-0x4(%ebp) 44: 7c 09 jl 4f main+0x4f 46: 81 7d f8 01 00 00 80cmpl $0x8001,-0x8(%ebp) 4d: 73 19 jae68 main+0x68 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] Re: using gdb 6.6 on linux fail after dec18 2013
A patch is applied to solve this bug. 2015-01-04 8:58 GMT+03:00, Sergey Korshunoff sey...@gmail.com: After a previous patch applied... Bug: a line number declaration (# NUM xxx file_name) is not used when generating a debug info. A test case: precompile your project files with tcc and then use a precompiled files to get an executable with a debug info included. This info will be wrong. A gcc works rigth in this case. 2015-01-04 8:10 GMT+03:00, Sergey Korshunoff sey...@gmail.com: Return back a grischka patch which lost after Split elf_output_file in smaller functions Author: grischka grischka Date: Tue Feb 5 21:18:29 2013 +0100 tccelf: fix debug section relocation With: tcc -g hello.c gdb a.out b main gdb refused to know main because of broken dwarf info. 2015-01-03 22:03 GMT+03:00, Sergey Korshunoff sey...@gmail.com: There is a patch 4aec2902cabb819e24850c80ddb364b7b4308b7b Author: Thomas Preud'homme robo...@celest.fr Date: Wed Dec 18 11:17:17 2013 +0800 Split elf_output_file in smaller functions After this patch a usage of the gdb 6.6 on Linux is not possible (gdb can not find a main proc for setting a breakpoint). Which debuger you on LInux to debug a programs compiled by tcc? PS: I don't have problems with debugging a programs which are compiled by gcc 4.1.2, 3.4.6, ... 2015-01-05-2-tccelf-debug.patch Description: Binary data ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] [BUG] tcc and INT64: wrong result of comparison (a test included)
HI! A test attached is a snippet code from a nimrod compiler. Currenly
tcc fails to compile it rigth.
#include stdio.h
typedef long long int NI64;
int main()
{
NI64 res = 0;
printf(Test for comparing a INT64 values: );
if (res -2147483648LL) {
printf(Error: 0 -2147483648\n);
return 1;
}
else
if (2147483647LL res) {
printf(Error: 2147483647 0\n);
return 2;
}
else {
printf(OK\n);
return 0;
}
}
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Creating a debugger for my own language, in TinyCC?
Hi people...
Is it possible to create a debugger, for my own (Secret) programming language
using TinyCC?
I'll spare you the long details (unless you need it)...
but here goes as short as I can...
So... let's imagine... I'm converting high-level code into C code.
Then... in this C code... I want to insert 2 functions... into every
translated function
DB_GetStackPointer(int)
DB_Line(int)
So...
function Func(MyStringArray) {
for (S in MyStringArray) {
print_line S
}
}
--
void Func(Type1* self, Type2* MyStringArray) {
DB_GetStackPointer(1); // DB_ means its a function for debugging the code
// So we save the current stack pointer to a global
variable
// and tell the debugger that we are on line 1 of the
current file's source code.
int N = 0;
while (N length(MyStringArray)) {
Type3* S = element(MyStringArray, N);
DB_Line(2);// Tell the debugger that we have advanced to line 2
of our *original* source code.
N++;
};
DB_Line(3);
}
All I need to do then... is implement DB_Line and DB_GetStackPointer. The idea
is that DB_GetStackPointer will save the current stack pointer... and DB_Line
will go to a func that lets me read the current variables off that stack
pointer, and then send them via a socket/TCP-connection... to my debugger.
I tried something like this using __builtin_frame_address from Xcode... but the
variables did not exist in a reliable location, relative to the stack pointer,
even in debug builds...
I guess the question really simply is...
Q: How easy is it, to get from the stack pointer, to the local
variables... in TinyCC?
That is... do they exist in a very simple and predictable format? Pretty much
starting from from function params... then going to any local variables still
in scope? And simply listing them in order?
If so... perhaps I could use TinyCC for my project...
Q: Or perhaps you have some better way of scraping local variables
out of a calling parent function?
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [BUG] tcc and INT64: wrong result of comparison (a test included)
There is another approach: assume the constant is negative by default.
This is the method used in nimrod to scan a constants:
lib/pure/parseutils.nim(rawparse)
proc rawParseInt(s: string, b: var BiggestInt, start: int = 0): int =
var
sign: BiggestInt = -1 # minus by defaul
i = start
if s[i] == '+': inc(i)
elif s[i] == '-':
inc(i)
sign = 1
if s[i] in {'0'..'9'}:
b = 0
while s[i] in {'0'..'9'}:
b = b * 10 - (ord(s[i]) - ord('0')) #! the point
inc(i)
while s[i] == '_': inc(i) # underscores are allowed and ignored
b = b * sign
result = i - start
Sun, 04 Jan 2015 16:51 +, Thomas Preud'homme robo...@celest.fr:
Le dimanche 4 janvier 2015, 19:18:34 Sergey Korshunoff a écrit :
By replacing a -2147483648 with a -2147483647 I can succesfully build
a working nim compiler. But this is not so good...
The bug is in tccpp.c parse_number. The function tries to guess what should
be
the size and sign of the litteral before parsing the suffix (which might not
exist).
/* XXX: not exactly ANSI compliant */
if ((n 0xLL) != 0) {
if ((n 63) != 0)
tok = TOK_CULLONG;
else
tok = TOK_CLLONG;
} else if (n 0x7fff) {
tok = TOK_CUINT;
} else {
tok = TOK_CINT;
}
In your case it will pass in the first else if and set tok to TOK_CUINT. So
far
so good.
Then it will parse the suffix and when it sees the second L it does this:
if (tok == TOK_CINT)
tok = TOK_CLLONG;
else if (tok == TOK_CUINT)
tok = TOK_CULLONG;
So here it will set the value to TOK_CULLONG while it should set it to
TOK_CLLONG and warn if the value is too big.
My feeling is that the automatic guess for the size and sign should be done
after trying to look for a suffix.
The algorithm would be something like:
1) Set tok to TOK_CINT and suffix_found to false.
2) Then look for a L or U suffix with unchanged code except for setting a
suffix_found variable if any such suffix is found.
3) Then if suffix_found is false try automatic detection, otherwise warn of
overflow and possibly process the overflow (what does GCC does in this
case?) Be
careful about the sign when checking for overflow.
Do you want to take a stab at it?
Best regards,
Thomas
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] pp-defines
On 4 janv. 2015, at 15:10, Thomas Preud'homme robo...@celest.fr wrote: Le dimanche 4 janvier 2015, 07:53:44 Sergey Korshunoff a écrit : This patch seems unnecessary as tcc_define_symbol with a third argument NULL is equivalent as setting it to 1 (#define FOO is the same as #define FOO 1) I trying to be exactly the same as gcc. And this macros in gcc are as 1 not Do you have an example of where this difference matters? For all purpose #define FOO 1 and #define FOO should be identical. Your explanation is confusing: #define FOO and #define FOO 1 are indeed different macro definitions with different expansions. But we are discussing predefined macros that are defined using the same function as for command line macro definitions -DFOO and -DFOO=1 command line options have identical behavior, namely defining macro FOO with value 1 parse_option_D() calls tcc_define_symbol() with the value after ‘=' or NULL if none is present. tcc_define_symbol() checks for NULL and uses “1” as the default value. tcc_define_symbol() creates a string from its arguments and then calls the actual parser parse_define(). Thus, If you want to add new predefined macros with the value 1, it is safe to pass NULL instead of “1” as a value. It also produces less code, but is more confusing ;-) Chqrlie. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
