Re: [Tinycc-devel] Straightening out x86_64 build?
Hi! Try to test an attached patch. I tested it only on x86 ububtu 03-ubuntu-config.patch Description: Binary data ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Straightening out x86_64 build?
The patch 03-ubuntu-config.patch doesn't work on Debian arm64. It can't find crt1.o because it's looking in "/usr/lib/aarch64-linux-gnu/aarch64-linux-gnu". Also, since that stuff is already very hard to understand I think we should be aiming to simplify it rather than add yet more configuration variables with names like SYSINCLUDEPATHS_ADDON. Edmund ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] regressions on i386
On March 6, 2015 3:46:46 AM GMT+08:00, Edmund Grimley Evans wrote: > > Then commit 76af94862352a3f1d26249d9ea6f795d107c1d7f broke building: > > ../tcc -B.. -c libtcc1.c -o i386/libtcc1.o -I.. -Wall -g -O2 > -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare > -Wno-unused-result -fPIC -DTCC_TARGET_I386 > In file included from libtcc1.c:31: > In file included from /usr/include/stdint.h:26: > /usr/include/features.h:323: error: include file 'bits/predefs.h' not > found > make[1]: *** [i386/libtcc1.o] Error 1 > make[1]: Leaving directory `/tmp/tt/lib' > > > I believe it's also now broken on Debian arm64 and Ubuntu x86_64. Does > it work for anyone? I have the same problem. I tracked it down to lines 92-112 [1]. The problem comes from adding the _LINK variable containing the arch-qualified symlink to the native compiler into PROGS. This causes these symlink files to be interpreted as target to be built and they then match the pattern for cross-compilers. Since these does not use multiarch by default, the build fails when trying to use them to compile libtcc1. Even on non-multiarch systems this approach is wrong as it would leads to 2 builds if I'm correct. The right approach is to extend the recipe for building native compiler in the same way as cross-compiler with an extra symlink step. [1] http://repo.or.cz/w/tinycc.git/blob/5de8b5638f3d0bca6723d5d63d9e22a7f04fff6c:/Makefile#l92 Seiko, can you fix this along those lines? Best regards, Tom ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] RE :Re: 1cbb4d322bc3c89a3b56d35c803a19f99f33ab65 broke tcc on arm (RPi) 6 days ago
Le mardi 10 mars 2015, 11:37:30 Christian JULLIEN a écrit : > > > PS: arm-tcc can be a cross-compiler on x86. Can it compile arm *.S > files in such case? No because there is no support for ARM assembly. So no matter if it's a native or cross compiler tcc cannot compile any ARM .S file. 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] [PATCH] deprecating VT_REF
Le dimanche 22 février 2015, 00:16:20 Michael Matz a écrit : > Hi, > > On Sat, 21 Feb 2015, Edmund Grimley Evans wrote: > > > > 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. FWIW, I fully agree. > > 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. No matter which one is used, it would be nice to use the name VT_REF as the name encompasse better what it is about: a value for a memory reference that contains the address of another value. The name VT_LLOCAL refers to much to the purpose of VT_LVAL on stack. 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] [PATCH] TCC arm64 back end
Le dimanche 22 février 2015, 06:13:21 Michael Matz a écrit : > Hi, > > > 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 ... :-) I think that's the next thing I'm going to work on. And then maybe simplify the Makefile and configure machinery but that's less fun and easier to break in my experience. I already started looking at bind_exe_dynsyms and why it's needed. All I can say for now is that without it the linking fails on x86-64 because of unresolved __libc_start_main. This is unsurprisingly provided by the libc. From what I understand a symbol is considered unresolved if it cannot be found in the dynsym section of the output file and it seems only relocation handled in build_got_entries leads to a dynsym being created. However __libc_start_main has a R_X86_64_PC32 that doesn't lead to a got + plt so no entry created in dynsym. I probably won't write any code tonight and it'll take time but we'll get things cleaned up eventually. 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] [PATCH] TCC arm64 back end
Thomas: >> 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 ... :-) > > I think that's the next thing I'm going to work on. In that case I should quote this, which only went to Michael, I think: > The main defect is linking. I've just discovered that even with the > work-around of using R_AARCH64_MOVW_UABS_G0_NC,... instead of > R_AARCH64_ADR_PREL_PG_HI21 "make test" won't always work: "make > libtest" can fail because code generated with libtcc does not use a > PLT. I've just been lucky that it works in the chroots I usually use. See also my message dated Sat, 28 Feb 2015 09:36:39 +. There seems to be a general problem with TCC not using a PLT when it should. Without the PLT it works all of the time on i386 and some of the time on arm64, depending on the environment. So you really need to print the addresses that are being used to check that they are in the PLT and that TCC isn't trying to branch directly to a different library/executable which might not necessarily be within range of a branch instruction. Edmund ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Straightening out x86_64 build?
Le mardi 10 mars 2015, 20:02:51 Sergey Korshunoff a écrit : > > A crt*.o searching on Debian/Ubuntu is another problem. > > > >> A problem you caused? > > A problem was caused by a Debians boys I think. Please refrain from such generalization. Being a small project I'm pretty sure all people involved in development of TinyCC make their own decision and work on it because they care about this project. > > > In general, could you please be a bit more careful > > The same suggestion for debian boys. I only reverted a commit "Set > CONFIG_MULTIARCHDIR for cross compilers" It was only debian oriented > "and breaks x86 / x86_64 compilres for linux" other then debian. > Correct me if I wrong. Yes, this applies to everybody. It's ok to break things occasionally, I broke things an important number of times myself as long as one fixes his mistake (of course it's fine for other people to fix it before if they wish). As I've said before, I encourage people to submit patches if they are unsure about them or if they often broke things. I tend to include myself in this latter category. I acknowledge that the review bandwith is quite low (I myself don't have as much time as I would like to dedicate to tcc and am slow at reviewing) which is why patch review is not mandatory. 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] [PATCH] TCC arm64 back end
I wrote:
> There seems to be a general problem with TCC not using a PLT when it
> should. Without the PLT it works all of the time on i386 and some of
> the time on arm64, depending on the environment. So you really need to
> print the addresses that are being used to check that they are in the
> PLT and that TCC isn't trying to branch directly to a different
> library/executable which might not necessarily be within range of a
> branch instruction.
I'll try to be more specific. For example, take this program:
#include
#include
#include
int main()
{
printf("PLT:\n");
printf("%p atoi\n", atoi);
printf("%p printf\n", printf);
printf("%p sin\n", sin);
printf("GOT:\n");
printf("%p signgam\n", &signgam);
printf("%p stdin\n", &stdin);
printf("%p stdout\n", &stdout);
printf("%p stderr\n", &stderr);
return 0;
}
If you run it you should get something like:
PLT:
0x4006a0 atoi
0x400660 printf
0x400690 sin
GOT:
0x601050 signgam
0x601048 stdin
0x601040 stdout
0x601058 stderr
Note how all the PLT addresses, and all the GOT addresses are close to
each other.
The same should be true when the program is linked by TCC, or executed
using tcc -run, or run with libtcc, I think. Currently it isn't, if I
recall correctly.
Edmund
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] deprecating VT_REF
Currently I find that whenever I reread the descriptions, in tcc-doc and tcc.h, of the various VT values I find myself understanding how they work worse afterwards than before. I'm not sure how the descriptions achieve this level of confusiveness; I think it's perhaps because of the way the descriptions mix source and target, meaning and use, and how a term like "lvalue" sometimes means the pointer and sometimes the thing pointed to, and how the terms "lvalue", "pointer" and "reference" are used without any clear distinction. I don't know that I can do any better, but here's an attempt. Perhaps someone can suggest improvements. The r (and r2) fields of SValue record how and where a value is stored. The value or r is one of the following base values possibly bitwise ORed with some of the following flags. # Base values A register number, from 0 to VT_CONST - 1. The value is in the register. VT_CONST The value is a constant, stored in SValue.c. VT_LOCAL The value is an offset on the stack, typically the address of a local variable. The offset is stored in SValue.c.i. VT_LLOCAL The same as VT_LOCAL but with another level of indirection. VT_LLOCAL is only used together with VT_LVAL to mean that the value is pointed to by an address on the stack. This typically arises when a (register | VT_LVAL) has to be saved to the stack, but it also can come from an architecture-specific calling convention. VT_CMP The value is 0 or 1 and represented in the processor flags. The way it is represented is indicated in SValue.c.i. VT_JMP VT_JMPI ... # Flags VT_LVAL Add one level of indirection. So (register | VT_LVAL) means the value is pointed to by an address in a register, and (VT_LOCAL | VT_LVAL) means the value is pointed to by an offset on the stack, in other words, that the value is on the stack, for example the value of a local variable. VT_REF Add another level of indirection. So (VT_LOCAL | VT_LVAL | VT_REF) means the value is pointed to by a value on the stack. VT_REF is only used together with VT_LVAL, and currently it is only used together with VT_LOCAL and only when the value is a structure. VT_REF must not be used together with VT_LLOCAL. (VT_LOCAL | VT_LVAL | VT_REF) means the same as (VT_LLOCAL | VT_LVAL) but the two are currently used in different parts of the code. VT_SYM The symbol SValue.sym must be added to the value. VT_SYM is only used together with VT_CONST. VT_MUSTCAST Used together with a register value to indicate that an integer stored in a register must be cast to the value type if the value is used (lazy casting). VT_LVAL_BYTE VT_LVAL_SHORT VT_LVAL_UNSIGNED I don't properly understand these. The current description is: "if the lvalue has an integer type then these flags give its real type. The type alone is not enough in case of cast optimisations." Presumably "the lvalue" means "the value, which is stored in memory", but what does "real type" mean? It sounds very philosophical. Perhaps the description ought to be something like: When VT_LVAL is set, these flags must also be set appropriately to indicate the size and sign of the value stored in memory. Who knows? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] some thoughts on the search path mess
Currently the search paths for a non-cross tcc on Debian arm64 look like this (./tcc -vv): crt: /usr/lib/aarch64-linux-gnu libraries: /usr/lib/aarch64-linux-gnu /usr/lib /lib/aarch64-linux-gnu /lib /usr/local/lib/aarch64-linux-gnu /usr/local/lib include: /usr/local/include/aarch64-linux-gnu /usr/local/include /usr/include/aarch64-linux-gnu /usr/include /usr/local/lib/tcc/include Does that seem correct? I note that /usr/local/lib comes after /usr/lib, but /usr/local/include comes before /usr/include. Why is that? Also, should /usr/lib be on the search path for crt? Also, is it correct for /usr/local/lib/tcc/include to come last rather than first in the "include" list? Presumably the search paths for any other Debian architecture could be the same with the appropriate triplet substituted for "aarch64-linux-gnu". Now, it seems that some other Linux distributions use lib32 and lib64. Is that only on Intel, or do they do the same on other architectures that have 32-bit and 64-bit variants? What should the search paths look like on one of those Linuxes? A general question: should "configure" try to work out what kind of Linux we're on, or it should it just merrily include all the possibilities in the search paths? The situation for a cross compiler is mostly very similar, except: * You can't run a test program. But TCC's configure doesn't do that anyway. * There's no point in including generic paths like /usr/lib in the search paths. They are almost certainly wrong. However, if you're cross-compiling between variants of the same architecture then it probably make sense to include things like /usr/lib32 in the paths. * With a cross-compiler it's quite probable that the user will install libraries after building TCC so it perhaps makes more sense to include directories that don't yet exist in the search paths. That last point suggests that for symmetry between cross and non-cross compilers it might make sense to put, by default, all likely directories into the search path whether or not they exist. Another general point: You can put complex "sh" logic in "configure", complex "make" logic in "Makefile", or complex "cpp" logic in the C source files: a choice of three crap programming languages! If you're a masochist, you can also put double-escaped sh code in the Makefile. Also, you can make the logic at each stage attempt to pre-empt bzw. second-guess what the logic at other stages has done or will do. I tend to think that "configure" is probably the best place to do things as "sh" is arguably the least hostile of the three environments. Also, configure produces a human-readable output and you can insert print statement into it, both of which help with debugging. Thoughts? Edmund ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] regressions on i386
There is a patch in discussion which try to solve this problem. 2015-03-11 14:27 GMT+03:00, Thomas Preud'homme : > On March 6, 2015 3:46:46 AM GMT+08:00, Edmund Grimley Evans > wrote: >> >> Then commit 76af94862352a3f1d26249d9ea6f795d107c1d7f broke building: >> >> ../tcc -B.. -c libtcc1.c -o i386/libtcc1.o -I.. -Wall -g -O2 >> -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare >> -Wno-unused-result -fPIC -DTCC_TARGET_I386 >> In file included from libtcc1.c:31: >> In file included from /usr/include/stdint.h:26: >> /usr/include/features.h:323: error: include file 'bits/predefs.h' not >> found >> make[1]: *** [i386/libtcc1.o] Error 1 >> make[1]: Leaving directory `/tmp/tt/lib' >> >> >> I believe it's also now broken on Debian arm64 and Ubuntu x86_64. Does >> it work for anyone? > > I have the same problem. I tracked it down to lines 92-112 [1]. > > The problem comes from adding the _LINK variable containing the > arch-qualified symlink to the native compiler into PROGS. This causes these > symlink files to be interpreted as target to be built and they then match > the pattern for cross-compilers. Since these does not use multiarch by > default, the build fails when trying to use them to compile libtcc1. > > Even on non-multiarch systems this approach is wrong as it would leads to 2 > builds if I'm correct. The right approach is to extend the recipe for > building native compiler in the same way as cross-compiler with an extra > symlink step. > > [1] > http://repo.or.cz/w/tinycc.git/blob/5de8b5638f3d0bca6723d5d63d9e22a7f04fff6c:/Makefile#l92 > > > Seiko, can you fix this along those lines? > > Best regards, > > Tom > > ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
