Re: [Tinycc-devel] Dollar Sign in Identifiers Extension
Hi Ramsey,
Thanks for trying it. The patch I made is from stable download here
http://bellard.org/tcc/ Sorry if that is wrong. Where can I get the mob
branch?
Thanks,
Dan
On 13/04/2015 18:16, Ramsay Jones wrote:
On 13/04/15 16:01, Daniel Holden wrote:
Hi,
I've attached a new patch which tests for dollars in identifiers in C.
I've added a new parsing flag `PARSE_FLAG_ASM` to block the use of dollar
identifiers when parsing asm. This could probably be combined with the
`PARSE_FLAG_ASM_COMMENTS` flag.
Currently the flag only blocks identifiers in asm _starting_ with a dollar. I
think this is the only syntactically valid place in which dollars occurring
could conflict with gas asm, but they might appear inside identifiers if the
programmer is either referencing a symbol with a dollar in _or_ if they've made
a syntax error. I'll look into it more and do some more testing.
I'm on 64 bit and I have to hack the makefiles to run the assembly tests
because they are written in 32-bit x86. Does anyone have a 32-bit machine they
are testing tcc on?
Your patch does not apply to the mob branch:
$ git apply ../dollars-in-identifiers.patch
../dollars-in-identifiers.patch:36: trailing whitespace.
../dollars-in-identifiers.patch:40: trailing whitespace.
|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
../dollars-in-identifiers.patch:41: trailing whitespace.
../dollars-in-identifiers.patch:135: trailing whitespace.
../dollars-in-identifiers.patch:138: trailing whitespace.
error: patch failed: tcc.h:528
error: tcc.h: patch does not apply
error: patch failed: libtcc.c:1423
error: libtcc.c: patch does not apply
error: patch failed: tccpp.c:2178
error: tccpp.c: patch does not apply
error: patch failed: ./tests/tests2/Makefile:67
error: ./tests/tests2/Makefile: patch does not apply
$
... but I'm guessing you already know that!
Applying your patch instead to the master branch:
$ git apply ../dollars-in-identifiers.patch
../dollars-in-identifiers.patch:36: trailing whitespace.
../dollars-in-identifiers.patch:40: trailing whitespace.
|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
../dollars-in-identifiers.patch:41: trailing whitespace.
../dollars-in-identifiers.patch:135: trailing whitespace.
../dollars-in-identifiers.patch:138: trailing whitespace.
warning: squelched 3 whitespace errors
warning: 8 lines add whitespace errors.
$
... shows that you are introducing some whitespace errors
(although the number of lines doesn't seem to tally!).
After 'git apply'-ing your patch and staging ('git add'-ing)
your changes (including the new files), then:
$ git diff --cached --check
tccpp.c:2181: trailing whitespace.
+
tccpp.c:2185: trailing whitespace.
+|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
tccpp.c:2186: trailing whitespace.
+
tests/tests2/56_dollars.c:20: trailing whitespace.
+
tests/tests2/56_dollars.c:23: trailing whitespace.
+
tests/tests2/56_dollars.c:24: trailing whitespace.
+ int $ = 10;
tests/tests2/56_dollars.c:30: trailing whitespace.
+
tests/tests2/56_dollars.c:42: new blank line at EOF.
$
(you can't see the red highlight on the trailing whitespace in
an email, of course! ;)
Note: so far this is on an 64-bit system, I was going to try on
a 32-bit system later.
After running:
$ make clean
...
$ ./configure
...
$ make
...
$ make test
...
Test: 56_dollars...
56_dollars.c:14: error: '$' undeclared
make[2]: *** [56_dollars.test] Error 1
make[2]: Leaving directory `/home/ramsay/tinycc/tests/tests2'
make[1]: *** [moretests] Error 2
make[1]: Leaving directory `/home/ramsay/tinycc/tests'
make: *** [test] Error 2
$
So, I'm obviously doing something wrong, sorry! :(
I suspect it's not worth trying on 32-bit, if I can't get it
to work on a 64-bit system.
ATB,
Ramsay Jones
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Dollar Sign in Identifiers Extension
On 13/04/15 17:51, Daniel Holden wrote: Hi Ramsey, Thanks for trying it. The patch I made is from stable download here http://bellard.org/tcc/ Sorry if that is wrong. Where can I get the mob branch? Ah, OK. The current master branch is tagged as 'release_0_9_26'. The git repository for tinycc can be obtained from repo.or.zc: $ git clone git://repo.or.cz/tinycc.git Cloning into 'tinycc'... remote: Counting objects: 7112, done. remote: Compressing objects: 100% (2158/2158), done. Receiving objects: 100% (7112/7112), 3.00 MiB | 964.00 KiB/s, done. remote: Total 7112 (delta 4962), reused 7002 (delta 4890) Resolving deltas: 100% (4962/4962), done. Checking connectivity... done. $ cd tinycc $ git branch -v * mob a13f183 ability to compile multiple *.c files with -c switch $ git branch -rv origin/HEAD - origin/mob origin/masterd5e2210 Release TinyCC 0.9.26 origin/mob a13f183 ability to compile multiple *.c files with -c switch origin/mob-stuff bfa394d Move bounds-checking code to a bcheck.a origin/tcc-xref ab24b28 tcc xref experiment $ git branch master origin/master Branch master set up to track remote branch master from origin. $ git branch -v master d5e2210 Release TinyCC 0.9.26 * moba13f183 ability to compile multiple *.c files with -c switch $ BTW, I get identical results on a 32-bit system. Also, the asmtest looks like this: $ make -C tests asmtest ... asmtest ../tcc -B.. -c asmtest.S objdump -D asmtest.o asmtest.out --- asmtest.ref 2015-04-13 20:11:34.856115487 +0100 +++ asmtest.out 2015-04-13 20:26:28.668071775 +0100 @@ -57,7 +57,7 @@ 5d:90 nop 5e:90 nop 5f:90 nop - 60:a1 5c 00 00 00 mov0x5c,%eax + 60:a1 00 00 00 00 mov0x0,%eax 65:89 c3 mov%eax,%ebx 67:a1 00 00 01 00 mov0x1,%eax 6c:66 a1 00 00 01 00 mov0x1,%ax @@ -167,7 +167,7 @@ 1fe:f6 05 00 10 00 00 01testb $0x1,0x1000 205:66 f7 05 00 10 00 00testw $0x1,0x1000 20c:01 00 - 20e:85 c3 test %eax,%ebx + 20e:85 d8 test %ebx,%eax 210:85 05 00 10 00 00 test %eax,0x1000 216:85 15 00 10 00 00 test %edx,0x1000 21c:f7 d2 not%edx make: Leaving directory `/home/ramsay/tinycc/tests' $ HTH ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] #pragma comment(lib,...) patch
Hi! As sugested Tomas Preud'homme: Turn on a fill tabs with spaces option in your editor. Be also careful that some files are indented with 2 spaces (when they have large indentation) while most are indented with 4 spaces There are a tabs in your patch :-( Otherwise it looks nice. I will try to test it. I'm sorry, they slipped through. Do you need me to rework the patch before (if) you test? Thanks, Steven G. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Dollar Sign in Identifiers Extension
Hi! 2015-04-13 15:01 GMT, Daniel Holden s0822...@staffmail.ed.ac.uk: I've attached a new patch which tests for dollars in identifiers in C. I've added a new parsing flag `PARSE_FLAG_ASM` to block the use of dollar identifiers when parsing asm. This could probably be combined with the `PARSE_FLAG_ASM_COMMENTS` flag. In the mob branch there is a flag PARSE_FLAG_ASM_FILE (in tcc_add_file_internal) turned on before calling tcc_assmble. What is needed in tcc_assemble is to keep it when changing parse_flags. Then your patch must check PARSE_FLAG_ASM_FILE and not a PARSE_FLAG_ASM. PARSE_FLAG_ASM_FILE is introduced to solve problems of the preprocessor (different rules of the # parsing) First version of the your patch is pushed to mob by me (with you as the autor of the patch in comments). Only addons of the new patch must be pushed to the mob. Your patch contain a \r chars. Is this chars are removed by git? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Dollar Sign in Identifiers Extension
On 13/04/15 16:01, Daniel Holden wrote:
Hi,
I've attached a new patch which tests for dollars in identifiers in C.
I've added a new parsing flag `PARSE_FLAG_ASM` to block the use of dollar
identifiers when parsing asm. This could probably be combined with the
`PARSE_FLAG_ASM_COMMENTS` flag.
Currently the flag only blocks identifiers in asm _starting_ with a dollar. I
think this is the only syntactically valid place in which dollars occurring
could conflict with gas asm, but they might appear inside identifiers if the
programmer is either referencing a symbol with a dollar in _or_ if they've
made a syntax error. I'll look into it more and do some more testing.
I'm on 64 bit and I have to hack the makefiles to run the assembly tests
because they are written in 32-bit x86. Does anyone have a 32-bit machine
they are testing tcc on?
Your patch does not apply to the mob branch:
$ git apply ../dollars-in-identifiers.patch
../dollars-in-identifiers.patch:36: trailing whitespace.
../dollars-in-identifiers.patch:40: trailing whitespace.
|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
../dollars-in-identifiers.patch:41: trailing whitespace.
../dollars-in-identifiers.patch:135: trailing whitespace.
../dollars-in-identifiers.patch:138: trailing whitespace.
error: patch failed: tcc.h:528
error: tcc.h: patch does not apply
error: patch failed: libtcc.c:1423
error: libtcc.c: patch does not apply
error: patch failed: tccpp.c:2178
error: tccpp.c: patch does not apply
error: patch failed: ./tests/tests2/Makefile:67
error: ./tests/tests2/Makefile: patch does not apply
$
... but I'm guessing you already know that!
Applying your patch instead to the master branch:
$ git apply ../dollars-in-identifiers.patch
../dollars-in-identifiers.patch:36: trailing whitespace.
../dollars-in-identifiers.patch:40: trailing whitespace.
|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
../dollars-in-identifiers.patch:41: trailing whitespace.
../dollars-in-identifiers.patch:135: trailing whitespace.
../dollars-in-identifiers.patch:138: trailing whitespace.
warning: squelched 3 whitespace errors
warning: 8 lines add whitespace errors.
$
... shows that you are introducing some whitespace errors
(although the number of lines doesn't seem to tally!).
After 'git apply'-ing your patch and staging ('git add'-ing)
your changes (including the new files), then:
$ git diff --cached --check
tccpp.c:2181: trailing whitespace.
+
tccpp.c:2185: trailing whitespace.
+|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
tccpp.c:2186: trailing whitespace.
+
tests/tests2/56_dollars.c:20: trailing whitespace.
+
tests/tests2/56_dollars.c:23: trailing whitespace.
+
tests/tests2/56_dollars.c:24: trailing whitespace.
+ int $ = 10;
tests/tests2/56_dollars.c:30: trailing whitespace.
+
tests/tests2/56_dollars.c:42: new blank line at EOF.
$
(you can't see the red highlight on the trailing whitespace in
an email, of course! ;)
Note: so far this is on an 64-bit system, I was going to try on
a 32-bit system later.
After running:
$ make clean
...
$ ./configure
...
$ make
...
$ make test
...
Test: 56_dollars...
56_dollars.c:14: error: '$' undeclared
make[2]: *** [56_dollars.test] Error 1
make[2]: Leaving directory `/home/ramsay/tinycc/tests/tests2'
make[1]: *** [moretests] Error 2
make[1]: Leaving directory `/home/ramsay/tinycc/tests'
make: *** [test] Error 2
$
So, I'm obviously doing something wrong, sorry! :(
I suspect it's not worth trying on 32-bit, if I can't get it
to work on a 64-bit system.
ATB,
Ramsay Jones
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Dollar Sign in Identifiers Extension
On 13/04/15 18:16, Ramsay Jones wrote:
On 13/04/15 16:01, Daniel Holden wrote:
Hi,
I've attached a new patch which tests for dollars in identifiers in C.
I've added a new parsing flag `PARSE_FLAG_ASM` to block the use of dollar
identifiers when parsing asm. This could probably be combined with the
`PARSE_FLAG_ASM_COMMENTS` flag.
Currently the flag only blocks identifiers in asm _starting_ with a dollar.
I think this is the only syntactically valid place in which dollars
occurring could conflict with gas asm, but they might appear inside
identifiers if the programmer is either referencing a symbol with a dollar
in _or_ if they've made a syntax error. I'll look into it more and do some
more testing.
I'm on 64 bit and I have to hack the makefiles to run the assembly tests
because they are written in 32-bit x86. Does anyone have a 32-bit machine
they are testing tcc on?
Your patch does not apply to the mob branch:
$ git apply ../dollars-in-identifiers.patch
../dollars-in-identifiers.patch:36: trailing whitespace.
../dollars-in-identifiers.patch:40: trailing whitespace.
|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
../dollars-in-identifiers.patch:41: trailing whitespace.
../dollars-in-identifiers.patch:135: trailing whitespace.
../dollars-in-identifiers.patch:138: trailing whitespace.
error: patch failed: tcc.h:528
error: tcc.h: patch does not apply
error: patch failed: libtcc.c:1423
error: libtcc.c: patch does not apply
error: patch failed: tccpp.c:2178
error: tccpp.c: patch does not apply
error: patch failed: ./tests/tests2/Makefile:67
error: ./tests/tests2/Makefile: patch does not apply
$
... but I'm guessing you already know that!
Applying your patch instead to the master branch:
$ git apply ../dollars-in-identifiers.patch
../dollars-in-identifiers.patch:36: trailing whitespace.
../dollars-in-identifiers.patch:40: trailing whitespace.
|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
../dollars-in-identifiers.patch:41: trailing whitespace.
../dollars-in-identifiers.patch:135: trailing whitespace.
../dollars-in-identifiers.patch:138: trailing whitespace.
warning: squelched 3 whitespace errors
warning: 8 lines add whitespace errors.
$
... shows that you are introducing some whitespace errors
(although the number of lines doesn't seem to tally!).
After 'git apply'-ing your patch and staging ('git add'-ing)
your changes (including the new files), then:
$ git diff --cached --check
tccpp.c:2181: trailing whitespace.
+
tccpp.c:2185: trailing whitespace.
+|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
tccpp.c:2186: trailing whitespace.
+
tests/tests2/56_dollars.c:20: trailing whitespace.
+
tests/tests2/56_dollars.c:23: trailing whitespace.
+
tests/tests2/56_dollars.c:24: trailing whitespace.
+ int $ = 10;
tests/tests2/56_dollars.c:30: trailing whitespace.
+
tests/tests2/56_dollars.c:42: new blank line at EOF.
$
(you can't see the red highlight on the trailing whitespace in
an email, of course! ;)
Note: so far this is on an 64-bit system, I was going to try on
a 32-bit system later.
Of course, I forgot that you said you had to hack the Makefile before
you could test on 64-bit systems ... sorry about that! :(
I will try it on a 32-bit system later ...
ATB,
Ramsay Jones
After running:
$ make clean
...
$ ./configure
...
$ make
...
$ make test
...
Test: 56_dollars...
56_dollars.c:14: error: '$' undeclared
make[2]: *** [56_dollars.test] Error 1
make[2]: Leaving directory `/home/ramsay/tinycc/tests/tests2'
make[1]: *** [moretests] Error 2
make[1]: Leaving directory `/home/ramsay/tinycc/tests'
make: *** [test] Error 2
$
So, I'm obviously doing something wrong, sorry! :(
I suspect it's not worth trying on 32-bit, if I can't get it
to work on a 64-bit system.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] RE :Re: Dollar Sign in Identifiers Extension
___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] TCC arm64 back end
Hello Thomas, On Sun, 12 Apr 2015, Thomas Preud'homme wrote: I was a bit puzzled because I saw symbols are resolved when a file is loaded that define them (in tcc_load_object_file). The reason this doesn't happen here is that the symbol is provided by libc.so.6 and the function that loads dynamic libraries (tcc_load_dll) only look for undefined symbols in dynsymtab_section rather than symtab_section. There might be an obvious reason but I'm not sure why symbols from object files and libraries are handled differently in terms of name resolution. Of course relocation happens differently but name resolution should be the same, shouldn't it? Object files have no dynsym section, only a symtab. Conversely shared objects don't have a symtab (conceptually; in reality they might have one, but then only for debugging purposes); their interface (and that's what is wanted when loading or linking against a shared object) is described by dynsym. It should be (and mostly is) like this in tcc: * symtab_section contains all symbols (defined or undefined) from either .c files or regular .o files (ET_REL) contained on the cmdline * s1-dynsymtab_section contain all symbols (defined or undefined) from all shared objects (ET_DYN) mentioned on the command line (these are collected from their respective .dynsym sections) * s1-dynsym contains the resulting dynamic symbols of the to-be-produced executable or shared library (i.e. that one is built up in several steps during linking) bind_exe_dynsyms is the one converting from symtab_section to .dynsym. After all, all undefined symbols (in symtab) must come from some shared lib (if it came from some .o it would not be undefined in symtab), hence must be recorded somewhere in dynsymtab. But to actually create the import this symbol then must be listed in the executables .dynsym section, and this is what's done in bind_exe_dynsyms (i.e. it resolved undefined symbols to shared libs). Conversely shared libs may also contain undefined symbols. If they are provided by other shared libs the dynamic linker will take care of it. But they may also be provided by the main executable. In order to avoid exporting _all_ global symbols from an executable always, only symbols actually undefined in shared libs and provided by the executable are exported (included as defined in .dynsym). That's the purpose of bind_libs_dynsyms. For creating a shared lib, all global symbols (with default visibility) are exported (included in their .dynsym); that's done by export_global_syms. But when linking with tcc I get: Hello, world! Yes, that's a bug in tcc. The problem is that all .dynsyms from shared libs are load and merged before the symtab of the executable is consulted. Therefore dynsymtab contains a definition for printf (from glibc) and hence bind_libs_dynsyms doesn't see anymore that it was once undefined in one library; it would probably need tweaking in add_elf_sym (if the to-be-added symbol is from shared libs, and should be added into dynsymtab, then UNDEF should prevail, not definedness; alternatively this only when also contained in symtab_section as global). I also found a possible speed improvement. Currently tcc_load_dll load dll recursively. Yes, but that's not only a speed change, but a semantic one as well. Basically what tcc implements right now is something in between ld's --copy-dt-needed-entries and its negative; tcc will _search_ for symbols also in referenced DSOs, but won't record a DT_NEEDED tag (this is a useless behaviour). That should only be necessary for tcc_run but that require changing bind_libs_dynsyms (which requires changing anyway because of the bug above). I don't see that. Also undefined references from shared libs should only be satisfied by the executable if they are mentioned directly on the command line I think. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] TCC arm64 back end
Le lundi 13 avril 2015, 15:12:52 Michael Matz a écrit : Hello Thomas, On Sun, 12 Apr 2015, Thomas Preud'homme wrote: I was a bit puzzled because I saw symbols are resolved when a file is loaded that define them (in tcc_load_object_file). The reason this doesn't happen here is that the symbol is provided by libc.so.6 and the function that loads dynamic libraries (tcc_load_dll) only look for undefined symbols in dynsymtab_section rather than symtab_section. There might be an obvious reason but I'm not sure why symbols from object files and libraries are handled differently in terms of name resolution. Of course relocation happens differently but name resolution should be the same, shouldn't it? Object files have no dynsym section, only a symtab. Conversely shared objects don't have a symtab (conceptually; in reality they might have one, but then only for debugging purposes); their interface (and that's what is wanted when loading or linking against a shared object) is described by dynsym. Yes, as you noticed I tend to focus too much on the code and not think enough about how it all works. It's like every time I need to do a change in the linker I relearn how it all works when I already have most of the knowledge. Anyway don't worry as I rediscovered it by myself today when doing some tests to understand how it all work. It should be (and mostly is) like this in tcc: * symtab_section contains all symbols (defined or undefined) from either .c files or regular .o files (ET_REL) contained on the cmdline * s1-dynsymtab_section contain all symbols (defined or undefined) from all shared objects (ET_DYN) mentioned on the command line (these are collected from their respective .dynsym sections) * s1-dynsym contains the resulting dynamic symbols of the to-be-produced executable or shared library (i.e. that one is built up in several steps during linking) Indeed, I refigured this out today. bind_exe_dynsyms is the one converting from symtab_section to .dynsym. After all, all undefined symbols (in symtab) must come from some shared lib (if it came from some .o it would not be undefined in symtab), hence must be recorded somewhere in dynsymtab. But to actually create the import this symbol then must be listed in the executables .dynsym section, and this is what's done in bind_exe_dynsyms (i.e. it resolved undefined symbols to shared libs). Yes, and it should be the only place calling put_got_entry. Right now it's a bit in build_got_entries and a bit in bind_exe_dynsyms. Unless I missed something but I'll discover before I do any change. Conversely shared libs may also contain undefined symbols. If they are provided by other shared libs the dynamic linker will take care of it. But they may also be provided by the main executable. In order to avoid exporting _all_ global symbols from an executable always, only symbols actually undefined in shared libs and provided by the executable are exported (included as defined in .dynsym). That's the purpose of bind_libs_dynsyms. It doesn't have to be undefined. I just did a test with ld and it exports symbol form the program if it's present in a dynsym of any library. Ld's man page confirm that in the description of the -E (aka --export-dynamic) option: If you do not use either of these options (or use the --no-export-dynamic option to restore the default behavior), the dynamic symbol table will normally contain only those symbols which are referenced by some dynamic object mentioned in the link. For creating a shared lib, all global symbols (with default visibility) are exported (included in their .dynsym); that's done by export_global_syms. But when linking with tcc I get: Hello, world! Yes, that's a bug in tcc. The problem is that all .dynsyms from shared libs are load and merged before the symtab of the executable is consulted. Therefore dynsymtab contains a definition for printf (from glibc) and hence bind_libs_dynsyms doesn't see anymore that it was once undefined in one library; it would probably need tweaking in add_elf_sym (if the to-be-added symbol is from shared libs, and should be added into dynsymtab, then UNDEF should prevail, not definedness; alternatively this only when also contained in symtab_section as global). The good news is that given the above, add_elf_sym doesn't need to be changed but only bind_libs_dynsyms. Or at least it should be as easy as moving the == UNDEF to guard the warning below but unfortunately doing so segfault because some relocation is not happening. Don't worry, I'll get to the bottom of it. I also found a possible speed improvement. Currently tcc_load_dll load dll recursively. Yes, but that's not only a speed change, but a semantic one as well. Basically what tcc implements right now is something in between ld's --copy-dt-needed-entries and its negative; tcc will _search_ for symbols also in referenced
Re: [Tinycc-devel] Dollar Sign in Identifiers Extension
Hi,
I've attached a new patch which tests for dollars in identifiers in C.
I've added a new parsing flag `PARSE_FLAG_ASM` to block the use of
dollar identifiers when parsing asm. This could probably be combined
with the `PARSE_FLAG_ASM_COMMENTS` flag.
Currently the flag only blocks identifiers in asm _starting_ with a
dollar. I think this is the only syntactically valid place in which
dollars occurring could conflict with gas asm, but they might appear
inside identifiers if the programmer is either referencing a symbol with
a dollar in _or_ if they've made a syntax error. I'll look into it more
and do some more testing.
I'm on 64 bit and I have to hack the makefiles to run the assembly tests
because they are written in 32-bit x86. Does anyone have a 32-bit
machine they are testing tcc on?
- Dan
On 11/04/15 14:09, Sergey Korshunoff wrote:
Hi!
although in almost all cases it is enabled by default
This can be done by using FD_INVERT insteed of 0 in the patch. But
keeping an old behavior of the tcc is safer (I think).
so they also provide -fno-dollars-in-identifiers
this works in tcc too. Try to test.
2015-04-11 14:49 GMT+03:00, Daniel Holden s0822...@staffmail.ed.ac.uk:
Hi,
I like the idea of using std=c99 to disable. I believe this is how
gcc/clang handle it. But ultimately I don't mind too much. gcc/clang use
the switch -fdollars-in-identifiers (I've attached a modified patch)
although in almost all cases it is enabled by default so they also
provide -fno-dollars-in-identifiers.
https://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html
I'm mainly interested in this change because I'm working on a new
version of my library Cello: http://libcello.org/ which uses `$` and
several variations of as macros. There is also RayLanguage which also
uses it as a macro for a kind of ObjC style message passing:
https://github.com/kojiba/RayLanguage . But I can also put together some
test cases using it in the various ways (variable, function, macro,
define, etc) so make sure it is completely covered.
Thanks,
Dan
On 11/04/2015 10:00, Thomas Preud'homme wrote:
Le samedi 11 avril 2015, 06:14:04 Sergey Korshunoff a écrit :
Hi! A modified version of the patch is attached.
Looks good at quick look. I'm not sure about the switch, we already
accept
some gnu extension without any switch for that. Or maybe introduce a more
general switch for all C extensions. You could enable it by default en
disable
it if std=c99 for instance?
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
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
--- ../tcc-0.9.26/tcc.h 2013-02-15 14:24:00.0 +
+++ tcc.h 2015-04-13 15:15:07.421945189 +0100
@@ -528,6 +528,7 @@
/* C language options */
int char_is_unsigned;
int leading_underscore;
+int dollars_in_identifiers; /* allows '$' in indentifiers */
/* warning switches */
int warn_write_strings;
@@ -1083,6 +1084,7 @@
returned at eof */
#define PARSE_FLAG_ASM_COMMENTS 0x0008 /* '#' can be used for line comment */
#define PARSE_FLAG_SPACES 0x0010 /* next() returns space tokens (for -E) */
+#define PARSE_FLAG_ASM0x0020 /* currently parsing assembly */
ST_FUNC TokenSym *tok_alloc(const char *str, int len);
ST_FUNC char *get_tok_str(int v, CValue *cv);
--- ../tcc-0.9.26/libtcc.c 2013-02-15 14:24:00.0 +
+++ libtcc.c 2015-04-13 15:15:33.357944813 +0100
@@ -1423,6 +1423,7 @@
{ offsetof(TCCState, char_is_unsigned), FD_INVERT, signed-char },
{ offsetof(TCCState, nocommon), FD_INVERT, common },
{ offsetof(TCCState, leading_underscore), 0, leading-underscore },
+{ offsetof(TCCState, dollars_in_identifiers), 0, dollars-in-identifiers },
};
/* set/reset a flag */
--- ../tcc-0.9.26/tccpp.c 2013-02-15 14:24:00.0 +
+++ tccpp.c 2015-04-13 15:19:16.425941580 +0100
@@ -2178,7 +2178,12 @@
}
}
break;
-
+
+/* allow $ in identifiers when not parsing asm */
+case '$':
+if (!tcc_state-dollars_in_identifiers
+|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
+
case 'a': case 'b': case 'c': case 'd':
case 'e': case 'f': case 'g': case 'h':
case 'i': case 'j': case 'k': case 'l':
@@ -2477,8 +2482,8 @@
case ':':
case '?':
case '~':
-case '$': /* only used in assembler */
-case '@': /* dito */
+case '@': /* only used in assembler */
+parse_simple:
tok = c;
p++;
break;
@@ -3049,7 +3054,8 @@
/* init isid table */
for(i=CH_EOF;i256;i++)
-
