Re: [Tinycc-devel] Recent changes segfault on Linux ARM
Le jeudi 6 juin 2013 06:37:39, Christian Jullien a écrit : Hi all, Is someone working on this issue? Raspberry Pi is still broken (tested with last night commit) ret_double_test... success ret_longdouble_test... success ret_2float_test... Segmentation fault Sorry no. I haven't had any time for tcc in the past weeks due to my PhD defense approaching. I shall have a bit more time again from next tuesday but then holidays will come quickly. I'll try to take a look next week. Christian Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
On Fri, Apr 26, 2013 at 10:58:39PM +0200, Daniel Glöckner wrote: There are two things broken in the code generated by TCC: First of all TCC thinks it has to return the structure in memory pointed to by r0 and second it gets confused about where it stored r0 and instead reads the first float from the stack and interpretes that as a pointer. The latter should be fixed by the one-liner I just committed. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
Hi Daniel ARM hardfloat: fix struct return with float/double args Fixes the case where the structure is not returned in registers. I thought it was related to ret_2float_test At least on Rpi I still have: ret_2float_test... Segmentation fault C. P.S. Compiled from a fresh git -Original Message- From: tinycc-devel-bounces+eligis=orange...@nongnu.org [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Daniel Glöckner Sent: mercredi 1 mai 2013 16:40 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Recent changes segfault on Linux ARM On Fri, Apr 26, 2013 at 10:58:39PM +0200, Daniel Glöckner wrote: There are two things broken in the code generated by TCC: First of all TCC thinks it has to return the structure in memory pointed to by r0 and second it gets confused about where it stored r0 and instead reads the first float from the stack and interpretes that as a pointer. The latter should be fixed by the one-liner I just committed. Daniel ___ 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] Recent changes segfault on Linux ARM
Hi Christian, On Wed, May 01, 2013 at 04:44:09PM +0200, Christian Jullien wrote: ARM hardfloat: fix struct return with float/double args Fixes the case where the structure is not returned in registers. I thought it was related to ret_2float_test At least on Rpi I still have: ret_2float_test... Segmentation fault well, it should still crash if you compile abitest.c with GCC, as the first of the two issues is not resolved. With TinyCC it should work though, judging from visual inspection of the disassembly. Which hardfp environment do you use for the Rpi? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
I simply do a ./configure Here are the lines I get gcc -o abitest-cc abitest.c ../libtcc.a -I.. -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -DCONFIG_LDDIR=\lib/arm-linux-gnueabihf\ -DCONFIG_MULTIARCHDIR=\arm-linux-gnueabihf\ -DTCC_TARGET_ARM -DWITHOUT_LIBTCC -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP -lm -ldl -I.. ../tcc -B.. -I.. -I.. -I../include -o abitest-tcc abitest.c ../libtcc.a -I.. -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -DCONFIG_LDDIR=\lib/arm-linux-gnueabihf\ -DCONFIG_MULTIARCHDIR=\arm-linux-gnueabihf\ -DTCC_TARGET_ARM -DWITHOUT_LIBTCC -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP -lm -ldl -I.. C. -Original Message- From: tinycc-devel-bounces+eligis=orange...@nongnu.org [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Daniel Glöckner Sent: mercredi 1 mai 2013 17:23 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Recent changes segfault on Linux ARM Hi Christian, On Wed, May 01, 2013 at 04:44:09PM +0200, Christian Jullien wrote: ARM hardfloat: fix struct return with float/double args Fixes the case where the structure is not returned in registers. I thought it was related to ret_2float_test At least on Rpi I still have: ret_2float_test... Segmentation fault well, it should still crash if you compile abitest.c with GCC, as the first of the two issues is not resolved. With TinyCC it should work though, judging from visual inspection of the disassembly. Which hardfp environment do you use for the Rpi? Best regards, Daniel ___ 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] Recent changes segfault on Linux ARM
Sure, of course. Actually, I've just had another look and I've realised I did screw up the ARM stuff - I was trying to maintain the existing behaviour since I didn't have a test system, but it looks like I messed it up. I think it's just a matter of deleting the first #ifdef TCC_ARM_EABI block from gfunc_call though. I'll try and get a look at it later but I can't promise much since I have zero experience of ARM development. Anyway, onto the stuff I fixed: Calling convention stuff: * Various x86 and x86-64 calling conventions pack structure return values into registers when they are small enough. I added gfunc_sret which determines whether that is the case and prevents an extra pointer parameter being added to receive the return value. It also returns the type used to pass the return value, so that tccgen.c can save it to the stack. Perhaps in retrospect it would have been better to move return value handling into target specific code generators, but anyway, it works. o x86-64: rules are rather complicated, see classify_x86_64_* functions and the SysV ABI. I had to add a register mode RC_QRET, analogous to RC_IRET, since a pair of doubles is returned in XMM0:XMM1. This in turn also means I have added support for XMM1-5 as general registers since since it was no more work than XMM1 alone. XMM6-7 aren't caller-saved on Win64 so I didn't make them available for calculation, although I did add them to the enumeration. Some cases also return 16-byte structures in RAX:RDX. o Win32: structures of 8-bytes or less are returned in EAX or EAX:EDX. o Win64: Structures of 8 bytes or less are returned in RAX. * Similarly, function arguments may be passed in registers rather than on the stack. o The SysV x86-64 ABI has rather complicated rules which I've implemented in classify_x86_64_* functions. o Win64 rules are somewhat simpler but (as far as I can tell, because MSs documentation isn't up to much) basically decide what to do based on whether the argument is larger or smaller than 8 bytes. Each argument gets 8 bytes of space in registers or on the stack; if the argument itself is 8 bytes or less it is passed in that space, otherwise it is passed by reference. o Win32 rules are the same as Linux-x86 except that small structures are returned in EAX:EDX. * x86-64 long double handling: added extra padding so that long doubles are aligned on 16-byte boundaries. There was already code to align the stack before the function call, but this actually has to be done each time a 16-byte aligned argument is encountered as well. * x86-64 varargs: I modified __builtin_va_arg_types to use the classify_x86_64_* functions, and added an alignment parameter to __va_arg so that 16-byte aligned long doubles can be handled. * Win64 varargs: I added __builtin_va_start on this platform since I couldn't see a way around it. If the last parameter (the second argument to va_start) on Win64 is larger than 8 bytes, it will be passed by reference, and va_start needs to get the address of the reference, which would require some sort of (x) type expression, which is obviously invalid C. I also redefined va_args. CMake build system: I added this primarily to make Win64 builds a lot easier since they then don't need a custom MSYS setup, just 64-bit gcc and mingw32-make which are available together. It should also work on other platforms where CMake is available. I had to shift tcclib.h out of the include/ directory to get some of the tests to work because there isn't a way in CMake to copy tcclib.h into the test directory, and other headers in include/ interfere with GCC compilation. Out-of-tree builds: there were a lot of small issues using the Makefiles for out of tree builds. They should now be self-updating (modifying the makefiles updates the out-of-tree copy). I've added $(top_srcdir)/... a lot to get file references right, and updated include paths where necessary. Variable length array stuff: VLAs were implemented using alloca() but the memory wasn't freed until the end of the function. This prevents VLAs from being used in a loop, for instance. This is pretty straightfoward to fix when goto and labels are not in use: just track whether the stack pointer has been modified and if so reset it at the end of each block. Goto handling is tricky because in a normal compiler we'd just work out what the stack pointer should be at the destination and set it before jumping. TCC can't do that because it generates code in a single pass, so what I did instead is that a goto with a VLA in scope saves the stack pointer and then resets it to its value when the outermost VLA was created. A label with a VLA in scope then reloads the appropriate stack pointer. Test cases are in vla_test.c. This does mean that in certain cases memory
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
Thanks, however I have to admit that I'm not particularly interested in TCC in the long term. I'm using it to JIT compile on Windows for the moment because it's a useful alternative to a full C compiler, and I basically fixed the things that prevented that working. As for ARM support for the same stuff, I'm not planning to work on it unless it determines whether my Win32/64 fixes make it into a release. On 29/04/13 00:14, Rob Landley wrote: On 04/26/2013 02:27:25 PM, James Lyon wrote: Hi, I don't have an ARM test system available but it is a new test... wget http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2 tar xvjf system-image-armv5l.tar.bz2 cd system-image-armv5l ./dev-environment.sh Now you do. (I also note that http://landley.net/qcc is my next todo project after toybox's 1.0 release, and since I got permission from Fabrice to use his original tcc code under a BSD license once I audit the third party contributions, I'm not going to be basing it on anything this project's done since then. *shrug*) Rob ___ 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] Recent changes segfault on Linux ARM
James Lyon wrote: Thanks, however I have to admit that I'm not particularly interested in TCC in the long term. ... and I basically fixed the things that prevented that working. Maybe you could at some point in time between too fresh to be sure and too old to care give some summary about what now you actually did. Unless that is sufficiently clear already from your commits and commit comments in which case please just ignore this message. Thanks, --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
On 04/26/2013 02:27:25 PM, James Lyon wrote: Hi, I don't have an ARM test system available but it is a new test... wget http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2 tar xvjf system-image-armv5l.tar.bz2 cd system-image-armv5l ./dev-environment.sh Now you do. (I also note that http://landley.net/qcc is my next todo project after toybox's 1.0 release, and since I got permission from Fabrice to use his original tcc code under a BSD license once I audit the third party contributions, I'm not going to be basing it on anything this project's done since then. *shrug*) Rob ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
Hi, I don't have an ARM test system available but it is a new test... The idea of abitest is to check compatibility of TCC calling convention with GCC, but I also made rather a lot of changes since compatibility with GCC on x86 an x86-64 had a lot of problems in corner cases. I think that ARM should use a hidden pointer to return the data in ret_2float_test, but reading the ARM EABI spec a structure with 2 floats in might count as a 64-bit containerized vector and thus would be returned in r0 and r1. In that case I think the thing to do is modify gfunc_sret to detect this. James On 26/04/13 19:59, Christian Jullien wrote: Here is the offending test : ../tcc -B.. -I.. -I.. -I../include -o abitest-tcc abitest.c ../libtcc.a -I.. -W all -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused- result -DCONFIG_LDDIR=\lib/arm-linux-gnueabihf\ -DCONFIG_MULTIARCHDIR=\arm -linux-gnueabihf\ -DTCC_TARGET_ARM -DWITHOUT_LIBTCC -DTCC_ARM_EABI -DTCC_ARM_H ARDFLOAT -DTCC_ARM_VFP -lm -ldl -I.. abitest ./abitest-cc lib_path=.. include=../include ret_int_test... success ret_longlong_test... success ret_float_test... success ret_double_test... success ret_longdouble_test... success ret_2float_test... Segmentation fault make[1]: *** [abitest] Error 139 make[1]: Leaving directory `/home/jullien/tinycc/tests' make: *** [test] Error 2 ___ 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] Recent changes segfault on Linux ARM
Le vendredi 26 avril 2013 21:27:25, James Lyon a écrit : Hi, I don't have an ARM test system available but it is a new test... The idea of abitest is to check compatibility of TCC calling convention with GCC, but I also made rather a lot of changes since compatibility with GCC on x86 an x86-64 had a lot of problems in corner cases. IMHO we should try to have the same behavior as gcc and clang. When they differ we might decide to follow either one or the other, except if there is a standard stating what is the right behavior. I think that ARM should use a hidden pointer to return the data in ret_2float_test, but reading the ARM EABI spec a structure with 2 floats in might count as a 64-bit containerized vector and thus would be returned in r0 and r1. In that case I think the thing to do is modify gfunc_sret to detect this. Indeed, such a structure qualify as 64-bit containerized vector. I handled that case when I added support for the hard float calling convention. You can see the is_float_hgen_aggr function that test this. James Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
On Fri, Apr 26, 2013 at 08:27:25PM +0100, James Lyon wrote: I think that ARM should use a hidden pointer to return the data in ret_2float_test, but reading the ARM EABI spec a structure with 2 floats in might count as a 64-bit containerized vector and thus would be returned in r0 and r1. In that case I think the thing to do is modify gfunc_sret to detect this. GCC with hard float ABI returns the structure in s0 and s1. There are two things broken in the code generated by TCC: First of all TCC thinks it has to return the structure in memory pointed to by r0 and second it gets confused about where it stored r0 and instead reads the first float from the stack and interpretes that as a pointer. And I am not happy that is_fconst() apparently does not work. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
On Fri, Apr 26, 2013 at 10:58:39PM +0200, Daniel Glöckner wrote: And I am not happy that is_fconst() apparently does not work. Scratch that. is_fconst() is for FPA an the VMOV (imm) instruction I saw in the output of GCC is VFPv3. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
