Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"
Hi, On Mon, 16 May 2016, Michael Matz wrote: Can you somehow find out which file and instruction is the one that's miscompiled? If you can, please attach the pre-processed source file here. That's not needed anymore, I found out myself. There were several pre-existing errors in the handling of arithmetic instructions with an imm8 operand: one that it accepted 8bit regs, and one that it accepted the xxxb form. I've corrected both in [mob]. I checked that tccboot works again. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"
Hello, On Sun, 15 May 2016, Sergey Korshunoff wrote: .fill problem is not fixed (on i386) Is the following patch correct? Yes. Using long was harmless on x86-64 (host), but wrong when the type of ExprValue->v is actually unsigned. Thanks for tracking this down. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"
Hi, On Mon, 16 May 2016, Sergey Korshunoff wrote: With the prev fix I still have a tccboot kernel trap on PCI bus configuration. What the purpose of the -ALT(DEF_ASM_OP2(addb, 0x80, 0, OPC_ARITH | OPC_MODRM | OPC_BWLX, OPT_IM, OPT_EA | OPT_REG)) ALT(DEF_ASM_OP2(addw, 0x83, 0, OPC_ARITH | OPC_MODRM | OPC_WLX, OPT_IM8S, OPT_EA | OPT_REG)) +ALT(DEF_ASM_OP2(addb, 0x80, 0, OPC_ARITH | OPC_MODRM | OPC_BWLX, OPT_IM, OPT_EA | OPT_REG)) in the "Fix signed constants and opcode order" ? The purpose is to prefer the short immediate forms of those instructions if the immediate value fits into 8 bit (signed). E.g. for add $-1,%ebx the encoding should be "83 c3 ff", not "81 c3 ff ff ff ff". I've tested multiple combinations of signed and unsigned constants (including the borders -129,-128,127,128,255,256) and the assembler itself does the right thing. Is it possible that the mishandled instructions doesn't have the above simple form, but perhaps that the immediate is calculated with asm expression? Can you somehow find out which file and instruction is the one that's miscompiled? If you can, please attach the pre-processed source file here. With thise change reverted there is no problem with tccboot kernel. I hope this means it's relatively simple to find out which file contains the problem. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"
Hi, On Sun, 15 May 2016, Sergey Korshunoff wrote: The idea of using only tcc headers for lib/* compilation might sound good at first, but tcc doesn't provide all standard headers (and shouldn't because it's not a full toolchain with C library); it really relies on the existence of working/compatible target headers that also the lib/* > implementation can use. But we can compile a cross-tcc compilers on i386 host w/o right headers for target. Why we stop on lib/* compilation? lib/* is a small support library for the target. Sure. Then first someone needs to rewrite the lib/* code such that it doesn't use any target headers at all. It don't use/need a full target headers. So, I offer two patches for you to try. The first (removing the typedefs from stddef.h) is more > correct, and the second might be more compatible with current behaviour. The first patch don't helps. Why not? (I.e. what's still broken?) And the second is not correct: with this patch a produced library use a host intptr_t (32 bit) for 64 bit targets. No. Read again: -#else +#elif defined(TCC_TARGET_X86_64) || defined(TCC_TARGET_ARM64) tcc_define_symbol(s, "__SIZE_TYPE__", "unsigned long"); tcc_define_symbol(s, "__PTRDIFF_TYPE__", "long"); +#else +tcc_define_symbol(s, "__SIZE_TYPE__", "unsigned int"); +tcc_define_symbol(s, "__PTRDIFF_TYPE__", "int"); #endif On the two real 64bit targets we have ptrdiff_t will be long (64bit), on the 32bit targets it will be int (32bit). (Well, and win64 is handled as before). Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"
> With the prev fix I still have a tccboot kernel trap on PCI bus configuration. What the purpose of the -ALT(DEF_ASM_OP2(addb, 0x80, 0, OPC_ARITH | OPC_MODRM | OPC_BWLX, OPT_IM, OPT_EA | OPT_REG)) ALT(DEF_ASM_OP2(addw, 0x83, 0, OPC_ARITH | OPC_MODRM | OPC_WLX, OPT_IM8S, OPT_EA | OPT_REG)) +ALT(DEF_ASM_OP2(addb, 0x80, 0, OPC_ARITH | OPC_MODRM | OPC_BWLX, OPT_IM, OPT_EA | OPT_REG)) in the "Fix signed constants and opcode order" ? With thise change reverted there is no problem with tccboot kernel. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"
> Is the following patch correct? With the prev fix I still have a tccboot kernel trap on PCI bus configuration. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"
> .fill problem is not fixed (on i386)
Is the following patch correct?
diff --git a/tccasm.c b/tccasm.c
index b494398..9dcab1c 100644
--- a/tccasm.c
+++ b/tccasm.c
@@ -42,7 +42,7 @@ static void asm_expr_unary(TCCState *s1, ExprValue *pe)
{
Sym *sym;
int op, label;
-long n;
+unsigned long n;
const char *p;
switch(tok) {
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"
.fill problem is not fixed (on i386) linux/arch/i386/kernel/head.S:380: error: repeat < 0; .fill ignored .org 0x1000 .globl swapper_pg_dir; .align 16,0x90; swapper_pg_dir: <-->.long 0x00102007 <-->.long 0x00103007 <-->.fill ((0xC000) >> 22)-2,4,0 Is a shift arithmetic there? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"
> And the second is not correct The second in my answer is stddef.h patch (removing the typedefs from stddef.h) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"
> The idea of using only tcc headers for lib/* compilation might sound good at > first, but tcc > doesn't provide all standard headers (and shouldn't because it's not a full > toolchain with C > library); it really relies on the existence of working/compatible target > headers that also the lib/* > implementation can use. But we can compile a cross-tcc compilers on i386 host w/o right headers for target. Why we stop on lib/* compilation? lib/* is a small support library for the target. It don't use/need a full target headers. > So, I offer two patches for you to try. The first (removing the typedefs > from stddef.h) is more > correct, and the second might be more compatible > with current behaviour. The first patch don't helps. And the second is not correct: with this patch a produced library use a host intptr_t (32 bit) for 64 bit targets. My solution is better in this aspect. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc compilation on MSYS2
> You can try my branch: https://github.com/avih/tinycc/commits/drafts (note, I > force-push and keep it rebased on top of mob). >I wanted to push some/all of the commits on my "drafts" branch to mob after >some cleanups, but never really got to end up doing it. If there's enough >interest and my current drafts branc ends up usable for many, I'll reconsider >putting the effort. Big thanks! I will try to test your branch. It is good to know any usefull branch of the tcc. PS: It was my first attempt to build tcc on Windows.. I think it is a ./configure error, which say OK for the unknown environment. Looking like Unix, I expected tcc build in the Unix way. PPS: For me Windows is foreign environment and configuring a PATH for the compiler/utilities is a problem. MSYS2 with a package manager looks like a primary target for the Unix man. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
