[Tinycc-devel] Some fixes for x86_64 and general code to enable compiling GCC
Hi,
I was bored the last weekend and stumbled over tinycc, tried compiling GCC with
it, which breaks in multiple ways, sometimes not parsing stuff, sometimes
miscompiling it, and thought about hacking some other compiler than GCC :) I
just pushed nine patches to mob to fix all the problems I encountered (also
attached for reference).
I've added testcases for all the issues to tcctest.c.
I can now build current GCC (well, r186469 plus a modification, see below) with
tinycc on x86_64 (all language frontends written in C, i.e. c, c++, objc,
objc++ and fortran), and that so built GCC is able to compile all its own
target libraries.
The nice thing is that I even found a real bug in GCC (fixing it is required to
make it work with tinycc on x86_64), which I'm going to apply upstream later,
but for completeness I attach it here too in case anyone wants to play with it
right now (fix-diag-vaend.diff) :)
Have fun,
Michael.From 6471ec0a2bd523edd4bbc79277a33d0b853940fa Mon Sep 17 00:00:00 2001
From: Michael Matz m...@suse.de
Date: Sat, 14 Apr 2012 23:50:21 +0200
Subject: [PATCH 1/9] Fix conversion in a?0:ptr.
(cond ? 0 : ptr)-member wasn't handled correctly. If one arm
is a null pointer constant (which also can be a pointer) the result
type is that of the other arm.
---
tccgen.c| 19 ++-
tests/tcctest.c | 13 +
2 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/tccgen.c b/tccgen.c
index 5aa21c6..b0cec4a 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -1489,7 +1489,8 @@ static inline int is_null_pointer(SValue *p)
if ((p-r (VT_VALMASK | VT_LVAL | VT_SYM)) != VT_CONST)
return 0;
return ((p-type.t VT_BTYPE) == VT_INT p-c.i == 0) ||
-((p-type.t VT_BTYPE) == VT_LLONG p-c.ll == 0);
+((p-type.t VT_BTYPE) == VT_LLONG p-c.ll == 0) ||
+ ((p-type.t VT_BTYPE) == VT_PTR p-c.ptr == 0);
}
static inline int is_integer_btype(int bt)
@@ -4116,14 +4117,22 @@ static void expr_cond(void)
(t2 (VT_BTYPE | VT_UNSIGNED)) == (VT_LLONG | VT_UNSIGNED))
type.t |= VT_UNSIGNED;
} else if (bt1 == VT_PTR || bt2 == VT_PTR) {
-/* XXX: test pointer compatibility */
-type = type1;
+ /* If one is a null ptr constant the result type
+ is the other. */
+ if (is_null_pointer (vtop))
+ type = type1;
+ else if (is_null_pointer (sv))
+ type = type2;
+/* XXX: test pointer compatibility, C99 has more elaborate
+ rules here. */
+ else
+ type = type1;
} else if (bt1 == VT_FUNC || bt2 == VT_FUNC) {
/* XXX: test function pointer compatibility */
-type = type1;
+type = bt1 == VT_FUNC ? type1 : type2;
} else if (bt1 == VT_STRUCT || bt2 == VT_STRUCT) {
/* XXX: test structure compatibility */
-type = type1;
+type = bt1 == VT_STRUCT ? type1 : type2;
} else if (bt1 == VT_VOID || bt2 == VT_VOID) {
/* NOTE: as an extension, we accept void on only one side */
type.t = VT_VOID;
diff --git a/tests/tcctest.c b/tests/tcctest.c
index f0d82cf..723adc1 100644
--- a/tests/tcctest.c
+++ b/tests/tcctest.c
@@ -2486,3 +2486,16 @@ void const_warn_test(void)
{
const_func(1);
}
+
+struct condstruct {
+ int i;
+};
+
+int getme (struct condstruct *s, int i)
+{
+ int i1 = (i == 0 ? 0 : s)-i;
+ int i2 = (i == 0 ? s : 0)-i;
+ int i3 = (i == 0 ? (void*)0 : s)-i;
+ int i4 = (i == 0 ? s : (void*)0)-i;
+ return i1 + i2 + i3 + i4;
+}
--
1.7.3.4
From 5c0a2366a3bb5bdeb3b3617389d4584375d5bfbc Mon Sep 17 00:00:00 2001
From: Michael Matz m...@suse.de
Date: Sun, 15 Apr 2012 01:06:46 +0200
Subject: [PATCH 2/9] Fix bitfield loads into char/short.
Removes a premature optimization of char/short loads
rewriting the source type. It did so also for bitfield
loads, thereby removing all the shifts/maskings.
---
tccgen.c|5 +++--
tests/tcctest.c |5 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/tccgen.c b/tccgen.c
index b0cec4a..2c759e1 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -2320,8 +2320,9 @@ ST_FUNC void vstore(void)
ft = vtop[-1].type.t;
sbt = vtop-type.t VT_BTYPE;
dbt = ft VT_BTYPE;
-if (((sbt == VT_INT || sbt == VT_SHORT) dbt == VT_BYTE) ||
-(sbt == VT_INT dbt == VT_SHORT)) {
+if sbt == VT_INT || sbt == VT_SHORT) dbt == VT_BYTE) ||
+ (sbt == VT_INT dbt == VT_SHORT))
+ !(vtop-type.t VT_BITFIELD)) {
/* optimize char/short casts */
delayed_cast = VT_MUSTCAST;
vtop-type.t = ft (VT_TYPE ~(VT_BITFIELD | (-1 VT_STRUCT_SHIFT)));
diff --git a/tests/tcctest.c b/tests/tcctest.c
index 723adc1..afb0825 100644
--- a/tests/tcctest.c
+++ b/tests/tcctest.c
@@ -1461,6 +1461,8 @@ void c99_bool_test(void)
void bitfield_test(void)
{
int a;
+short sa;
+unsigned char ca
Re: [Tinycc-devel] Some fixes for x86_64 and general code to enable compiling GCC
Hi, On Sat, 21 Apr 2012, grischka wrote: I can now build current GCC (well, r186469 plus a modification, see below) with tinycc on x86_64 (all language frontends written in C, i.e. c, c++, objc, objc++ and fortran), and that so built GCC is able to compile all its own target libraries. If practicable, could you post the recipe that you used to build GCC with TCC? (If it is a script you might just push it into our 'tests' directory. There is already gcctestsuite.sh) No script. Just: from directory in which `pwd`/gcc is the top-level dir of checked out gcc: % mkdir devtcc; cd devtcc % CC=/matz/git/tinycc/tcc -B/matz/git/tinycc/ ../gcc/configure \ --disable-bootstrap --enable-languages=c,c++,fortran,java,objc % make -j8 Recent checkouts of GCC will also have the va_arg fix already applied, so it should build well out of box with tcc's mob branch. Note that I checked only the above self-build of gcc (i.e. including building its own runtime libs), I didn't run the testsuite; weekend was running out :) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] env executable examples
Hi, On Thu, 10 May 2012, grischka wrote: [1] See commit 27a428cd0fae475d7377e1dbe218c064ee217d85 Basically /usr/bin/env tcc -run will try to find tcc -run which is then obviously not found. Should we go back to the solution proposed in [2] or do you have another idea? Why not use just #!tcc -tun Because shebangs are interpreted by the kernel VFS, which doesn't know about $PATH, and hence won't find 'tcc' in any path (and therefore the execution will fail). That's what env(1) was intended for, but the linux kernel unfortunately supports only exactly one (optional) argument for the interpreter, i.e. it breaks with two and more arguments like when the shebang is #!env firstarg secondarg. So, all in all, when you use an meta-interpreter (like env) that somehow needs the name of the real interpreter as argument (tcc in this case) you can't give further arguments to that real interpreter (-run here). Otherwise I'd suggest to revert to the original #!/usr/local/bin/tcc -tun Which again would have the problem of hardcoding the path to tcc into the scripts. You need a meta-interpreter for finding the name of the real interpreter, and you can't give further arguments to it. Hence the best suggestion up to now was to create a wrapper script called tcc-run (just calling exec tcc -run $1 on its argument), which would be used as argument to the 'env' shebang. Of course, one could also decide to not care, but IMHO Davids above suggestion (helper script) is the most satisfying one, given the sorry circumstances. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc x86-64 and gawk - progress
Hi, On Thu, 3 May 2012, arn...@skeeve.com wrote: The one remaining test failure seems to be related to handling NaN floating point values. Here is the diff of the test results. NaN handling was totally hosed for x86_64. Update your checkout of mob branch, I fixed it. I've added an fairly extensive test function for all code paths that TCC might use to expand the various comparison constructs. This might introduce failures on the other targets which I can't test (i.e. other than x86_64 or i386). If so, they are equally broken regarding comparison behaviour with NaNs according to IEEE fp. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Github
Hi, On Mon, 14 May 2012, Karl Skomski wrote: Hi, I discovered tinycc some days ago but only today I discovered the current development repository: http://repo.or.cz/w/tinycc.git It's not that easy to find the most-updated tinycc repository. I thought maybe it would be nice to switch the tinycc repository to a github organization? How exactly would that help spreading interest (except in github)? Apart from that: does github have kind of like mob branches by default? Because, quite frankly, that's the only reason I contributed anything, however small, back to tinycc. If it hadn't I still would have had fun for a weekend fixing tcc, just without anybody gaining anything from it, as my patches would have never seen anybody else, and nobody would have seen them. Higher google rank, Huh? So you think google is giving points for github, but not for repo.or.cz (the best), or gitorious or any of the others? Proof? nice readme, Doesn't write itself, no matter the VCS. So how does a new VCS magically help? easier collaborating, How exactly easier than today? easier forks Well, I'm not exactly fluent in git (actually I hate its usability, which is next to non-existent), but what's difficult with git checkout -b? etc. Aha. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] question about bit-fields
Hi, On Sun, 27 May 2012, Rick Hodgin wrote: Didier, You're able to take the code and modify that requirement. It seems straight-forward enough that TinyCC is (in memory at compile-time) determining the target size, regardless of the storage size, and using that for the storage size in memory. You could alter that code to always use the smallest storage-size, and automatically upsize to the larger form, such as something stored as 1..7 bits always being stored as a single byte, even if it's scoped as an int. If one changes anything at all then it only makes sense to change it so as to be layout compatible with GCC. A third layout (GCC, TCC-old, TCC-new) wouldn't help. Although the rules of GCC are relatively obscure and complex in corner cases. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] question about bit-fields
Hi, On Sun, 27 May 2012, Michael Matz wrote: If one changes anything at all then it only makes sense to change it so as to be layout compatible with GCC. A third layout (GCC, TCC-old, TCC-new) wouldn't help. Although the rules of GCC are relatively obscure and complex in corner cases. Actually I have to correct myself here. After studying the layout code a bit I see that TCC implements mostly microsoft's bit-field layout. We don't want to get rid of that capability, so GCCs layout (which is PCC layout for i386 and arm AAPCS, and funky layout for legacy arm) would have to be implemented in addition. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] overflow in R_X86_64_PC32 relocations
Hi, On Thu, 31 May 2012, Thomas Preud'homme wrote: I've just received a bug report [1] about overflow occuring with R_X86_64_PC32 relocations when a library is compiled with tcc. Yep, shared libraries on x86-64 don't work correctly with TCC. It emits non-PIC code, which is fine for x86, but isn't for x86-64. One symptom are these overflows. Maybe one rainy weekend ... :) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug: malloc + function returning double + comparison between doubles
Hi, On Sat, 9 Jun 2012, g...@sdf.org wrote: d = malloc (s); If this returns a pointer with upper 32 bits set (which depends on malloc size, fragmentation and moon phase) ... d[0] = 10.0; i = d[0] f (); ... those are lost in the caller-save/restore code for the address of d[0] generated because of the call to f. This is because the reload was done in VT_INT mode, not VT_PTR as it should have been. I fixed it on the mob branch with a hopefully more reliable testcase using alloca (which on x86-64 will always return a pointer with high 32 bit set because the stack will be set up that way). Thomas: as you were last fiddling with arm, you might want to check if the test works on it. The other alloca testcase is #ifdef'ed on i386 and x86_64, but that only makes sense if alloca really isn't supported on arm, which I can't believe. If that really is the case callsave_test() needs to be conditional too. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug: malloc + function returning double + comparison between doubles
Hi, On Sun, 10 Jun 2012, Daniel Glöckner wrote: On Sun, Jun 10, 2012 at 09:15:52AM +0200, Michael Matz wrote: Thomas: as you were last fiddling with arm, you might want to check if the test works on it. The other alloca testcase is #ifdef'ed on i386 and x86_64, but that only makes sense if alloca really isn't supported on arm, which I can't believe. If that really is the case callsave_test() needs to be conditional too. Some time ago I posted an alloca version for ARM: http://lists.nongnu.org/archive/html/tinycc-devel/2011-02/msg00046.html Ah, I see. Well, alloca is highly desirable to have IMHO, so ... but we don't build a libtcc1 for ARM ... I think we should do so then. As it seems the various arithmetic routines of libtcc1.c aren't needed on arm it would only contain alloca. I'd vote for the assembler implementation (don't know if it would have to differ between the eabi and oldabi variants). Ciao, Michael.___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug: malloc + function returning double + comparison between doubles
Hi, On Sun, 10 Jun 2012, Daniel Glöckner wrote: Compiler generated calls have been chosen to allow the use of libgcc_s.so.1 on ARM EABI and OABI. It is needed for divisions, 64-bit shifts, and some floating point conversion. One day we might also support devices without floating point hardware/emulator, where we could use the EABI soft float functions already contained in libgcc. I also added a configure option --with-libgcc to make TinyCC automatically link to libgcc_s.so.1 instead of libtcc1.a. If we now start to supply a libtcc1.a that does not include the functions from libgcc_s.so.1, we need to link to two libraries. But that's no problem, is it? Alternatively alloca could be expanded inline at a (small) code size cost, but I think a libtcc1.a makes sense even when using libgcc_s (the former being the tinycc internals libs, the latter being a conveniently supported 3rd party lib). Ciao, Michael.___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc_relocate() and tcc_relocate_ex()
Hi, On Mon, 27 Aug 2012, grischka wrote: Can you at least commit the change that makes tcc_relocate_ex() global? Yes, perhaps at least. You wrote: ... but fixing my code to match the current definition of tcc_relocate() was out of the question (the surrounding code manages the lifetime of both the TCCState and the resulting executable code compiled into memory). I'd actually like to know some details why you can't just use tcc_relocate()? So Sean meanwhile answered this extensively, but I'd actually ask back why the answer to this question matters? The _ex function exposes a strict superset of possibilities of the non _ex variant, that much is very obvious, so asking why the more limited API isn't enough for everyone, when it once was more capable and actually used in that extended fashion seems patronizing to me. There's clearly a use for the extended API (clearly in the sense, it once worked, now with the limited API it doesn't, and I don't see how to work around the limitation with the current API), and exporting the relevant, though renamed symbol, isn't affecting the future of libtcc stability, insofar it exists (which it doesn't), at all. So, while the complaint about the leak is correct, the conservatism about exporting one internal function (whose functionality once was available as an exported function that was removed from the API) is hypocritic at best. Sorry for that assessment. IOW: I don't understand your reservations. To make it short: just export the damn thing. It makes sense. Admittedly we know little about how people actually use the libtcc API. Well, we now know a little bit more. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc_relocate() and tcc_relocate_ex()
Hi, On Wed, 29 Aug 2012, grischka wrote: What about this: Keep the 0.9.25 declaration of tcc_relocate, which was: Sure. Keep tcc_relocate with its current signature. /* copy code into memory passed in by the caller and do all relocations (needed before using tcc_get_symbol()). returns -1 on error and required size if ptr is NULL */ LIBTCCAPI int tcc_relocate(TCCState *s1, void *ptr); but define a special value for 'ptr' to get behavior as of 0.9.24, as in: /* Do all relocations. Needed before using tcc_get_symbol(). Possible values for ptr: - TCC_RELOCATE_AUTO : Allocate memory internally - NULL : return required memory size for the step below - memory address: copy code into memory passed by the caller returns -1 on error. */ LIBTCCAPI int tcc_relocate(TCCState *s1, void *ptr); #define TCC_RELOCATE_AUTO (void*)-1 Is this ugly? Confusing? 0.9.26 isn't out yet so we can still decide. You earnestly added this interface abomination to avoid exporting a function? I mean, huh? Well, as you asked: yes it's ugly, and yes it's confusing. (and it's also non-C, ((void*)-1) might not be representable; the only integer literal that definitely is convertible into a pointer is 0; but I'll admit that this would just be a nitpick). But why you think this interface would be better than an explicit one with two functions is a complete mystery to me. I mean, really, can you give a reason? I'm seriously interested. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Hi,
On Wed, 16 Jan 2013, Thomas Preud'homme wrote:
$ cat long_long.c
#include stdio.h
int main(void)
{
char *p = NULL;
p -= 0x7042;
/* from pointer to integer types */
printf(%d %d %ld %ld %lld %lld\n,
(int)p, (unsigned int)p,
(long)p, (unsigned long)p,
(long long)p, (unsigned long long)p);
return 0;
}
Pointer to integer conversions (and back) are implementation defined, the
only requirement being that if the integer type is (u)intptr_t that a
pointer converted to that one and back to a pointer shall compare equal to
the original pointer.
So, depending on how the compiler implements this conversion (and
documents this) one might get different results:
$ gcc -o long_long long_long.c ./long_long
[SNIP gcc warnings]
-66 -66 -66 -66 -66 -66
This is a correct result for ILP32 (i.e. 32bit code). GCC sign extends
pointers when the pointer representation needs fewer bits than the target
type.
$ clang -o long_long long_long.c ./long_long
-66 -66 -66 -66 4294967230 4294967230
And this is also a correct result for 32bit code, when the compiler
defines pointer to integer conversion to be zero-extending when the target
type has more bits than a pointer. IMO sign-extending is more useful, and
as GCC set the precedent a long time ago I would declare clang to at least
have an QoI issue with compatibility with GCC. In other words: tcc has no
bug here.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Small patch
Hi, On Thu, 31 Jan 2013, Vincent Lefevre wrote: In such a case, a default: at the end with an assertion failure would have been better. No. An assertion only makes sense to make sure about what we aren't entirely sure. In this case we are sure (that default never happens). You are sure *now*. But imagine that in the future you modify the if at the beginning of the loop to add a 4th operator but you forget to modify the switch... BTW, since you are sure now and think an assert is useless anyway, removing the default: (or adding an empty default: at the end) now should be completely safe. It will lead to slower and/or larger code to add a default case with a separate body. The current way of doing it is IMO the exactly correct way. If people are really confused by that, put a comment next to the 'default:'. Generally stylistic warnings of coverity (and actually not just stylistic things) have to be taken with a huge amount of salt. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] What C version tcc is supposed to implement?
Hello Christian,
Am 16.02.2013 12:04, schrieb Christian Jullien:
tcc_define_symbol(s, __STDC_VERSION__, 199901L);
This define pretends it is ISO/IEC 9899:1999 (E)
Strictly speaking that's optimistic, because it also depends on the C
library on which tcc has no influence (some embedded C libs can be
configured to not support wchar for instance). But in your case it's
simply an error on your part.
Because __STDC_VERSION__ is set to 199901L
This code should be legal:
It's legal, but doesn't do what you want:
int main()
{
When a program is started stdout/err/in have no orientation yet. The
first input/output operation determines which orientation it gets ...
#if defined(__STDC_VERSION__) (__STDC_VERSION__ = 199901L)
wchar_t* s = LABCDEFGHIJKLMNOPQRSTUVWXYZ;
char* p = (char*)s;
printf(%x %x %x %x\n, p[0],p[1],p[2],p[3]);
... and printf is byte-oriented, so stdout will from now on be
byte-oriented, and the string is output...
printf(%x %x %x %x\n, p[4],p[5],p[6],p[7]);
... stdout is byte-oriented, printf is byte-oriented, so the string is
output ...
wprintf(LHello World\n);
... and this doesn't work, because stdout is byte-oriented, but wprintf
requires a stream that isn't byte-oriented. If you had checked for
errors you would have seen one. Once a stream has an orientation it
can't be switched anymore. Remove the printf's and leave only wprintf
and it works. Alternatively if you want to output wide characters on a
byte-oriented stream use printf and %ls. For the whole background see
fwide(3) and wprintf(3).
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] What C version tcc is supposed to implement?
Am 16.02.2013 20:16, schrieb Christian Jullien: Thank you Michael, I'm really sorry, my intention was not that someone tried to debug this silly program. The purpose of this small program was to illustrate that I don't know what C version tcc is supposed to implement, with which feature. I admit that this quick and dirty program is odd. If __STDC_VERSION__ is set to 199901L we can assume that other features of ISO/IEC 9899:1999 (E) are present which it not true. Then you have to be a bit more specific about which features you're missing, as wchar_t's aren't. There are of course some, but usually arcane ones that even GCC doesn't implement (e.g. strict adherence to the floating point environment model, and the associated pragmas). I can tell you that tcc aims to implement c99 (when reasonably possible), so setting __STDC_VERSION__ to the value it has right now is sensible. Not necessarily all optional features of it (e.g. _Complex support is missing right now, but that's mentioned in the TODO). You cited some macros that are supposed to be set, and the state of them is: __STDC__ : set correctly __STDC_VERSION__ : set correctly __STDC_HOSTED__ : not set (incorrectly, it should probably be set to 1 given that tcc assumes a normal main() and that the rest of the provided facilities is provided by the C library not under tcc control) __STDC_IEC_559__ : Optional, correctly not set __STDC_IEC_559_COMPLEX__ : Optional, correctly not set __STDC_ISO_10646 : Optional, setting it would require quite some testing because it would have to be matched against a certain version of the 10646 standard. Not much value in doing that. So, in short, if your question was really only the subject: tcc aims to a large subset of ISO/IEC 9899:1999, hosted implementation, minus _Complex and minus IEC 559. Modulo bugs, and modulo missing features I forgot :), if you have any specific in mind, tell us. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] What C version tcc is supposed to implement?
Am 17.02.2013 19:46, schrieb Thomas Preud'homme: Le samedi 16 février 2013 21:17:32, Michael Matz a écrit : __STDC_HOSTED__ : not set (incorrectly, it should probably be set to 1 given that tcc assumes a normal main() and that the rest of the provided facilities is provided by the C library not under tcc control) So what do you think of the attached patch? Makes sense IMO. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] va_* broken on x86-64: any volonteer? (fwd)
Hi, [resent because my work email is not subscribed here :-/] On Thu, 9 Jan 2014, Thomas Preud'homme wrote: That's because GCC doesn't have any problem. The problem is in TinyCC. I was compiling mksh with TinyCC (I called it tcc in my initial mail) and it gave me linker error about undefined __va_arg if I remember correctly. Are you sure it's not a bug in mksh, and in which version anyway? The stdarg testcases from the testsuite all work just fine. I can also build mksh-R48b with tcc just fine: % uname -a % cd /matz/git/tinycc; git log --online HEAD^.. 767410b Various Makefile fixes for cross-compilation % ./configure; make; make test ... all works ... % cd /tmp/ % tar xvf mksh-R48b.tgz % mkdir mksh/build; cd mksh/build % CC=/matz/git/tinycc/tcc -B/matz/git/tinycc/ /bin/sh ../Build.sh ... Run the regression test suite: ./test.sh Please also read the sample file dot.mkshrc and the fine manual. % ./mksh ./test.sh ... Total failed: 0 Total passed: 466 So, if you want anything fixed we'd first need to know what is broken, e.g. a testcase ;) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] va_* broken on x86-64: any volonteer?
Hi, [bah, resent again because of suse.de not being the subscribed address here :-/ ] On Thu, 9 Jan 2014, Thomas Preud'homme wrote: Oh I see. I compiled with --with-libgcc and gcc doesn't provide __va_* like libtcc1 does. So I guess either libgcc should not be proposed for x86-64 systems or libtcc1 should always be linked in as well as to fill in the blank. Yeah. tcc meanwhile also emits references to other symbols that aren't in libgcc. E.g. __floatundixf. Or maybe now that arm can uses libtcc1 this option could be just removed. If there is some value in keeping it, it could also be nice that tcc can work directly with libgcc (and thus have va_* macros builtin, see stdarg.h from gcc and gcc's source code). You can't without providing the implementation currently residing in libtcc directly as inline variant in the code generator (as libgcc doesn't contain any implementation of that stuff). As the x86_64 variant of stdargs is a bit convoluted (as in, more that three/four instructions) that doesn't seem like the best solution. So, ... Dear users, does any of you see value in the --with-libgcc switch of configure? ... if the possibility of using libgcc should be retained, then yes, libtcc needs to be linked in additionally. Which seems to make sense as that lib indeed is supposed to provide the runtime parts that the compiler (here tcc) specifically wants to rely on. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Use an anonymous file to back mmap
Hi, On Thu, 9 Jan 2014, Keren Tan wrote: I just submitted a tentative patch to the mob branch about mmap. When selinux is enabled, tccrun.c uses mmap to hold the dynamically generated code/data. It is backed by a randomly named file under /tmp directory. My patch is to use an anonymous file in mmap instead, so that the generated code/data only resides in memory, and tcc does not depend on a writable /tmp anymore. It's customary to actually test changes before committing. In your case: % ./configure --with-selinux % make make test ... test3 ../tcc -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib64\ -DTCC_TARGET_X86_64 -DONE_SOURCE -run ../tcc.c -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib64\ -DTCC_TARGET_X86_64 -DONE_SOURCE -run ../tcc.c -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib64\ -DTCC_TARGET_X86_64 -DONE_SOURCE -run ../tcc.c -B.. -I.. -I.. -I../include -run tcctest.c test.out3 /bin/sh: line 1: 15954 Segmentation fault ../tcc -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib64\ -DTCC_TARGET_X86_64 -DONE_SOURCE -run ../tcc.c -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib64\ -DTCC_TARGET_X86_64 -DONE_SOURCE -run ../tcc.c -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib64\ -DTCC_TARGET_X86_64 -DONE_SOURCE -run ../tcc.c -B.. -I.. -I.. -I../include -run tcctest.c test.out3 make[1]: *** [test3] Error 139 This is no wonder because the former mmap mechanism had some special requirements mandated by SElinux that you ignored. Your patch basically did this: s1-write_mem = mmap (NULL, ret, PROT_READ|PROT_WRITE, -MAP_SHARED, fd, 0); +MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); ... s1-runtime_mem = mmap (NULL, ret, PROT_READ|PROT_EXEC, -MAP_SHARED, fd, 0); +MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); So it replaced two mmaps of the same region (the file), one mapping being writable (pointer to it in -write_mem), and another mapping being executable (pointer in -runtime_mem) by two completely unrelated anon mappings, one writable, one executable. The requirements of the whole things are such, that changes to the writable mapping via -write_mem need to be reflected in the mapping reachable via -runtime_mem. I.e. both mappings really need to be two views on _exactly_ the same data. Depending on the configuration of an SElinux system the following things might be disallowed: * creating mapping which is WRITE|EXEC * changing flags of an existing writable mapping to include EXEC when it didn't before (no matter if WRITE is now removed or not) The first means you won't get away with just a single mmap of some ANON|PRIVATE that is writable and executable. The second means you also don't get away with first mapping something writable, let tcc generate its code therein and then remap it executable (either via mprotect or mremap). That is you indeed need two separate mappings. And because both mappings need to be actually from the same underlying data they need to be related somehow. And the only way to relate two separate mappings is via a file descriptor and a MAP_SHARED mapping. IOW: the former way of mapping a writable and executable piece of memory via a shared mapping backed by a file is the only way that works in SElinux. And yes, that means it needs to have a place for that file, and it needs to be on a file system that isn't mounted noexec (i.e. /tmp might actually not be the right place). In still other words: please revert, sorry. :-/ tcc is fantastic! I am new to this community. Your comments are very welcome! Yeah, sorry to spoil the fun ;) Thanks for contributing, I hope the above at least explains things. Testing is the key :) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Use an anonymous file to back mmap
Hi, On Sat, 11 Jan 2014, Michael Matz wrote: I just submitted a tentative patch to the mob branch about mmap. When selinux is enabled, tccrun.c uses mmap to hold the dynamically generated code/data. It is backed by a randomly named file under /tmp directory. My patch is to use an anonymous file in mmap instead, so that the generated code/data only resides in memory, and tcc does not depend on a writable /tmp anymore. It's customary to actually test changes before committing. In your case: % ./configure --with-selinux % make make test ... test3 ../tcc -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib64\ -DTCC_TARGET_X86_64 -DONE_SOURCE -run ../tcc.c -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib64\ -DTCC_TARGET_X86_64 -DONE_SOURCE -run ../tcc.c -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib64\ -DTCC_TARGET_X86_64 -DONE_SOURCE -run ../tcc.c -B.. -I.. -I.. -I../include -run tcctest.c test.out3 /bin/sh: line 1: 15954 Segmentation fault ../tcc -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib64\ -DTCC_TARGET_X86_64 -DONE_SOURCE -run ../tcc.c -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib64\ -DTCC_TARGET_X86_64 -DONE_SOURCE -run ../tcc.c -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib64\ -DTCC_TARGET_X86_64 -DONE_SOURCE -run ../tcc.c -B.. -I.. -I.. -I../include -run tcctest.c test.out3 make[1]: *** [test3] Error 139 Actually I take back that this is caused by your change (it's not). I'll maintain that the change you introduced would break a very confined SElinux system for the stated reasons, _if it were working at all before your change_. But after some more poking I conclude the whole SElinux support seems to have either bitrotted or never was complete. In particular -runtime_mem (the mapping that's supposed to point to non-writable executable memory reflecting the same data as -write_mem) is never used anywhere in the SElinux case except for munmapping it again, and tcc tries to mprotect -write_mem also in the SElinux case to be WRITE|EXEC, which won't work for the reasons I mentioned in a very closed down SElinux system. That is all a preexisting problem, and from that perspective the whole initialization and separation of -runtime_mem and -write_mem is useless and merely confusing; it would probably be better to just do away with that and use just one mapping (WRITE|EXEC, and because it's only one it can then indeed be ANON) also in the SElinux case even though it wouldn't work for all situations, like before (well, of course even better would be to make the whole thing work for real even in a confined system :) ). Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] bug introduced by the latest changes
Hi, On Sat, 11 Jan 2014, Vincent Lefevre wrote: On 2014-01-11 22:39:28 +0800, Thomas Preud'homme wrote: Can you try a git bisect to see what commit introduced this bug? The last two commits. Fixed in mob. ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] signed zero handling is still buggy
Hi, On Sun, 12 Jan 2014, Vincent Lefevre wrote: There's still a bug related to signed zero support. I think I've fixed that now on mob [1]. In particular +x is regarded as no-op for floating point types (for integer types it's still x+0 so that the promotions still happen automatically). And unary -x is now expanded as subtract(-0,x) for floating point types (hacking in real support for unary operations would have been more complicated and would have entailed changes in all backends). I've also included your tests in tcctest.c. Ciao, Michael. [1] http://repo.or.cz/w/tinycc.git/commitdiff/05c9b76131e9d0 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] signed zero handling is still buggy
Hi, On Sun, 12 Jan 2014, Vincent Lefevre wrote: On 2014-01-12 04:59:06 +0100, Michael Matz wrote: I think I've fixed that now on mob [1]. In particular +x is regarded as no-op for floating point types (for integer types it's still x+0 so that the promotions still happen automatically). And unary -x is now expanded as subtract(-0,x) for floating point types (hacking in real support for unary operations would have been more complicated and would have entailed changes in all backends). subtract(-0,x) is OK in most cases, but in rounding toward -Inf, on -0, one would get -0 instead of +0. Yeah, I know, but tcc has many more problems with strict IEEE arithmetic and rouding modes, so I'll ignore that smallish aspect for now. Just don't switch rounding modes to -Inf when calculating -x ;-) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc bootstrap
Hi, On Mon, 10 Mar 2014, Christian Jullien wrote: Yes I fully agree that tcc should, by default, be a gcc compiled program. Also, as Patrick said, having tcc bootstrapped by itself has the following advantages: - it proves tcc is complete - it proves tcc does not use gcc extensions, or it implements extensions in a compatible way - it is a very good non-regression test - it allows to have a decent C compiler without the need to install huge gcc suite (useful on ARM boards) A ./configure --bootstrap may do the job. Guys, just look at the testsuite. It's part of that since a long time. test3 compiles tcctest by a tcc compiled by tcc compiled by tcc compiled by tcc (i.e. _four_ times, the comment above it is wrong). Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
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
Re: [Tinycc-devel] Zeroing stack variables CValue
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
Re: [Tinycc-devel] improving get_tok_str
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
Re: [Tinycc-devel] Zeroing stack variables CValue
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
Re: [Tinycc-devel] improving get_tok_str
Hi, On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote: It's not better to have two different functions/entry points, one for when we have/need a CValue and other without it ? Yes, that could be reasonable. OTOH to avoid code duplication the one without taking a CValue would be internally calling the one with a CValue (passing it a local faked one). (Or alternatively both would call an internal helper that expects one) And at that point I don't see much value in enlarging the API more, seeing a NULL in place of the CValue is equally clear to me like seeing a _nocval suffix on the function call name, but that's just IMHO. Ciao, Michael. ___ 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
Hi,
On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:
Thanks for pointing it and show an example to test !
Now going back to the original problem the original tcc implementation leaks
memory on:
void *__va_copy(struct __va_list_struct *src)
{
struct __va_list_struct *dest =
(struct __va_list_struct *)malloc(sizeof(struct __va_list_struct));
*dest = *src;
return dest;
}
No, that's not leaking memory, because a va_copy _must_ be paired with a
va_end call in client code. And that one will release the
allocated memory.
And I'll continue investigating a way to make it work with fossil-scm
for the X86_64, the problem that I saw is that there is a double free
when the process fork somehow the fossil compiled by tcc seem to not
duplicate the malloced strioneng and both the parent and child free the
same string.
That's no double free, because the process space will be unshared after
fork. I don't know what tool you used that pointed out a double free in
this specific situation, but if it really thought this situation is a
double free then it's buggy.
Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
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] x86_64: shared libs
Hi, I just pushed some things [1] to mob that make shared libs on x86-64 linux sort of working (well, in my little tests). It's not 100% conformant to the ABI yet, but hey, its late here :) i386 could now use some cleanups as well (so that it really generates PIC code, not that unsharing text-reloc containing code it currently emits). I have checked x86-64 (no testsuite bugs) and i386 (no _additional_ testsuite bugs), but not ARM. I tried to not change the latter, although it also contains dubious code (OTOH it currently doesn't support generated shared libs at all, so ...), but I might have unintentionally broken stuff. I had to extend struct sym_attr to contain a full plt_offset, not just a flag, it's really required. Shouldn't be too bad as it's created only for symbols that really take part in dynamic linking. Testing appreciated (hi Arnold :) ). Ciao, Michael. [1] http://repo.or.cz/w/tinycc.git/commitdiff/080ad7e6 http://repo.or.cz/w/tinycc.git/commitdiff/0bd12820 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] x86_64: shared libs
Hi, On Mon, 31 Mar 2014, Aharon Robbins wrote: Testing appreciated (hi Arnold :) ). This has certainly improved things; two tests that used to fail now pass, although two more continue to fail. If you want to test yourself, here's the recipe: git clone git://git.savannah.gnu.org/gawk.git cd gawk git checkout gawk-4.1-stable ./bootstrap.sh # due after clone or pull ./configure CC=tcc make make -k check # filefuncs and functab4 tests should fail This is really great progress, thanks! Thanks for the report. The cause is that libtcc1.a needs to contain position independend code as well (so that it may be linked into shared libraries). I've simply added -fPIC for compiling all components of it, which should be fine no matter if it's compiled by gcc or tcc. In any case the default config from tcc (mob branch as of ea2805f0) can now build gawk-4.1-stable without shared lib regressions (i.e. filefuncs and functab4 now work). I do see other tests fail as well: backbigs1, backsmalls1, mbfw1, mbprintf1 and mbprintf4; which seem to be locale dependend, but they work when compiling with gcc on my system. But seems unrelated to shared libs issues. Ciao, Michael. ___ 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
Hi, On Thu, 3 Apr 2014, Domingo Alvarez Duarte wrote: I propose to remove bounds check from tests/build till we have a good solution/implementation to it. Why should we? The checks are for features that are supposed to work. They did work once. They don't anymore. That's a regression. And the regression didn't happen because the testcase is invalid. So, I've probably broken something. Testcases can be disabled if there are known reasons why they currently can't possbily work. This is not one of the situations, the fails needs to be investigated first. Ramsay, thanks for the report, if nobody beats me, I'll look at details later the week. Probably something with how calls to internal functions are emitted. Ciao, Michael. ___ 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
Hello Ramsay, On Thu, 3 Apr 2014, Ramsay Jones wrote: After commit ea2805f (shared libs: Build libtcc1.a with -fPIC, 02-04-2014), this now fails like so: Fixed with 2024c445. Indeed PIC input wasn't handled correctly in connection with -run (emitting a real ELF executable worked). So the testsuite is now back to the state before ea2805f, that is known VLA 5 fail in test1b and known bad pointer in strlen() in test3b. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Fwd: Bug#675024: tcc: errors Symbol `mpfr_xxx' causes overflow in R_X86_64_PC32 relocation
Hi,
On Fri, 4 Apr 2014, Vincent Lefevre wrote:
Actually I just fixed a similar error for gawk (libtcc1.a containing non-PIC
code), which has exactly that symptom ('abort' and _PC32 reloc overflowing).
So it's worth a new try with mob branch.
This doesn't change anything in MPFR:
ypig:...ftware/mpfr/tests ./texceptions
./texceptions: Symbol `stderr' causes overflow in R_X86_64_PC32 relocation
./texceptions: Symbol `abort' causes overflow in R_X86_64_PC32 relocation
zsh: segmentation fault (core dumped) ./texceptions
Have you rebuilt libtcc1.a (e.g. make clean before redoing make in tcc)?
And reinstalled it? How did you configure tinycc? How did you configure
mpfr. Because I can't reproduce:
% tcc ./configure make -j8
% tcc cd /tmp/mpfr-3.1.2
% mpfr-3.1.2 CC=/matz/git/tinycc/tcc -B/matz/git/tinycc/ ./configure
...
% mpfr-3.1.2 make -j8 make check
...
[tversion] GMP: header 5.0.2, library 5.0.2
[tversion] MPFR tuning parameters from default
PASS: tversion
All 160 tests passed
(1 test was not run)
...
(The skipped test is tget_set_d64). In particular:
% mpfr-3.1.2 cd tests ./texceptions
% tests echo $?
0
% ldd ./texceptions
linux-vdso.so.1 = (0x7fffd336f000)
libm.so.6 = /lib64/libm.so.6 (0x7f36ffd28000)
libc.so.6 = /lib64/libc.so.6 (0x7f36ff9bb000)
libmpfr.so.4 = /tmp/mpfr-3.1.2/src/.libs/libmpfr.so.4
(0x7f36ff714000)
libgmp.so.10 = /usr/lib64/libgmp.so.10 (0x7f36ff496000)
/lib64/ld-linux-x86-64.so.2 (0x7f36fff7f000)
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] x86_64: shared libs
Hi, On Fri, 4 Apr 2014, grischka wrote: Question apropos: On linux x86_64 there is still the ugly runtime_plt_and_got hack which is a replacement for PLT in the tcc -run case to forward 32bit calls to extern libraries. On win64 the same problem is solved by building the IAT (import address table) also in the -run case. From your estimation, would it be possible to do the same on ELF? That is build the PLT/GOT as if we were making an executable and then use that with tcc -run? Yes, that's something on my TODO. Theoretically having runtime_plt_and_got makes code emission a tiny bit faster because having a proper PLT and GOT also for -run means first creating and second applying intermediate relocations (the _GLOB_DAT and _JUMP_SLOT relocs), which is cut short with the hack. OTOH removing the hack would remove deviation depending on output type, so I think it's a good idea nevertheless. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] x86_64: shared libs
Hi, On Fri, 4 Apr 2014, Michael Matz wrote: Yes, that's something on my TODO. Theoretically having runtime_plt_and_got makes code emission a tiny bit faster because having a proper PLT and GOT also for -run means first creating and second applying intermediate relocations (the _GLOB_DAT and _JUMP_SLOT relocs), which is cut short with the hack. OTOH removing the hack would remove deviation depending on output type, so I think it's a good idea nevertheless. Done now. For x86_64 and ARM, where the latter required me to extend the current relocation support to some more cases. To test the latter I used gawk and mpfr, for which I had to add alloca support to ARM. So I'm reasonably sure that my changes don't cause regressions, but from reading the code there's still potential to fix more things (and of course to implement ARM shared libs). One of those days ... Ciao, Michael. ___ 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
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
Re: [Tinycc-devel] Building a single cross-compiler: please test new configure
Hello Thomas, On Wed, 9 Apr 2014, Thomas Preud'homme wrote: I have a patch to build a single cross-compiler by using --targetcpu but given the potential of breakage of the build script I prefer to post it here for now and ask you to try building tcc with it, either natively or all the cross compilers to see if anything break. You can also try building a single compiler to see if it works for you or take a look at the patch. Any feedback welcome. No cake yet, there are multiple problems. Some of them are fixed by the attached second version of that patch (which applies on top of current mob). The changes are: * inconsistent use of X64, x86_64 and x86-64. This now matters because sometimes directory names implies make targets and variables now. I've settled on x86_64, because from that we can infer also C macros * configure would unconditionally put #define TCC_TARGET_$ARCH in config.h. When building cross compilers that would define the native arch and the cross arch for the same executable. So go back to adding the right define in the Makefile * The correct spelling of the make function is 'filter-out' (not with underscore) * libtcc1.c needs access to size_t also for cross environment (no idea why it would be there before the patch), so include stddef.h With that patch the following works on an x86_64 host: % ./configure make make test and % linux32 ./configure CC=gcc -m32 \ sed -i -e 's/lib64/lib/' config.mak \ linux32 make CFLAGS=-g CC=gcc -m32 \ linux32 make CFLAGS=-g CC=gcc -m32 -k test I.e. the two native compilers for such host. Some host compilers compile as well: % ./configure --targetcpu=i386 make The resulting i386-tcc cannot build binaries (with ./i386-tcc -B./ because libtcc1.a isn't found (seems it's not searched in ./lib/i386). This works before the patch. Similar this other cross compiler: % linux32 ./configure CC=gcc -m32 --targetcpu=x86_64 make Produces a 32bit x86_64-tcc executable (correct), which can't link executables, because it searches in /usr/lib for crt[1in].o and doesn't find libgcc1.a Also: % ./configure --enable-cross make ... make -C lib cross TARGET=i386-win32 PROG_CROSS= make[1]: Entering directory `/matz/git/tinycc/lib' ../ -B../win32 -I../include -c libtcc1.c -o i386-win32/libtcc1.o -I.. -g -DTCC_TARGET_I386 -DTCC_TARGET_PE make[1]: execvp: ../: Permission denied make[1]: *** [i386-win32/libtcc1.o] Error 127 make[1]: Leaving directory `/matz/git/tinycc/lib' make: *** [lib/i386-win32/libtcc1.a] Error 2 This points to a general problem in how the Makefile infers some names for the compiler to build the target lib. You have: lib/%/libtcc1.a : FORCE $(filter $*%,$(PROGS_CROSS)) $(MAKE) -C lib cross TARGET=$* PROG_CROSS=$(filter $*%,$(PROGS_CROSS)) The '%' is i386, i386-win32, x86_64-win32, x86_64 and arm. But in $(PROGS_CROSS) there is only i386-w64-mingw32-tcc which doesn't match i386-win32. With arm it's even worse, because there we have four cross compilers in PROGS_CROSS, that all match arm%. So, that needs some more work still. I've attached the patch I have up to now (need to leave now). The result of interdiff of both patches (yours vs. mine) is below to easier see what exactly I've changed relative to yours. Thanks for starting to clean up the cross stuff. Ciao, Michael. - diff -u b/Makefile b/Makefile --- b/Makefile +++ b/Makefile @@ -67,6 +67,7 @@ NATIVE_DEFINES_$(CONFIG_arm_eabi) += -DTCC_ARM_EABI NATIVE_DEFINES_$(CONFIG_arm_vfp) += -DTCC_ARM_VFP NATIVE_DEFINES += $(NATIVE_DEFINES_yes) +NATIVE_DEFINES += -DTCC_TARGET_$(ARCH) ifeq ($(TOP),.) @@ -74,7 +75,7 @@ WIN32_CROSS = i386-w64-mingw32-tcc$(EXESUF) WIN64_CROSS = x86_64-w64-mingw32-tcc$(EXESUF) WINCE_CROSS = arm-wince-mingw32ce-tcc$(EXESUF) -X64_CROSS = x86_64-linux-gnu-tcc$(EXESUF) +X86_64_CROSS = x86_64-linux-gnu-tcc$(EXESUF) ARM_FPA_CROSS = arm-linux-fpa-tcc$(EXESUF) ARM_FPA_LD_CROSS = arm-linux-fpa-ld-tcc$(EXESUF) ARM_VFP_CROSS = arm-linux-gnu-tcc$(EXESUF) @@ -88,7 +89,7 @@ $(WIN32_CROSS)_LINK = i386-win32-tcc$(EXESUF) $(WIN64_CROSS)_LINK = x86_64-win32-tcc$(EXESUF) $(WINCE_CROSS)_LINK = arm-win32-tcc$(EXESUF) -$(X64_CROSS)_LINK = x86_64-tcc$(EXESUF) +$(X86_64_CROSS)_LINK = x86_64-tcc$(EXESUF) $(ARM_FPA_CROSS)_LINK = arm-fpa-tcc$(EXESUF) $(ARM_FPA_LD_CROSS)_LINK = arm-fpa-ld-tcc$(EXESUF) $(ARM_VFP_CROSS)_LINK = arm-vfp-tcc$(EXESUF) @@ -107,7 +108,7 @@ I386_LIBTCC1_CROSS=lib/i386/libtcc1.a WIN32_LIBTCC1_CROSS=lib/i386-win32/libtcc1.a WIN64_LIBTCC1_CROSS=lib/x86_64-win32/libtcc1.a -X86_64_LIBTCC1_CROSS=lib/x86-64/libtcc1.a +X86_64_LIBTCC1_CROSS=lib/x86_64/libtcc1.a ARM_LIBTCC1_CROSS=lib/arm/libtcc1.a ifdef CONFIG_WIN64 @@ -116,7 +117,7 @@ ARCH=WIN32 endif -TARGET_ALL=WIN32 WIN64 I386 X64 ARM C67 +TARGET_ALL=WIN32 WIN64 I386 X86_64 ARM C67 ifdef TARGET_ARCH NATIVE_FILES= PROGS_CROSS=$($(TARGET_ARCH)_CROSS) @@ -125,8 +126,8 @@ else
Re: [Tinycc-devel] New warning on ARM since few commits
Hi, On Sat, 12 Apr 2014, Christian Jullien wrote: No comments about this issue? It shouldn't be a new warning. The code in question (libtcc1.c, ldouble_long type, the __fixunsxfdi function, and the definition of LDOUBLE_SIZE for ARM) hasn't changed in ages. In fact, this warning is a real BUG if this function is called on ARM Yes, but it never is. long double size is always 8, and for that calls to the XFmode functions are never emitted. You could as well simply add some #ifndef TCC_TARGET_ARM around the implementation of the *xfdi and *dixf functions in libtcc1.c. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Support for hidden symbols?
Hi, On Sat, 12 Apr 2014, Austin English wrote: I recently revisited compiling Wine with TinyCC. I've got some patches for wine for that, but my current blocker is a lack of support for hidden symbols on tcc: Even with that fixed I'll predict some more blockers for wine. It's not exactly one of the most trivial (and C conformant) program packages. And well, wine has some quite performance critical components, so what would be the point in compiling it with tcc? (except for the obvious one of that being an intellectually entertaining experiment) acledit.pEPjUb.s:14: error: unknown assembler directive '.hidden' Okay, so that's supporting (parsing) hidden directive from the assembler itself. While fixing this is easy, you'll hit many more roadblocks in actually compiling real assembler sources (the above seems to be something emitted by the ../../tools/winegcc/winegcc wrapper). TCCs included assembler really isn't much GAS compatible and misses many more directives. /* return a global symbol declaration for an assembly symbol */ const char *asm_globl( const char *func ) default: buffer = strmake( \t.globl %s\n\t.hidden %s\n%s:, func, func, func ); is there any plan for supporting this? There are multiple aspects for supporting hidden symbols: 1) parsing the above (inline) assembler directives. 2) parsing hidden symbols via gcc-compatible visibility attribute. 3) supporting hidden symbol in the builtin link editor. I've done 1) and 2) in the mob branch (e69c506). For 3) there's some code that isn't fully working yet. For x86-64 I've at least implemented correct resolutions of calls to hidden functions. I haven't yet implemented the other archs or correctly handling hidden data symbols. The latter will simply be emitted as non-hidden global symbols (even if they were hidden in the input .o files) right now. grischka: the PE port uses the st_other member of ELF symbols for tracking its own IMPORT/EXPORT directives. As I'm now using it for symbol visibility (with values 0-3) this might clash: using visibility attribute might overwrite former IMPORT/EXPORT directives, and using IMPORT/EXPORT might influence the ELF linker (as it will now make more use of visibility). I lack the necessary pieces to check on windows. If there's indeed an interaction (I can't quite figure that out from just reading the code) but the PE port wants to continue using the st_other member (and not the TCC symbols type) I would guess it's best to use bits outside of mask ELFXX_ST_VISIBILITY (0x3). The COFF port (used for C67) is now a bit more broken than before. It uses st_other for debug type info (ugh!). Is anyone even working on that? Time to remove it maybe? Ciao, Michael.___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Support for hidden symbols?
Hi, On Sun, 13 Apr 2014, Austin English wrote: I expected that wine wouldn't immediately work, I'm doing it for the curiosity factor. Okay :) The next problem is: make[1]: Entering directory `/home/austin/src/wine-tcc/dlls/acledit' /home/austin/tcc/bin/i386-linux-gnu-tcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -g -o main.o main.c ../../tools/winegcc/winegcc -m32 -B../../tools/winebuild --sysroot=../.. -shared ./acledit.spec main.o -o acledit.dll.so ../../libs/port/libwine_port.a acledit.UgAqPb.s:14: error: unknown assembler directive '.L__wine_spec_rva_base' Yep, tccasm doesn't currently accept the ATT syntax of local labels. Well, I could add that as well, but the question will be where to stop? wine emits assembler code for an ATT (e.g. the GNU) assembler, and tccasm is not such one. There will be many more things missing. All the .cfi directives, section markers, the special syntax for marking operands with certain relocations. It would be easier if you would force wine to use the GNU assembler at least for assembler input. The C sources can then still be compiled with TCC (and presumably that's where your couriosity lies). Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] mob broken; how to develop with mob and community
Hello, okay, are the last commits to mob from jiang meant as joke or vandalism? * 32bit code generation is hosed already in the testsuite, * gawk doesn't work anymore even for x86_64, * arm codegen is broken already in the testsuite (adding an internal compiler error) * they contain ugly white-space changes making review exceedingly hard * despite the unnecessarily hard review I think there are numerous problems in the actual implementation: + the new parse_number uses inexact floating point directly (e.g. 1.0L/b when b==10 isn't exactly representable, cumulating errors while parsing) + There's a new subtype VT_VLS meaning VLA plus STRUCT, which makes no sense at all (VLA is VL _array_) + TREG_MEM (also new) doesn't follow convention for type flags, and seems like a layering violation + It reverts a cleanup by Thomas (eda2c756edc4dca004ba217) without discussion + It renames libtcc1.a to libcrt.a, thereby trading a sensibly tcc-specific name for something tcc-specific with something generic (what if gcc had libcrt as well?) + It increases VT_STRUCT_SHIFT to 20, breaking bitfields larger than 31 bits (we needs 12 bits to encode bitfield position and size, so the maximum bit shift can be 19 + It changes gv2() so that VT_CMP/VT_JMP results aren't special-cased anymore, without obvious compensation in all its users to avoid the errors that the comment specifically mentioned + It implements some strange non-standard preprocessor extension push_macro/pop_macro (as pragmas) without discussion; it enlargens some heavily used internal data structures for this. + It adds some fix x86-64 vla commit, without testcase showing what's actually broken, and for that shuffles the internal code generations in large and unobvious ways (and removes the correct calls to alloca() on x86-64 PE) And that's just what I saw on a cursory read of the commits. Due to the white-space changes the more intricate parts are terrible to review and I've skipped them. When I wrote above without discussion, then this was just for the most controversial parts. It's true for all the patches. I've seen no messages at all from jiang to this mailing list. No discussion about implementation approaches, no discussions about bugs, no nothing. The commit messages are mostly non-informative as well. All in all I think this approach is pretty unacceptable, but others here might differ. If the patch series were a smaller then the problems in it could reasonably be fixed after the fact by others. But as it stands we now have something in which every single one of the 22 topmost patches (ignoring the white-space fixup patch from grischka) has issues. If it were just my project I'd be tempted to revert the whole mob state to be before your (jiangs) patches, and expect you to work with the community to fix what you actually wanted to fix or improve. (From the patch series I gather that one thing you wanted to fix was parameter passing on stack when memcpy is needed). It the very minimum you have to subscribe to this mailing list (that's even listed in the mob rules), and of course also take part in discussions. You also have to _review_ your patches before commiting (you would have seen the useless white-space changes) and write meaningful commit messages. Any opinions from others? Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Request push
Hi, On Sun, 22 Jun 2014, David Mertens wrote: Hey jiang, For each of these three patches, please explain the following: 1) When run with the version of tcc without your patch, what behavior do you get? What does the C99 spec tell us we should get? 2) How does the proposed patch alter the behavior of tcc? Also, it appears you did not read the links I provided about how to write good commit messages. Please re-read those and write better ones. Patch 2 at least also contains gratious whitespace changes creating lines longer than 80 character (I know, not a strict policy for TCC, but existing code mostly follows that). And patch 3 (the bitfield fiddling) certainly is wrong as explained in some other mail. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc-devel Digest, Vol 134, Issue 16
Hi,
On Sun, 22 Jun 2014, jiang wrote:
This is my patch (see Annex)
tcc result is correct
-- 254 / 30 / 126
That's not the correct result. If you think it is the probably because
you're confused by the semantics of assignments as rvalue.
I guess gcc mvc repeated use of the register, so wrong
No, GCC and MSVC are correct.
struct {
unsigned a:9, b:5, c:7;
} _s, *s = _s;
int n = 250;
s-a = s-b = s-c = n + 4;
To show that GCC is correct (and TCC wrong, and your patch still wrong)
rewrite the above into the explicit expansion according to associativity
of '=':
s-c = n + 4; // s-c == 254 127 == 126
s-b = s-c; // s-b == 126 31 == 30
s-a = s-b; // s-a == 30
In particular the value loaded into s-a comes from s-b, and hence is the
truncated value, which isn't changed anymore as 5 bits fits into 9 bits.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] State of the tcc project
Hi, On Sun, 22 Jun 2014, David Mertens wrote: Sorry, I decided to give more than 20 hours for folks to weigh in, and then time got away from me. I'll revert jiang's changes with a push some time around June 23 (tomorrow), 9:00PM New York time. By the way, if the instructions at http://repo.or.cz/w/tinycc.git are supposed to be the community rules, jiang was not really breaking any. We should probably work with a different approach. I suggest that individuals who have ideas should do the following: 1) Discuss bug reports or feature requests on the mailing list. 2) If individuals on the mailing list agree that the idea is a good one, the individual should publish their work on a public git hosting site and submit a pull request on the mailing list. 3) After somebody with commit access has checked it out, they can pull it into the official release branch. That would mean closing the mob branch (otherwise everybody has commit access :) ). FWIW, I'd have never touched the x86-64 backend in TCC at all if it weren't for mob. I think overall the mob branch worked reasonably well until recently, and I'd hate to see it thrown out because of people having a different notion of reasonable behaviour :-/ Unfortunately I have no good alternative suggestion, though :-( Ciao, Michael.___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC contributors attending GNU Tools Cauldron
Hi, On Sat, 28 Jun 2014, Thomas Preud'homme wrote: In three weeks will be the GNU Tools Cauldron. I'm going to attend it (it will be my first time) and I was wondering if some of you would come there. I noticed some familiar names when joining the GCC community so I guess some of you will come. I'm there for instance. We'll probably meet at the social dinner on Friday :) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Crosscompiling
On Fri, 27 Jun 2014, Markus Bergholz wrote: Make it clear where “mexPrintf” is defined and why it is not effective. mexPrintf is defined in /usr/include/octave-3.8.1/octave/mexproto.h afaiu. That's a declaration, not a definition. The definition comes from some Octave internal library. On linux you can build shared libraries that contain references to undefined symbols (like 'mexPrintf') that will then be resolved when loading the library (Octave itself or some library it depends on will define that symbol). That's what happens for your working example (your helloworld.mex will actually be an ELF shared library containing unresolved references to mexPrintf). When you try the same for Windows you'll actually build a DLL. When it's supposed to contain references to external symbols then you at least need a .def file that describes which library will provide that symbol later. You'll also need to generate a .lib file describing the symbols exported by your helloworld.mex (so that octave can load it). Generally for Octave the right way to create .mex files seems to be to use the helper program/script mkoctfile (with --mex), which presumably contains all the right libraries and other link parameters for each platform. If Octave supports external commands on Windows at all. This all is not TCC specific, it's a problem in how you use Octaves system for C bindings. You'll probably get better answers asking their developers. Ciao, Michael.___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Fallout from commit 01c041923474750a236da02561f0f8835445848b
Hi,
On Tue, 9 Sep 2014, Thomas Preud'homme wrote:
1) You added the support for R_ARM_GLOB_DAT and R_ARM_JUMP_SLOT
relocations but the computation you added ignore the possible addend at
*ptr by doing a simple assignment. Is that normal? Did I miss something?
This is per the ABI. The addend for both relocations (when using REL
form) is (and must be) always zero. I didn't bother checking for this,
but rather just ignored anything that was in there.
2) When creating a GOT and PLT entry for a R_ARM_PC24, R_ARM_CALL or
R_ARM_JUMP24 you add the offset of the PLT entry to the place being
relocated.
I'm not sure I got it right but it seems to me that the relocation will be
processed again in relocate_section and seems the symbol referenced is still
the target function (and not the PLT entry created) as the index in the
r_info
field of the relocation has remained unchanged. Also this put some relocation
computation in build_got_entries. Why not change the initial relocation to
make it resolve to the PLT entry.
It might be that I got some of the logic wrong, though I obviously did
check tcc on arm with itself (and IIRC gawk). I'll need to reproduce the
problem somewhen. Are you positive that it was my commit that broke it?
Hmm, or it might be that I also hit an error but somehow convinced myself
that it was a pre-existing but possibly hidden problem. Man, it's long
ago :)
3) I don't see any test for the type of output when deciding what type of
relocation to add. So even when the output is in memory reloc_type will be
JUMP_SLOT which will lead to a PLT entry being created. This seems to
contradict the comment near the end of put_got_entry. The comment seems wrong
as I don't see how a branch could be relocated without a PLT entry.
I think what I wanted to convey in the comment is the following situation:
normally with memory output (or static linking) no symbolic relocations
whatsoever are required in the executable, because, well, everything is
relocated from the beginning. But the means by which that is ensured is
itself (at least in TCCs link editor) by creating (and later processing)
relocations. Where it matters are indirect calls:
extern void f(void);
g() { void (*ptr)(void) = f; ptr(); }
Here there will be a GOT slot allocated for 'f'. The initialization of
'ptr' will load from that GOT slot. So even though direct calls to 'f'
can (and will be, when 'f' is defined) fully resolved without a PLT slot,
this indirect access needs a GOT slot, and because of that also needs to
initialize that slot with f's address, which is done by an relocation
(which are processed for static and memory output right at the end of most
processing).
4) the jump table that was removed in subsequent patch was only available
when
outputing to memory. But now a PLT and GOT entry is created no matter what
type of output (see 3) above).
Yes, PLT and GOT together (when unconditionally created) take over the
role of the old jump table.
Now obviously I bungled something regarding all that on ARM and will have
to look at the details. Let me first try to reproduce and I'll come back.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Fallout from commit 01c041923474750a236da02561f0f8835445848b
Hi, On Thu, 18 Sep 2014, Michael Matz wrote: Now obviously I bungled something regarding all that on ARM and will have to look at the details. Let me first try to reproduce and I'll come back. Hmm, current git TCC works for me on ARMv7 in a qemu-simulated chroot. I do have to configure with --with-libgcc (which is different from the debian buildlog you referenced), because my libc_nonshared.a references __aeabi_unwind_cpp_pr[01] . Probably I'd have to use that exact debian-based setup under qemu (my chroot is based on some openSUSE version), but I don't know a simple recipe for how. Any help appreciated. Ciao, Michael. ___ 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] Don't break compilation process with unknow option
Am 07.01.2015 um 11:22 schrieb Sergey Korshunoff: I'm agree. But what to do with the described bug? How to fix it? cd tcc-source ./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' Multiple solutions: * declare this a non-problem by requiring that the reference compiler in the testsuite has to be GCC (in that case configure could perhaps error out if CC != tcc). * if tcc is to be accepted as test reference then the Makefile and possibly configure need to be changed to not pass -std=gnu99 to it without checking if it is accepted (I don't have tcc code here to say if it's only the Makefile that hardcodes that option, or if it comes from configure). Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] RE :Re: New test 73_arm64 hangs if ran on RPi
Hi, On Mon, 9 Mar 2015, Edmund Grimley Evans wrote: Michael Matz matz@frakked.de: And some more fixes for more tests in 73_arm64, namely stdarg passing of structs passed in purely integer registers. structs passed in fp regs or mixed int/fp regs are unfortunately not consecutive in the reg_save_area, and hence need temporary memory, but this requires some more involved changes in libtcc1. On arm64 a struct is sometimes not consecutive in memory. Code is generated in gen_va_arg() in arm64-gen.c to rearrange the data. I get more stack space using the global variable loc. Yes, I know. I just wanted to avoid having to open-code a va_arg in x86-64, it currently uses a C implementation from libtcc1. With that approach I can't allocate stack in the calling routine, of course, and would have to resort to a static buffer, which in turn would break multi-threaded use, or use malloc which would create a leak, or use malloc with reuse, which requires a global list, again creating multi-threaded problems :-/ Over that set of stones and hard places I went to bed. (I now think the only realistic option is indeed to generate va_arg from the backend). Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Some tcc questions
Hi, On Mon, 2 Mar 2015, Sergey Korshunoff wrote: What stuff to change globally do you have in mind? For example, a compiler defines are currently embeded inside a tcc. If such defines will be placed inside a configuration file then it will be possible to select a tcc behavior without tcc recompilation: gcc like defines or C99 dfines. This is better solved with implementing a GCC feature like -include in which you basically prepend an include file for the compilation. No need for a global config file. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] RE :Re: New test 73_arm64 hangs if ran on RPi
Hi, On Mon, 9 Mar 2015, Michael Matz wrote: Same issue with x86_64 and RPi arm32 I just pushed something that helps x86_64 to not segfault this test. It still exposes other bugs in parameter passing there, but doesn't segfault anymore. And some more fixes for more tests in 73_arm64, namely stdarg passing of structs passed in purely integer registers. structs passed in fp regs or mixed int/fp regs are unfortunately not consecutive in the reg_save_area, and hence need temporary memory, but this requires some more involved changes in libtcc1. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] Convert some lines from ISO-8859-1 to UTF-8.
Hi, On Sun, 8 Mar 2015, Edmund Grimley Evans wrote: lib/armeabi.c uses UTF-8. RELICENSING, arm-gen.c and i386-asm.c use ISO-8859-1. Changelog uses a mixture. Yuck! The script in the commit message converts every line that isn't valid UTF-8 from ISO-8859-1 to UTF-8. I'm attaching the compressed patch. I can't very well include it inline for a fairly obvious reason. Is this a good change, or pointless fiddling? It doesn't cause too much churn (only changes 10 lines), and it annoyed me sometimes as well, so IMHO it's a good change. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] RE :Re: New test 73_arm64 hangs if ran on RPi
Hi, On Thu, 26 Feb 2015, Christian Jullien wrote: Same issue with x86_64 and RPi arm32 I just pushed something that helps x86_64 to not segfault this test. It still exposes other bugs in parameter passing there, but doesn't segfault anymore. On arm32 (but in qemu, not real hardware) I also don't see segfaults anymore, but miscompares and an internal compiler error (vstack leak). Ciao, Michael. C. -Original Message- From: tinycc-devel-bounces+eligis=orange...@nongnu.org [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Edmund Grimley Evans Sent: jeudi 26 février 2015 13:38 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] RE :Re: New test 73_arm64 hangs if ran on RPi I'll try to fix it later today. Done. (In my lunch hour as I'm so embarrassed about having written bad C!) However, I don't expect it to affect the test failures. If a compiler lets you take the address of a return value then it has presumably put the return value into an anonymous local variable. TCC in any case puts a returned struct into an anonymous local variable. The test 73_arm64 passes on arm64 and i386. Edmund ___ 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] Your revert of a gdb-helping patch breaks gdb
Hi,
On Mon, 9 Mar 2015, Sergey Korshunoff wrote:
This behavior may depend on the gdb version. I use a rhide v1.5 for
debuggin (i386, Linux). A gdb version embedded in it is 6.1.1
This version is more than ten years old.
And which version of the gdb you use?
Various ones, 7.3, 7.5.50, 7.8.
I think a tcc switch must be
introduced to select a stabs handling behavior.
I don't think so. I rather think we should do what a normal linker does
in this respect, and that's relocating the input sections. So you're
saying that a hello world compiled by gcc -gstabs (and linked by ld)
doesn't work in rhide? In that case rhide is simply buggy and needs
fixing. If it does work OTOH, then you should find out why and make tcc
emulate gcc+ld better.
PS: grishka don't explain in his patch why he change a behavior of the
previous patch.
Well, neither did you, but the way it's not working without relocated
.stabs is very obvious, as I showed in my mail. When not relocating
.stabs no program compiled by tcc -g will be debuggable in gdb.
On Mon, 9 Mar 2015, Sergey Korshunoff wrote:
By the way: after appling a patch CValue (replacing various integer
types with int64_t) rhide works well independed of stabs behavior
(with relocating stabs section and w/o this). What this means?
Sorry, this is not true. With grishka patch on rhide don't work.
So, what exactly doesn't work?
PS: You can test this itself (www.rhide.com)
Well, you want to use age-old software, so IMO it's you having the
burden of debugging your IDE. But some other hint: you can also use
objdump to inspect the debug output of tcc:
% objdump -g hello.broken
hello: file format elf64-x86-64
/home/matz/hello.c:
undefined main ()
{ /* 0x0 */
/* file /home/matz/hello.c line 5 addr 0x0 */
/* file /home/matz/hello.c line 5 addr 0xb */
/* file /home/matz/hello.c line 6 addr 0xb */
/* file /home/matz/hello.c line 7 addr 0x1f */
} /* 0x2b */
...
(That's a full executable). As you can see, the addresses are wrong by
starting at zero. A working executable shows this:
% objdump -g hello.ok
hello.ok: file format elf64-x86-64
/home/matz/hello.c:
undefined main ()
{ /* 0x400303 */
/* file /home/matz/hello.c line 5 addr 0x400303 */
/* file /home/matz/hello.c line 5 addr 0x40030e */
/* file /home/matz/hello.c line 6 addr 0x40030e */
/* file /home/matz/hello.c line 7 addr 0x400322 */
} /* 0x40032e */
...
I have one other idea, that _might_ be the cause for your problems: tcc
usually emits all input sections to the output, and that includes the
applied .rela.secname sections. So, in a way, the produced executables
contain the relocations twice: once in the target section, once in the
relocation section again. This is normally harmless (only dynamic
relocations are processed for executables, not those additional ones), but
possibly the old tools you use do apply them again.
You can check this if you remove that section: with a program
compiled/linked by a tcc with your revert reverted (i.e. relocated
.stabs), do this:
% objcopy -R .rela.stabs input output
If input isn't debuggable in rhide, but output is, then this is the
problem, and the right fix for tcc is to not emit those needless .rel(a)
sections in linked files.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] accepting a wrong scruct declaration
Hi,
On Sun, 29 Mar 2015, Sergey Korshunoff wrote:
struct A
{
struct B {
int f1;
int f2;
};
};
int main()
{
struct A a;
a.f1 = 16;
a.f2 = 32;
}
A tcc compiler must not accept this program because a struct B is only
a type declaration and not a member declaration. Any tips how to fix
this?
Careful. The above example is non-standard C, but must be accepted as a
microsoft extension. GCCs option for that is -fms-extensions . As TCC
is also used on windows I expect not accepting it to lead to failures
there.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] When handling '.' operator, cope with VT_LLOCAL
Hi,
On Fri, 20 Feb 2015, Edmund Grimley Evans wrote:
Does this look all right?
Do you have a testcase? I'll agree that there's possibly something fishy,
but the change doesn't look 100% right.
... looksy looksy ...
Hmm, maybe I trace your path how you found this :) When trying to use
VT_LLOCAL to replace VT_REF, when the member in question is not an array,
right? ;) Because then without your patch this example generates wrong
code under win64:
struct S {int a; int x[7];};
int f (int a, int b, int c, int d, struct S s)
{
return s.a;
}
So, something is wrong indeed. The problem I have with your patch:
@@ -4024,6 +4024,8 @@ ST_FUNC void unary(void)
vtop-type.t |= qualifiers;
/* an array is never an lvalue */
if (!(vtop-type.t VT_ARRAY)) {
+if ((vtop-r (VT_VALMASK | VT_LVAL)) == (VT_LOCAL | VT_LVAL))
+vtop-r += VT_LLOCAL - VT_LOCAL;
vtop-r |= lvalue_type(vtop-type.t);
#ifdef CONFIG_TCC_BCHECK
/* if bound checking, the referenced pointer must be checked */
is: this patches only one place where lvalue_type is called (i.e. where
something on the stack is lvalueized again). Why are the others trivially
correct and don't need such handling? Also, conceptually, I might have a
problem with this: it fixes up things after they went wrong. For
instance, why isn't the problem in gen_op? I mean, one invariant of
gen_op (when called with non-optimizable args) is that it leaves a
non-lvalue on the stack, so the code in unary() is correct as is, for
those cases. So, wouldn't it be better if the lvalue-to-rvalue conversion
would happen also with gen_op(+,0)?
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] deprecating VT_REF
Hi,
On Sat, 21 Feb 2015, Edmund Grimley Evans wrote:
Michael Matz matz@frakked.de:
I don't like this. tccgen.c should become _less_ dependend on the
TARGET defines, not more. Hence either VT_REF has a purpose and it
might make sense to use it in more backends, or it hasn't and should
be removed also from x86_64.
I agree, but inserting those #ifdefs is merely making the
architecture-specificity explicit, thereby perhaps encouraging someone
to do something about it. Without the #ifdefs, but with VT_REF only
used by the x86_64 back end, you have hidden target-specificity, which
is more dangerous.
I disagree about dangerous; it's only a problem for those targets, and
presumably for them the generic handling of VT_REF is correct. If you
mean dangerous as in others might be tempted to use it in their target,
even though the generic handling isn't correct for them, then, well, life
is tough; it's not enough reason IMHO to uglify common code. Neither is
trying to make others interested in removing the thing.
But apart from that philosophical argument, I claim that the concept of
VT_REF is not target specific at all. It does have things in common with
VT_LLOCAL, but is not _quite_ the same currently, as we now found out in
the other mails. This not-quite-equality might indeed be bugs in how
VT_LLOCAL is handled, e.g. VT_LLOCAL might be understood as an
optimization to VT_REF (even though the latter was introduced later), the
optimization being that lvalueness/referenceness can be changed by a
simple bitflip, instead of generating code.
So, yes, ideally VT_LLOCAL and VT_REF should be merged. Though the
question still is into which one. VT_LLOCAL is tricky, as the docu said
:) And it currently contains bugs, when used for some things.
_If_ the issues with VT_LLOCAL can be fixed, then I'd be in favor of
removing VT_REF. After such fixing goes in.
AFAIU VT_REF is added when an argument is passed in a caller
allocated buffer whose address itself is passed in a register (i.e.
by-reference-passing).
Do you mean on the stack?
Usually, but not necessarily. For a function like
int f (int a; struct large b) { ... }
there are two ways to get to 'b':
1) it's saved on the stack by caller, the address will be right below
the slot for 'a', or the first slot, if 'a' gets a register. So
addressof(b) will be something like sp+offset.
2) it's stored in some buffer (not necessarily stack) and the address of
it is explicitely passed in the argument that would take the place of
'b' were it of pointer type. Now addressof(b) is not necessarily some
offset from sp, but rather must be loaded (either from a register,
or the stack slot that addressof value got)
Yes, VT_LLOCAL can nearly express the concept 2. VT_REF as well (just
that it works right now).
On arm64 the caller sometimes allocates a buffer then passes a pointer
to that buffer on the stack, and I'm handling that with VT_LLOCAL,
Okay, that's the same as win64 then, which means you could have also used
VT_REF. (I'm not saying you should have, just stating the fact.)
which is already widely used. (I checked that a lot of VT_LLOCALs are
generated when you run the test suite on i386, for example.)
Yes, VT_LLOCAL is used often. But it's used for only one thing currently
(i.e. the number of concepts expressed by it is not very large): when an
lvalue contained in a register is spilled, it becomes a stack slot with
VT_LLOCAL. That makes sense, because lvalue in a register means the
register contains the address of that lvalue (and then so does the stack
slot). But for instance it's not totally clear what VT_LLOCAL means on
something that never was a register (e.g. because it is not of right
type). Also, is it ever okay to have VT_LLOCAL without VT_LVAL? (There
should be nothing wrong about this, but does the code always handle this?)
I think perhaps it's time to try to figure out what the three flags
(VT_LLOCAL, VT_LVAL and VT_LOCAL) really mean, which combinations make
sense (under which circumstances) and which operations do what to the
flags. If we had clear rules we probably can make VT_LLOCAL do exactly
what's necessary in generic code, to make it safely and generally usable.
Right now the whole VT_LLOCAL handling seems quite ad-hoc (and that
results exactly in the omissions you saw with the '.' operator).
I'd definitely prefer it if someone could remove VT_REF altogether.
Alternatively, someone could patch the documentation to explain exactly
what VT_REF means, why it's needed, and how it differs from VT_LLOCAL.
If neither of those patches is forthcoming I'd prefer something like my
patch to be committed to just leaving it as it is.
Well, we're still discussing, so not all is lost yet :) I'd actually hope
to have such description for VT_LLOCAL in the end, and remove VT_REF after
the current threads are finished.
Ciao,
Michael
Re: [Tinycc-devel] [PATCH] When handling '.' operator, cope with VT_LLOCAL
Hi, On Sun, 22 Feb 2015, Edmund Grimley Evans wrote: The only disadvantage that I can think of is that certain expressions which would cause GCC to warn that value computed is not used would not get optimised. I think the conversion to rvalue might not actually have to emit code, in which case unused stuff would be as optimized as before (as far as tcc is optimizing :)). I can't see how to do that. Hmm, perhaps it's not possible. I thought via manipulating the VT_foo flags in vtop-r. Since I probably still have a test case to hand, should I propose an alternative patch that fixes my problem by modifying gen_op? Yeah, I think so. So here's an alternative patch that fixes the problem for me: diff --git a/tccgen.c b/tccgen.c index ae07563..9dfeb2b 100644 --- a/tccgen.c +++ b/tccgen.c @@ -1827,6 +1827,8 @@ ST_FUNC void gen_op(int op) vtop-type.t = t; } } +if (vtop-r VT_LVAL) +gv(is_float(vtop-type.t VT_BTYPE) ? RC_FLOAT : RC_INT); } #ifndef TCC_TARGET_ARM It probably doesn't change the generated code significantly, though I should perhaps warn that apart from the cases I alluded to earlier, where a value computed is not used, there may also be a few cases where converting the value to an rvalue earlier than it is needed hurts the register allocation, as in something like f(a + 0, b + 0, c + 0, d + 0, e + 0, f + 0). I wouldn't worry about it, though. I've just noticed that the patch above doesn't have the comment I wrote, something like: +// Make sure that we have converted to an rvalue: Do you like this new patch? I need to fix this problem somehow for arm64. Now that I also have a working aarch64 tcc, do you have a testcase for the problem? The testsuite itself is clean. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] deprecating VT_REF
Hi,
On Fri, 20 Feb 2015, Edmund Grimley Evans wrote:
VT_REF is not mentioned in the documentation and seems to be used only
for x86_64. Also, it seems to be the same thing as VT_LLOCAL, really.
This could be a first step towards removing it altogether.
Commit message:
Make it explicit that VT_REF is used only for TCC_TARGET_X86_64.
tcc.h: Make the definition conditional on TCC_TARGET_X86_64.
tccgen.c: Since the VT_REF bit is set only in x86_64-gen.c we
can make clearing it and testing for it conditional.
I don't like this. tccgen.c should become _less_ dependend on the TARGET
defines, not more. Hence either VT_REF has a purpose and it might make
sense to use it in more backends, or it hasn't and should be removed also
from x86_64. And _if_ it has a purpose only on x86-64 (which indeed seems
unlikely) then the common code should still handle it unconditionally.
FWIW it's currently only used when TCC_TARGET_PE, i.e. win64.
It was introduced by grischka in 2010 for some win64 va_arg handling of
structure types (8d107d9ff) and fixed a bit later with f115c123.
AFAIU VT_REF is added when an argument is passed in a caller allocated
buffer whose address itself is passed in a register (i.e.
by-reference-passing). So the register contains not the argument
itself, but the address of it. That's not a too unusual ABI (x86-64
linux, though, uses passing on stack, not by reference), as it can
sometimes avoid a memcpy when calling such functions. And yes, that seems
to be VT_LLOCAL.
grischka, can you try the below patch on win64? If it works we can remove
VT_REF altogether. I verified it generates the same code with a
cross-to-win64 tcc on functions where it should be active, like:
struct S {int x[7];};
int f (
#ifndef IN_REGS
int a, int b, int c, int d,
#endif
struct S s)
{
return s.x[3];
}
(with -DIN_REGS the address is passed in rcx, without it's passed on
stack).
Ciao,
Michael.
--
diff --git a/x86_64-gen.c b/x86_64-gen.c
index c8fed85..463cf8d 100644
--- a/x86_64-gen.c
+++ b/x86_64-gen.c
@@ -855,7 +855,7 @@ void gfunc_prolog(CType *func_type)
if (reg_param_index REGN) {
gen_modrm64(0x89, arg_regs[reg_param_index], VT_LOCAL, NULL,
addr);
}
-sym_push(sym-v ~SYM_FIELD, type, VT_LOCAL | VT_LVAL | VT_REF,
addr);
+sym_push(sym-v ~SYM_FIELD, type, VT_LVAL | VT_LLOCAL, addr);
} else {
if (reg_param_index REGN) {
/* save arguments passed by register */
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] TCC arm64 back end
Hi,
On Sun, 22 Feb 2015, Edmund Grimley Evans wrote:
I've done roughly that. However, I included both fixes for
VT_LLOCAL/'.', but with both disabled. Also, I omitted the VT_REF patch,
of course.
New diff attached, with updated README.arm64.
Just for demonstration, this is what I meant that you could have also used
VT_REF instead of VT_LLOCAL. On top of your patch, without the
VT_LLOCAL/'.' hunks active, this also makes abitest pass. Except for
register allocation (not using x30 as temp reg, but a normal allocated
register) it generates the same code for some examples extracted from
abitest.c, between with this patch vs. activating one of the LLOCAL/'.'
hunks.
Ciao,
Michael.
diff --git a/arm64-gen.c b/arm64-gen.c
index cf3764b..44675f5 100644
--- a/arm64-gen.c
+++ b/arm64-gen.c
@@ -430,7 +430,7 @@ ST_FUNC void load(int r, SValue *sv)
int svrv = svr VT_VALMASK;
uint64_t svcul = (int32_t)sv-c.ul;
-if (svr == (VT_LOCAL | VT_LVAL)) {
+if ((svr ~VT_REF) == (VT_LOCAL | VT_LVAL)) {
if (IS_FREG(r))
gen_fload(arm64_type_size(svtt), fltr(r), 29, svcul);
else
@@ -1010,7 +1010,7 @@ ST_FUNC void gfunc_prolog(CType *func_type)
a[i] 32 ? 16 + (a[i] - 16) / 2 * 16 :
224 + ((a[i] - 32) 1 1));
sym_push(sym-v ~SYM_FIELD, sym-type,
- (a[i] 1 ? VT_LLOCAL : VT_LOCAL) | lvalue_type(sym-type.t),
+ (a[i] 1 ? (VT_LOCAL | VT_REF) /*VT_LLOCAL*/ : VT_LOCAL) |
lvalue_type(sym-type.t),
off);
// HFAs of float and double need to be written differently:
if (16 = a[i] a[i] 32 (sym-type.t VT_BTYPE) == VT_STRUCT) {
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] TCC arm64 back end
Hi, On Sun, 22 Feb 2015, Edmund Grimley Evans wrote: That's excellent. Many thanks. When do you sleep, by the way? :-) Roughly when you asked this question :) - merge my local uncommitted stuff or at least stash it somehow (I've implemented HFAs and have started doing va_list) - rebase my branch onto the latest mob, omitting the VT_LLOCAL/'.' patch - merge your patch - send out the new diff, which should then demonstrate the problem when you do: ( cd tests make abitest ) (I'll fiddle with the patch you sent) I'm not a git expert, but what I'll try to do before committing the arm64 branch to mob is greatly simplify the history but leave your changes to tccelf.c as a separate commit ... so that anyone who consults the history will know who the expert is on linking! I'm hoping the arm64 stuff can go onto mob within about a week even if it's without va_list. Just push the stuff right now to mob. Makes collaboration a bit easier than having to deal with the large patch by hand. As for history: make sure the branch you push doesn't contain any merges (uglifies history), i.e. your working-mob branch should always have been rebased, not merged with origin/mob. One more request: if you could make sure that multi-line comments in your patch are using /**/ and no leader chars, that would be ideal. 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
Hi,
On Thu, 19 Feb 2015, Edmund Grimley Evans wrote:
It's not finished, but a lot of things seem to work, and there's a
problem with the linker that perhaps someone could help me with.
See README.arm64 for details.
That's quite cool. Below is a patch on top of your's (slightly amended to
resolve the conflicts with top-of-mob of your recent commits) which fixes
-run. Obviously quite more stuff is missing, most of which will be
necessary for generating real shared libs (or even psABI compliant exes).
And the codegen should sometimes use different strategies. One thing I
noticed is for instance that gen_addr uses non-GOT relocs for accessing
the address of a symbol. That's generally not correct, at least for weak
symbols one has to go via a GOT entry (or some in-.text slot with a ABS64
reloc). I've hacked around this in the patch, but eventually such things
need cleanup.
And I pulled my hair out again when tracing the different paths the
linker can go through in different modes, and how the relocs and symbol
values change over the course of compilation. One of those days ... :-)
Ciao,
Michael.
-
From c2274760caed058d53a94e161c34ea7ea49bfdca Mon Sep 17 00:00:00 2001
From: Michael Matz m...@suse.de
Date: Sun, 22 Feb 2015 05:59:06 +0100
Subject: [PATCH] aarch64: Fix -run.
This adds some more support for properly transfering some
offsets over the different stages of a relocations life.
Still not at all psABI compliant and DSOs can't yet be generated.
But it runs the testsuite in qemu-arm64.
---
tccelf.c | 62 +---
tccrun.c |2 +-
tests/Makefile|2 +-
tests/tests2/Makefile | 20 ---
4 files changed, 55 insertions(+), 31 deletions(-)
diff --git a/tccelf.c b/tccelf.c
index 4f89224..2b07f60 100644
--- a/tccelf.c
+++ b/tccelf.c
@@ -451,7 +451,7 @@ ST_FUNC void relocate_syms(TCCState *s1, int do_resolve)
if (addr) {
sym-st_value = (addr_t)addr;
#ifdef DEBUG_RELOC
- printf (relocate_sym: %s - 0x%x\n, name, sym-st_value);
+ printf (relocate_sym: %s - 0x%lx\n, name, sym-st_value);
#endif
goto found;
}
@@ -797,8 +797,21 @@ ST_FUNC void relocate_section(TCCState *s1, Section *s)
break;
case R_AARCH64_JUMP26:
case R_AARCH64_CALL26:
+ /* This check must match the one in build_got_entries, testing
+ if we really need a PLT slot. */
+ if (sym-st_shndx == SHN_UNDEF)
+ /* We've put the PLT slot offset into r_addend when generating
+ it, and that's what we must use as relocation value (adjusted
+ by section offset of course). */
+ val = s1-plt-sh_addr + rel-r_addend;
+#ifdef DEBUG_RELOC
+ printf (reloc %d @ 0x%lx: val=0x%lx name=%s\n, type, addr, val,
+ (char *) symtab_section-link-data + sym-st_name);
+#endif
if (((val - addr) + ((uint64_t)1 27)) ~(uint64_t)0xffc)
-tcc_error(R_AARCH64_(JUMP|CALL)26 relocation failed);
+ {
+tcc_error(R_AARCH64_(JUMP|CALL)26 relocation failed (val=%lx,
addr=%lx), addr, val);
+ }
*(uint32_t *)ptr = 0x1400 | (type == R_AARCH64_CALL26) 31 |
((val - addr) 2 0x3ff);
break;
@@ -818,7 +831,17 @@ ST_FUNC void relocate_section(TCCState *s1, Section *s)
0xff8) 7;
break;
case R_AARCH64_COPY:
- break;
+break;
+case R_AARCH64_GLOB_DAT:
+case R_AARCH64_JUMP_SLOT:
+/* They don't need addend */
+#ifdef DEBUG_RELOC
+ printf (reloc %d @ 0x%lx: val=0x%lx name=%s\n, type, addr,
+ val - rel-r_addend,
+ (char *) symtab_section-link-data + sym-st_name);
+#endif
+*(addr_t *)ptr = val - rel-r_addend;
+break;
default:
fprintf(stderr, FIXME: handle reloc type %x at %x [%p] to %x\n,
type, (unsigned)addr, ptr, (unsigned)val);
@@ -1211,6 +1234,7 @@ static unsigned long put_got_entry(TCCState *s1,
plt = s1-plt;
if (plt-data_offset == 0)
section_ptr_add(plt, 32);
+symattr-plt_offset = plt-data_offset;
p = section_ptr_add(plt, 16);
put32(p, s1-got-data_offset);
put32(p + 4, (uint64_t)s1-got-data_offset 32);
@@ -1372,6 +1396,23 @@ ST_FUNC void build_got_entries(TCCState *s1)
put_got_entry(s1, reloc_type, sym-st_size, sym-st_info,
sym_index);
break;
+
+ case R_AARCH64_JUMP26:
+ case R_AARCH64_CALL26:
+if (!s1-got)
+build_got(s1);
+sym_index = ELFW(R_SYM)(rel
Re: [Tinycc-devel] [PATCH] use RELA relocations properly for R_DATA_PTR
Hello Edmund,
On Tue, 17 Feb 2015, Edmund Grimley Evans wrote:
With TCC the addend is zero! Apparently TCC is putting the offset is
in the data section:
readelf -x .data t1.gcc.o
0x
readelf -x .data t1.tcc.o
0x 1000
Now this isn't how RELA relocations are normally described as working,
though I'm not sure that it's wrong.
It's strictly wrong, but harmless, because, as you noticed, all linkers OR
in the value at the reloc place. It's one of those things that always
wants fixing but never really reach the top of TODO lists :) As it
reached yours, all the better.
I haven't found a document that says you have to ignore what value is
in the place with a RELA relocation,
Actually, the x86-64 psABI is explicit. The formulas for calculating
reloc values only contain one 'A' (addend) and specify that the addend is
in r_addend of the reloc, so the addend at the place must be ignored.
But alas, real world is more forgiving :)
Proposed commit message:
Use RELA relocations properly for R_DATA_PTR on x86_64.
libtcc.c: Add greloca, a generalisation of greloc that takes an addend.
tcc.h: Add greloca and put_elf_reloca.
tccelf.c: Add put_elf_reloca, a generalisation of put_elf_reloc.
tccgen.c: On x86_64, use greloca instead of greloc in init_putv.
The patch is fine, please commit. I have one remark:
-if (vtop-r VT_SYM) {
+#ifdef TCC_TARGET_X86_64
+if (vtop-r VT_SYM)
+greloca(sec, vtop-sym, c, R_DATA_PTR, vtop-c.ptr_offset);
+else
+*(addr_t *)ptr |= (vtop-c.ptr_offset bit_mask) bit_pos;
+#else
+if (vtop-r VT_SYM)
greloc(sec, vtop-sym, c, R_DATA_PTR);
-}
*(addr_t *)ptr |= (vtop-c.ptr_offset bit_mask) bit_pos;
+#endif
Strictly speaking the addend should be
(vtop-c.ptr_offset bit_mask) bit_pos;
This should make no difference for VT_SYM vtops, but perhaps an assert
would be better (bit_pos == 0). OTOH this routine has other checking
problems (e.g. it doesn't give an error if the value doesn't fit e.g. a
VT_BYTE place), so adding just one assert for this case seems
inconsistent.
Oh, and one other thing: if you could include (smallish) patches inline at
the end of mail, it makes quoting parts of them for review easier; of
course only if your mailer doesn't mangle patches added inline.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Some tcc questions
Hi,
On Thu, 19 Feb 2015, Naper Hamza wrote:
Hello , I wanna know if tcc have a global config , where we can change some
stuff , if not why not implementing one ?
That's not how compilers traditionally work, it would be a layering
violation. What options are active for a compilation is usually
determined by the build system using the compiler (and given to the
compiler as command line options or environment variables). Having a
config file would be very surprising to most compiler users.
What stuff to change globally do you have in mind?
Also I wanna know if a official tcc organization is available on
GitHub ,
No.
which means also if a official tcc repo is available too .
One doesn't imply the other. The official tcc repo is at
{http,git}://repo.or.cz/tinycc.git
Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Fallout from commit 01c041923474750a236da02561f0f8835
Hi,
On Fri, 20 Feb 2015, Edmund Grimley Evans wrote:
extern void f(void);
g() { void (*ptr)(void) = f; ptr(); }
Here there will be a GOT slot allocated for 'f'. The initialization of
'ptr' will load from that GOT slot. So even though direct calls to 'f'
can (and will be, when 'f' is defined) fully resolved without a PLT slot,
If f is in a library it may turn out not to be in range for a direct
call.
Right. But defined in tcc sense means defined in the .o/.c files
taking part in the compilation, not in some shared library. I.e. symbols
that don't have SHN_UNDEF as st_shndx. They are always reachable (as long
as the programs text segment doesn't become too large, i.e. the usual
small model when sizeof(.text) must be something 1(some-bitsize)).
Probably I'd have to use that exact debian-based setup under qemu (my
chroot is based on some openSUSE version), but I don't know a simple
recipe for how. Any help appreciated.
You could try taking debootstrap from the Debian archive, unpacking it
manually, and running it as root thus:
.../debootstrap --arch armhf unstable .../chroots/arm64-unstable
http://ftp.debian.org/debian
I've done that before for creating a Debian chroot on a non-Debian
Linux machine. It's also what I use for creating a chroot for a
different architecture, such as arm64 on i386 (with QEMU), or armhf on
arm64 (without QEMU).
Yeah, something wasn't quite right with my qemu when I tried this last
time in September. Now it works.
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
Hi, On Mon, 13 Apr 2015, Thomas Preud'homme wrote: 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. Ah right, that's actually what makes more sense than just doing it for undef symbols. 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. Nope. Try it for yourself: Huh, indeed. IMHO that's inconsistent with the symbol resolution behaviour of GNU ld (only looking in level0 libs for symbols, not in those DT_NEEDED by them, unless --copy-dt-needed-entries is active), but so be it. Thanks for teaching me, I really appreciate. It seems that despite what you told, you understand tcc's linker at least as well as me. Anyway, if you don't mind I'd still like to be the one to improve its organisation. I'll appreciate any review of my changes though. Sure, no problem. 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
Hi, On Wed, 15 Apr 2015, Thomas Preud'homme wrote: Nope. Try it for yourself: Huh, indeed. IMHO that's inconsistent with the symbol resolution behaviour of GNU ld (only looking in level0 libs for symbols, not in those DT_NEEDED by them, unless --copy-dt-needed-entries is active), but so be it. I did the test with gcc so I was describing ld's behavior. Yes, in case it wasn't obvious I agreed with you, I just think ld's behaviour in this aspect is IMHO inconsistent with behaviour in a slightly related aspect. Got a patch and would appreciate some feedback. Only tested on x86-64 so far [1] so I would also appreciate testing on other targets (even i386). Looks good to me. 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
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] accepting a wrong scruct declaration
Hi, On Thu, 2 Apr 2015, Sergey Korshunoff wrote: Thanks. Very interesting. Then a patch must contain a -fms-extensions option too. Or we just declare this to be a non-issue. Accepting invalid source is IMHO acceptable in the scope of TCC (at least if the fix would be too involved). Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] No lazy PLTGOT relocation for TinyCC generated executables
Hi, On Thu, 21 May 2015, Thomas Preud'homme wrote: On May 18, 2015 11:17:35 PM GMT+08:00, Sergey Korshunoff sey...@gmail.com wrote: tries comparing the output of readelf -a for an hello world program but there are too many differences and I didn't spot anything obvious there is no .got.plt section in the tcc generated exe. gcc don't generate this section if bind_now. no (FLAGS attribute too. Doh, indeed. How could I miss that? Actually I know, the diff was basically all deletions followed by all additions so I focused on common sections. Anyway both sections (.got and .got.plt) have same access rights (WA) and the names shouldn't matter so does glibc changes it's behaviour if there is more than one section with (dynamic) relocations? Or does it check if a section is full of JUMP_SLOT only? No, the missing of .got.plt is a red herring (it's used to implement a security feature to isolate .got slots that can be written to also after program relocation from those can can't). The real problem is, that the dynamic linker only resolves relocations lazily that are consecutive and properly announced in the ELF dynamic section. Normal relocations are found by the DT_RELA/DT_RELASZ (DT_RELAENT) entries, they describe where in the ELF file relocations are found (note that sections are completely irrelevant for the loader). Then there's also an DT_JMPREL/DT_PLTRELSZ (DT_PLTREL) pair that describes where the _lazy_ relocations are to be found. This was for a RELA arch, a REL one is equivalent. So, if the latter is missing (and hence all relocs are bounded by the first pair) then all relocs are done eagerly. So, tcc needs to emit relocations a bit different: either sorting by type, then describing the JUMP_SLOT relocs with the DT_JMPREL pair (and exclude them from the DT_RELA pair), or keeping JUMP_SLOT and other relocs separate from the start, but still using the two pairs to describe lazy and non-lazy relocs. I'll enable lazy relocation as part of the refactoring I'm doing as it's easier but will try to do an intermediary push as soon as I do it rather than wait to complete all the refactoring. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] mob regression - compiling gawk
Hi, On Wed, 1 Jul 2015, Aharon Robbins wrote: Hi. The current mob on x86_64 no longer compiles gawk correctly. The generated executable does a stunning job of failing the test suite, dumping core multiple times. wget http://ftp.gnu.org/gnu/gawk/gawk-4.1.3.tar.gz # latest release tar -xpvzf gawk-4.1.3.tar.gz ./configure CC=tcc make make check # KABOOM! I'm using a version from mid-May and that works fine, so something broke in the past 6 or 7 weeks. Can someone look into this please? It's 4e04f67c94c9, fix-mixed-struct (patch by Pip Cet) which breaks it. It changes argument passing on x86-64 in a significant way, and obviously there's a glitch in it. Haven't analyzed further yet. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] RE : [RFC] Moving source code to src
Hi, On Mon, 27 Jul 2015, gus knight wrote: On Mon, Jul 27, 2015 at 12:48 PM, Christian JULLIEN eli...@orange.fr wrote: Hi Gus, This is a good idea. If you do so, I also suggest an arch directory that contains subdirectories for all supported archives I wound up going with one dir per arch rather than an arch directory. Let me know if there are any regressions. $ cd tinycc $ ./configure make ... make: *** No targets specified and no makefile found. Stop. Sigh. Also make -C src is broken, the documentation in particular: $ make -C src ... ./texi2pod.pl ../docs/tcc-doc.texi tcc.pod make: ./texi2pod.pl: Command not found make: [tcc.1] Error 127 (ignored) pod2man --section=1 --center=Tiny C Compiler --release=`cat ./../VERSION` tcc.pod tcc.1 Can't open tcc.pod: No such file or directory at /usr/bin/pod2man line 60. make: [tcc.1] Error 2 (ignored) This is because you've moved texi2pod.pl from ./ into ./docs/ but haven't changed the makefile. Please fix. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Source vandalism
Hello gus or Augustin,
while I appreciate more people working on tinycc, why do you think the
best thing to do as the very first commits would be source code
reformattings and reorganizations? Look at what damage you've done:
@@ -204,7 +204,7 @@ void C67_g(int c)
#endif
ind1 = ind + 4;
if (ind1 (int) cur_text_section-data_allocated)
- section_realloc(cur_text_section, ind1);
+section_realloc(cur_text_section, ind1);
Grand, so now the conditioned statement isn't indended anymore. Or:
while (t) {
- ptr = (int *) (cur_text_section-data + t);
- {
- Sym *sym;
+ptr = (int *) (cur_text_section-data + t);
+{
+Sym *sym;
The 'ptr =' assignment has to be indended. Or:
} else {
- qrel-r_info = ELFW(R_INFO)(0, R_X86_64_RELATIVE);
- qrel-r_addend = *(long long *)ptr + val;
+qrel-r_info = ELFW(R_INFO)(0, R_X86_64_RELATIVE);
+qrel-r_addend = *(long long *)ptr + val;
qrel++;
}
What the hell? Parts of the conditional block are now indended completely
wrong. Or such changes:
-#define RC_INT 0x0001 /* generic integer register */
-#define RC_FLOAT 0x0002 /* generic float register */
-#define RC_R0 0x0004
-#define RC_R1 0x0008
-#define RC_R2 0x0010
-#define RC_R3 0x0020
-#define RC_R12 0x0040
-#define RC_F0 0x0080
-#define RC_F1 0x0100
-#define RC_F2 0x0200
-#define RC_F3 0x0400
+#define RC_INT 0x0001 /* generic integer register */
+#define RC_FLOAT 0x0002 /* generic float register */
+#define RC_R0 0x0004
+#define RC_R1 0x0008
+#define RC_R2 0x0010
+#define RC_R3 0x0020
+#define RC_R12 0x0040
+#define RC_F0 0x0080
+#define RC_F1 0x0100
+#define RC_F2 0x0200
+#define RC_F3 0x0400
Well, obviously the author of this wanted to align the numbers like in a
table, now it looks ugly. Or this:
static unsigned long put_got_entry(TCCState *s1,
- int reloc_type, unsigned long size, int info,
- int sym_index)
+ int reloc_type, unsigned long size, int info,
+ int sym_index)
{
The arguments on second and third line were meant to align with the first
argument. Or just a few lines down:
if (need_plt_entry !s1-plt) {
- /* add PLT */
- s1-plt = new_section(s1, .plt, SHT_PROGBITS,
- SHF_ALLOC | SHF_EXECINSTR);
- s1-plt-sh_entsize = 4;
+/* add PLT */
+s1-plt = new_section(s1, .plt, SHT_PROGBITS,
+ SHF_ALLOC | SHF_EXECINSTR);
+s1-plt-sh_entsize = 4;
}
Gnah! First the whole conditional statements aren't indended anymore, and
second the arguments to the new_section call aren't aligned.
This is all quite obvious and terrible, and I could go on and on just
citing from the diffs. Have you even _looked_ at your patches before
committing them? Fix all of this right away, otherwise we have to revert
the whole series.
Also there's another argument against generally doing such code
reformattings: git blame is disturbed now, all lines that you've
reindended now show your commit as the one to blame, which is useless
information. Unfortunately that's a damage that can't be undone now
anymore.
Next time you want to do whole-sale code changes please discuss on the
mailing list before doing so, there might be reasons for the status quo
that you're unaware of, like in this case.
Sigh.
Ciao,
Michael.
P.S: some of the reindendation changes look like as if you've replaced
leading tabs with four spaces. That would have been wrong, tabs are eight
spaces. If this is the case, fix your editor settings.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] defined twice error commented out
Hi,
On Sun, 25 Oct 2015, Sergey Korshunoff wrote:
> Hi! Commented out a tcc_error_noabort("'%s' defined twice"... on mob
> gcc-3.4.6 don't give such error by default
> example file1.c
> char __version_303_;
> void func1() {}
> example file2.c
> char __version_303_;
> void func2() {}
> int main() { return 0; }
> I think there must be a switch to supress such message as minimum
No, please keep the message. That GNU ld doesn't error out in this case
is a side-effect of GCC using common symbols. If it wouldn't then also ld
would error. Try compiling the above with -fno-common and GCC and you'll
see it.
It would also error out if you would initialize both definitions. So,
please revert.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] defined twice error commented out
Hi, On Thu, 29 Oct 2015, grischka wrote: > Michael Matz wrote: > > ... In C it's not allowed to have two definitions of the same non-static > > symbol, simple as that. It's not only for when initialized with different > > values or the like; it's undefined no matter what. > > Maybe it isn't that clear. See below from the c99 draft, in particular > the word "tentative". Yes, but multiple tentative definitions are only allowed inside one translation unit, where they then collapse into one definition equivalent to one initialized by 0. When multiple such translation units are involved then 6.9#5 comes into play: 5 An external definition is an external declaration that is also a definition of a function (other than an inline definition) or an object. If an identifier declared with external linkage is used in an expression (other than as part of the operand of a sizeof operator whose result is an integer constant), somewhere in the entire program there shall be exactly one external definition for the identifier; otherwise, there shall be no more than one. In particular exactly one definition if the identifier is used; and not more than one when it's unused. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Shared libraries: startup and cleanup
Hi,
On Thu, 10 Sep 2015, Jared Maddox wrote:
> Does anyone remember if this is supposed to currently work? Is there
> some sort of caveat, such as requiring a linker flag or script?
No, it's simply not implemented, and even hacks aren't working. The
ctor/dtor attributes aren't implemented, and for the section attributes to
work some stuff in TCCs linker is missing:
.init/.fini sections have to contain straight line code actually calling
the function in question (the content of .init/.fini simply is run from
the dynamic loader, so placing functions therein doesn't work, you have to
place code snippets calling functions into it). Something like this:
struct S {unsigned opcode; unsigned ofs;};
struct S dtorref __attribute((section(".fini"))) = {0xe8909090,
(unsigned)( ((char*)dtor) - (char*) + 5) };
Don't bother to try, the TCC linker has another problem in that it emits a
64bit relocation for the reference to dtor where it's actually a 32bit
field (the call offset), and doesn't support this kind of pointer
arithmentic anyway.
The modern way of actually emitting ctors/dtors is not .init/.fini but
rather .init_array and .fini_array. Those are sections simply containing
pointers to functions to be called as ctors resp. dtors. Like so:
#define A __attribute((section(".init_array")))
void * ctorref A = ctor;
On some glibc dynamic linkers this already works, but it doesn't work for
dtors. This again is because TCCs linker doesn't generate the right
information, in this case the executable or shared lib needs DT_INIT_ARRAY
and DT_FINI_ARRAY dynamic entries that describe where those pointer arrays
are placed (basically the bounds of the .init_array/.fini_array sections).
Even linking with gcc (circumventing TCCs linker) doesn't help, because
TCC generates the .init_array sections with 32byte alignment, whereas it
has to be 8 bytes (on 64bit machines), so there's zero padding from other
object files (crtbegin.o usually) that makes it crash at runtime.
So, all in all, there is currently no way to make it work with TCC in
purely C. You have to resort to assembler, for instance:
% cat ctortest-ctors.s
.section .init_array
.quad ctor
.section .fini_array
.quad dtor
Then link with GCC (and the built-in assembler of TCC doesn't work on the
above).
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] segmentation fault on any code compiled by tcc with glibc 2.21
Hi, On Tue, 15 Dec 2015, Vincent Lefevre wrote: With glibc 2.21 (Debian/unstable on x86_64), on any code compiled by tcc segfaults. This occurs with both old tcc (tcc 0.9.27~git20140923.9d7fb33-3 Debian package) and mob. I wonder whether this is a bug in tcc or in the glibc. According to Aurelien Jarno, this is actually due to new binutils relocations (and the Debian glibc 2.21-4 package is built with a recent binutils, hence the problem with it). Details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808008#22 Blaeh. I didn't consider the case of the libc runtime startup .o files when agreeing to the new relocs. Arguably those object files exposed to every linker trying to create user-space programs shouldn't use the new relocs (they provide a very minor performance benefit sometimes) even with new binutils (and so that's a QoI issue in glibc), but it's easy enough to deal with them in tcc. Try newest mob again. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc mob regression on x86_64
Hi, On Thu, 17 Dec 2015, Aharon Robbins wrote: TCC on x86_64 is broken (again) when used to create .so files. I like to use it for gawk development since it's fast. Unfortunately, all the shared library stuff no longer works. This can be reproduced using the current version: wget ftp://ftp.gnu.org/gnu/gawk/gawk-4.1.3.tar.gz tar -xpzvf gawk-4.1.3.tar.gz cd gawk-4.1.3 PATH=/tmp/tcc/bin:$PATH # or wherever you have latest mob ./configure CC=tcc && make make check This used to work... Fixed in mob. Edmund, you might want to review other cases as well (it's your introduction of read32le everywhere), but I think I got all (two of them). Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Windows debugger which understands tcc generated debug symbols?
Hi, On Sat, 19 Dec 2015, Jeremy Kvurr wrote: Hello. I know about the existance of the -g option in the tcc, but I don't know how to enable a source-level debugging using this debug info. I tried to run the tcc-generated program with winedbg, but he hasn't recognised the symbols it seems. And I want to know where this debugging info is placed in the exe, and what format does it use. It uses the stabs debugging format. But only a very restricted subset, namely only line information (i.e. filenames, include hierarchy, function names, source line numbers). The info is in the .stab and .stabstr sections. gdb is able to interpret this debug format, I don't know other windows debuggers. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] -Wl,-rpath not passed through?
Hi, On Mon, 6 Jun 2016, Steffen Nurpmeso wrote: > Bäh! > Take this one, please, the other one deleted an option. > Ciao! I think this leaks memory when opath contains a string already. pbuf is allocated memory, you free the opath, copy pbuf into npath, but then leak pbuf itself (it's not leaked when opath is NULL, then it's freed in the next call as opath). valgrind should find it. Fix that and push to mob I'd say. Ciao, Michael.___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] -Wl,-rpath not passed through?
Hi, On Sat, 4 Jun 2016, David Mertens wrote: Nice. I am not very familiar with this part of tcc, but I noticed the use of ':' as a path separator. Is this the path separator used across all platforms? Yes. On all those that support DT_RPATH or DT_RUNPATH, which is an ELFism ... In particular, what about Windows? ... and hence Windows simply doesn't and isn't affected. Also, I am not sure what others think about the first line in which you declare two integers and initialize them with the return values of function calls. I guess that's fine, but I don't see it often in the codebase. @Everyone, do we have a coding standard about this? No. IMHO it's fine. Push to mob. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] realpath(x, NULL) doesn't work with tcc(1)
Hi,
On Thu, 2 Jun 2016, Steffen Nurpmeso wrote:
Well, have i yet asked this? I think no...
It's like that for a long time, ever since i use tcc(1) (autumn
last year):
?0[steffen@wales tmp]$ cat t.c
#include
int main(void){
char *x = realpath(".", NULL);
return (x != NULL) ? 0 : 1;
}
?0[steffen@wales tmp]$ for i in clang gcc tcc; do \
$i -o zt t.c && ./zt; echo $i: $?;\
done
clang: 0
gcc: 0
tcc: 1
tcc(1) only gets realpath(3) with buffer argument right, i wonder
what that can be?
Wow. You've run into the result of an unimplemented feature of tcc, which
I never thought would matter in practice ;-) I'll explain, bear with me:
in POSIX 2001 the result of using NULL as 'resolved_path' argument to
realpath(3) was left implementation defined. This was an unworkable
interface (you basically had no way of finding out if the returned buffer
has overflown), so in POSIX 2008 this was specified universally as meaning
to malloc the returned buffer. Now, glibc at the time (versions < 2.3)
was using that old standards freedom to define this as unsupported. You
will see in your program that errno is set to EINVAL after realpath
returns NULL with a NULL second argument.
Later glibc introduced the newer and more sensible behaviour with
accepting NULL as second argument. But glibc also has a strict no change
in interfaces policy, and this was a visible change, so symbol versioning
had to be used to provide the old behaviour for old applications (those
linked with glibc < 2.3) and new behaviour for new ones. So, since then
glibc exports two variants of realpath: realpath@GLIBC_2.2.5 and
realpath@@GLIBC_2.3. Normally when linking executables against a
libc providing these two symbols the link editor, when it supports symbol
versions, will choose the newest one, record that fact into the
executable, and when running the dynamic linker will search for
realpath@GLIBC_2.3 and use it.
"when it supports symbol versions" is of course the crucial part: tcc as
ELF linker doesn't. So it leaves in an unversioned reference to
'realpath' in the executable and so the dynamic linker is free to choose
any. Now the usual ld.so uses a (normally) sensible heuristic for
choosing which one when there are several: for references from dlsym it
uses the newest available one, for references from applications that have
no symbol version information whatsoever it uses the oldest symbol
version, on the grounds that apps without any symversion info must have
been created before the ELF implementation provided them, i.e. they must
be very very old applications.
This reasoning breaks down with an incomplete link editor like tcc. It
creates new applications that are regarded as very old by ld.so. So, what
you see is ld.so resolving to the old implementation of realpath, instead
of the current one.
Short of implementing proper ELF symbol versioning in tcc there's only an
ugly work-around: you could use a different link editor. Perhaps there's
somewhen a rainy weekend when the former can be done.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tccgen.c: off by one in flexible array members
Hi,
On Fri, 11 Mar 2016, Michael Matz wrote:
This whole thing also points out some deficiencies of tcc to emit error
messages. For instance it accepts the initialization
void f(void) {
struct w q = {"bugs", { 'c' } };
}
(and sets ref->c to 1), even though this is a non-static initialization,
which is wrong (but the size adjustments needs also to be done for static
initialization).
And even that is only a GCC extension. One isn't allowed to initialize
flex array members, only via malloc and assignments. (But the GCC
extension is probably quite prevalent as GCC doesn't even warn about it in
conformant mode.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Alternative tokens for C-application
Hi, On Thu, 10 Mar 2016, Мельников Алексей wrote: --> Urgs. Are you really using digraphs in any production code? --> (Yes, tcc tries to support c99, but, well, I mean, digraphs? Seriously? If you use EBCDIC you have more serious problems with tcc I guess, and if you don't, why use digraphs? Not as bad as trigraphs, but still.) I am searching new ways to use tcc for web developing. And I think digraphs syntax are combined better with html tags. I see, fair enough. I'll try to refrain from going "huh?" regarding tcc plus web developing (and that <> are special to html and part of every digraph), except in this sentence :) Ben, have you finished the patch? If so, please post here, have you measured compile time to be unaffected (would be bad if such a seldom used feature would cause a slowdown)? Ciao, Michael.___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tccgen.c: off by one in flexible array members
Hi,
On Fri, 11 Mar 2016, Michael Matz wrote:
it's now "size += -1 * 4 + 1" (i.e. +=3).
-=3 of course, but you got the idea :)
So, I think it's more correct to special case the ref->c == -1 case only
(don't adjust size in that case), instead of playing +-1 tricks (as in,
it's not a off-by-one error). Will think a bit over dinner :)
After dinner I still agree with me :) Pushed with a testcase.
This whole thing also points out some deficiencies of tcc to emit error
messages. For instance it accepts the initialization
void f(void) {
struct w q = {"bugs", { 'c' } };
}
(and sets ref->c to 1), even though this is a non-static initialization,
which is wrong (but the size adjustments needs also to be done for static
initialization). Probably this code can be simplified somewhat, but
that's for somewhen else.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] MAJOR bug: tcc doesn't detect duplicate cases in switch statements
Hi, On Sat, 12 Mar 2016, arn...@skeeve.com wrote: First, the bug can't be as MAJOR as the subject wants to make us believe. After all it wasn't noticed since the last $MANY years. The bug caused me to push bad code to gawk's repo. I assumed something like that. It still doesn't make the bug any more major than many of the other bugs that tcc has. It's only luck that it wasn't noticed, but a bug is a bug. Geting the right answer a little more slowly is always better than getting the wrong answer super fast. No, I don't agree with you that a missed diagnostics is in the same class like wrong-code bugs. Especially if it's costly to implement a diagnostic it's quite reasonable to not implement it in a compiler that's supposed to be quick (at least as long as there's other missing diagnostics). Unlike wrong-code bugs for instance (well, even there the world is not always black and white, only mostly so). The issue isn't just the lack of diagnostic - what kind of erroneous code is being generated in this case? Any we want. As the behaviour of the input was undefined the generated code can't be erroneous. In practice I can tell you: tcc translates a switch literally into a sequence of if-else tests, so the code with overlapping cases is simply: if (a == 1) ... else if (a == 1) ... So, first one matching wins. TCC is valuable for being both fast and correct. Lose the correctness and you lose ALL the value. Given those absolute terms, I don't know of any compiler that's correct. TCC certainly isn't. TCC isn't bad either in correctness, it's actually quite good, but not 100%. I hope you still continue to find TCC valuable, your use of it for serious development is much welcome :) And, of course, I'm not dead-set against giving a diagnostic. An implementation that's not making eyes bleed and is fast would be nice. E.g. remember cases in an array of ranges while parsing, qsort them after switch is finished, generated diagnostics on overlap. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] MAJOR bug: tcc doesn't detect duplicate cases in switch statements
Hi, On Sat, 12 Mar 2016, Daniel Glöckner wrote: The issue isn't just the lack of diagnostic - what kind of erroneous code is being generated in this case? Let's see what the final C11 draft (N1570) says about this issue: Section 6.8.4.2 paragraph 3: The expression of each case label shall be an integer constant expression and no two of the case constant expressions in the same switch statement shall have the same value after conversion. Section 4 paragraph 2: If a "shall" or "shall not" requirement that appears outside of a constraint or runtime-constraint is violated, the behavior is undefined. There you read it, C11 allows us to generate whatever we want. This is true. But you missed the detail that all constraint violations require a diagnostic (5.1.1.3), and the above citation is a constraint on switches. So, yes, TCC is not conforming :) Ciao, Michael.___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] MAJOR bug: tcc doesn't detect duplicate cases in switch statements
Hi,
On Fri, 11 Mar 2016, Amine Najahi wrote:
> Perhaps surprisingly, correcting this bug is quite costly. Here is a
> tentative patch. I find it messy but working with dynamic data and
> passing the cases to the block function are necessary to handle an
> "unlimited number" of cases and nested switch blocks.
>
> Also, since the 'block' function is starting to have too many arguments,
> I suggest to create a structure that assembles related arguments such
> that def_sym, case_sym, cases, and cases_cnt, and any other...
>
> Does that sound ok?
I'm not a big fan of this solution. First, the bug can't be as MAJOR as
the subject wants to make us believe. After all it wasn't noticed since
the last $MANY years. Secondly it's inherently costly (as you notice) to
do such checking in a single-pass compiler; that's simply expected of the
approach that TCC takes to reach the speed. Third, you don't handle the
GNU extension "case 1 .. 3" at all. I think you handle this correctly:
switch (a) {
case 1:
switch (b) {
case 1: break; // no error here
}
break;
case 1: break; // but an error here
}
so, that's nice. But still, I don't think it's worth it. (Hey, in a way
not erroring is even sort of logical, the error is only there because the
standard requires it; but if looking at the mirrored situation in an
if-cascade, "if (a == 1); else if (a == 1);" there's no error required).
I think there are quite many required diagnostics we don't do because of
the single-pass nature and I don't see why this one only should be fixed.
Perhaps I could be convinced by some speed measurements on a relevant
source base (not only tcc itself).
Ciao,
Michael.
P.S: Oh, and the dynarray API and usage is super ugly ;-)
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tccgen.c: off by one in flexible array members
Hi,
On Wed, 9 Mar 2016, Henry Kroll wrote:
I created a + 1 patch that seems to work, but I need to run more tests
before committing.
=
diff --git a/tccgen.c b/tccgen.c
index 3cd28ed..270d11c 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -5847,7 +5847,7 @@ static void decl_initializer_alloc(CType *type,
AttributeDef *ad, int r,
tcc_error("unknown type size");
}
if (flexible_array)
-size += flexible_array->type.ref->c *
pointed_size(_array->type);
+size += flexible_array->type.ref->c *
pointed_size(_array->type) + 1;
/* take into account specified alignment if bigger */
if (ad->a.aligned) {
if (ad->a.aligned > align)
=
Have a great day!
This still isn't quite right. The thing is, type->ref.c is -1 for an
unused flex array, so with your example ("char mem[]") your change
basically boils down to "size += -1 * 1 + 1" (i.e. +=0). But with a
different type (say int) it's now "size += -1 * 4 + 1" (i.e. +=3). So
this example still fails the same way:
-
#include
struct w {
char *data; int mem[];
};
int main (void) {
char s[9]="nonono"; struct w q = {"bugs"};
printf ("tcc has %s %s\n", s, q.data);
return !s[0];
}
-
(only changed the mem[] member type). The +1 also looks conceptually
wrong, we try to adjust the size by some number of elements. The example
works of course if you'd do
size += (flexible_array->type.ref->c + 1)
* pointed_size(_array->type)
But then it'll break this example: (well, not break it, but it seems it'd
allocate more then necessary), which actually does use the flex member:
-
#include
struct w {
char *data; int mem[];
};
int main (void) {
char s[9]="nonono";
struct w q = {"bugs", { 1 }};
printf ("tcc has %s %s\n", s, q.data);
return !s[0];
}
-
Here type->ref.c (after parsing the initializer) will be 1, the number of
elements used, and the original size calculation seems correct.
type->ref.c will be 0 if the flex member is there but empty (in the
initializer), so for that case the original is also correct.
So, I think it's more correct to special case the ref->c == -1 case only
(don't adjust size in that case), instead of playing +-1 tricks (as in,
it's not a off-by-one error). Will think a bit over dinner :)
diff --git a/tccgen.c b/tccgen.c
index 270d11c..896a520 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -5846,8 +5846,10 @@ static void decl_initializer_alloc(CType *type,
AttributeDef *ad, int r,
if (size < 0)
tcc_error("unknown type size");
}
-if (flexible_array)
-size += flexible_array->type.ref->c *
pointed_size(_array->type) + 1;
+if (flexible_array
+ /* If the flex member was used in the initializer. */
+ && flexible_array->type.ref->c > 0)
+size += flexible_array->type.ref->c *
pointed_size(_array->type);
/* take into account specified alignment if bigger */
if (ad->a.aligned) {
if (ad->a.aligned > align)
Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] MAJOR bug: tcc doesn't detect duplicate cases in switch statements
Hi, On Sun, 13 Mar 2016, arn...@skeeve.com wrote: > Whoever it was that posted the note about the standard requiring a > diagnostic was right on target. It was me ... > This is too fundamental a mistake not to diagnose. ... making a concious decision to conditionally disagree with you (namely on your unspelled but implied "at all costs"). > But since I don't make commits, I'll stop complaining. I will also most > likely stop using tcc, nor will I recommend it in the future. > > Good luck folks, you're gonna need it. Please don't rage-quit, the bug reports coming out of gawk development are appreciated. You're one of the few serious tcc users we know about :) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Attributes position on structs/unions
Hi, On Wed, 6 Apr 2016, Vladimir Vissoultchev wrote: https://github.com/wqweto/tinycc/commit/0691b7630b89bf3de5f7691802cb923bd7c1 fd99 Thanks, please push to mob. (It would be easier to review if you'd include the patch in plain text in your email. I for instance use a console based MUA, so opening URLs is a small hassle.) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] GAS symbols
Hi,
welcome to TCC development :)
On Mon, 14 Mar 2016, Vladimir Vissoultchev wrote:
> A symbol is one or more characters chosen from the set of all letters
(both upper and lower case), digits and the three characters _.$. No
> symbol may begin with a digit. Case is significant. There is no length
limit: all characters are significant. Symbols are delimited by
> characters not in that set, or by the beginning of a file (since the
source program must end with a newline, the end of a file is not a
> possible symbol delimiter). See Symbols.
So it seems labels can indeed start with and contain dots. Am I correct in
understanding this text?
Yes, GAS labels. There's no universal convention for assemblers. Being
compatible with GAS does make sense (when easily possible), so yeah, such
change seems appropriate.
Also, what is the polite way to commit in mob branch? Do you practice
sending patches to the list beforehand so that anyone can chime in with
problems spotted?
No formal process exists, but if you're a new developer sending patches
beforehand would be appreciated, especially so for new features, because
the feature might not even be wanted (or in a different form).
I'm sorry my first commits were out of nowhere and then had to revert
some rogue changes that broke some tests. Now I have the tests working
under MinGW.
Some comments on some of those patches (such comments are also easier when
the patch was in a mail :) ):
case TOK_CLDOUBLE:
cstr_cat(_buf, "");
+cstr_ccat(_buf, '\0');
You made it such that most cstr_cat calls (except two and those in
i386-asm.c) are now followed by cstr_ccat(0). Consider adding a
cstr_catz() routine that does both.
+/* keep structs lvalue by transforming `(expr ? a : b)` to `*(expr~
+ that `(expr ? a : b).mem` does not error with "lvalue expected~
+islv = (vtop->r & VT_LVAL) && (sv.r & VT_LVAL) && VT_STRUCT == (ty~
+
Please respect a 80 characters per line limit. It's not always currently
respected, but we shouldn't introduce new over long lines.
Also, this specific change could use a testcase to not regress in the
future.
-} else if (c == '.') {
-PEEKC(c, p);
-if (c == '.') {
-p++;
-tok = TOK_DOTS;
-} else {
-*--p = '.'; /* may underflow into file->unget[] */
-tok = '.';
-}
+} else if ((isidnum_table['.' - CH_EOF] & IS_ID) != 0) { /* asm mode */
+*--p = c = '.';
+goto parse_ident_fast;
+} else if (c == '.' && p[1] == '.') {
+p += 2;
+tok = TOK_DOTS;
As you removed the PEEKC call you mishandle quoted line-endings. For
instance the following decl is conforming and hence the ..\\n. must be
parsed as one token, TOK_DOTS:
int f (int a, ..\
.);
This feature could also do with a testcase.
One more remark about future git commit messages: please follow the usual
git convention. From git-commit(1):
Though not required, it’s a good idea to begin the commit message with
a single short (less than 50 character) line summarizing the change,
followed by a blank line and then a more thorough description. The text
up to the first blank line in a commit message is treated as the commit
title, and that title is used throughout git.
Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] GAS symbols
Hi, On Thu, 17 Mar 2016, Vladimir Vissoultchev wrote: > About the TOK_DOTS saga -- yes, the original code was using PEEKC > canonically, I'm not sure about the unget hack it implemented though. It is, as the comment written next to it explained. I fixed the parsing of ..\n. now in mob with a testcase. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
