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] CValue
In case anyone else wants to play with this or test it on another
architecture. Please do, if you can.
I first changed the code using a one-line perl -i command, and was
surprised to find that most of the tests still passed after that. I
then fiddled around to make all the tests pass on arm64. I haven't
tested on other architectures, but it was at least possible to build
the cross compilers on i386.
If you're reading the diff, start by looking at what changed in tcc.h.
Everything else follows from that.
From: Edmund Grimley Evans edmund.grimley.ev...@gmail.com
Date: Sun, 8 Mar 2015 20:31:52 +
Subject: [PATCH] First attempt at merging all integer members of CValue.
In this patch they have all been replaced by uint64_t ii as that
makes it easier to find the affected code. A real commit would
probably use uint64_t i to reduce the number of changes.
---
arm-gen.c| 50 ++--
arm64-gen.c | 20 +++-
c67-gen.c| 17 ---
i386-asm.c | 12 ++---
i386-gen.c | 36 +++---
il-gen.c | 14 +++---
tcc.h|7 +--
tccasm.c |2 +-
tccgen.c | 150 +-
tccpe.c |4 +-
tccpp.c | 30 ++--
x86_64-gen.c | 52 ++--
12 files changed, 193 insertions(+), 201 deletions(-)
diff --git a/arm-gen.c b/arm-gen.c
index 3bb5326..d3b396f 100644
--- a/arm-gen.c
+++ b/arm-gen.c
@@ -528,7 +528,7 @@ void load(int r, SValue *sv)
fr = sv-r;
ft = sv-type.t;
- fc = sv-c.ul;
+ fc = sv-c.ii;
if(fc=0)
sign=0;
@@ -543,14 +543,14 @@ void load(int r, SValue *sv)
if(v == VT_LLOCAL) {
v1.type.t = VT_PTR;
v1.r = VT_LOCAL | VT_LVAL;
- v1.c.ul = sv-c.ul;
+ v1.c.ii = sv-c.ii;
load(base=14 /* lr */, v1);
fc=sign=0;
v=VT_LOCAL;
} else if(v == VT_CONST) {
v1.type.t = VT_PTR;
v1.r = fr~VT_LVAL;
- v1.c.ul = sv-c.ul;
+ v1.c.ii = sv-c.ii;
v1.sym=sv-sym;
load(base=14, v1);
fc=sign=0;
@@ -609,38 +609,38 @@ void load(int r, SValue *sv)
}
} else {
if (v == VT_CONST) {
- op=stuff_const(0xE3A0|(intr(r)12),sv-c.ul);
+ op=stuff_const(0xE3A0|(intr(r)12),sv-c.ii);
if (fr VT_SYM || !op) {
o(0xE59F|(intr(r)12));
o(0xEA00);
if(fr VT_SYM)
greloc(cur_text_section, sv-sym, ind, R_ARM_ABS32);
-o(sv-c.ul);
+o(sv-c.ii);
} else
o(op);
return;
} else if (v == VT_LOCAL) {
- op=stuff_const(0xE28B|(intr(r)12),sv-c.ul);
+ op=stuff_const(0xE28B|(intr(r)12),sv-c.ii);
if (fr VT_SYM || !op) {
o(0xE59F|(intr(r)12));
o(0xEA00);
if(fr VT_SYM) // needed ?
greloc(cur_text_section, sv-sym, ind, R_ARM_ABS32);
- o(sv-c.ul);
+ o(sv-c.ii);
o(0xE08B|(intr(r)12)|intr(r));
} else
o(op);
return;
} else if(v == VT_CMP) {
- o(mapcc(sv-c.ul)|0x3A1|(intr(r)12));
- o(mapcc(negcc(sv-c.ul))|0x3A0|(intr(r)12));
+ o(mapcc(sv-c.ii)|0x3A1|(intr(r)12));
+ o(mapcc(negcc(sv-c.ii))|0x3A0|(intr(r)12));
return;
} else if (v == VT_JMP || v == VT_JMPI) {
int t;
t = v 1;
o(0xE3A0|(intr(r)12)|t);
o(0xEA00);
- gsym(sv-c.ul);
+ gsym(sv-c.ii);
o(0xE3A0|(intr(r)12)|(t^1));
return;
} else if (v VT_CONST) {
@@ -667,7 +667,7 @@ void store(int r, SValue *sv)
fr = sv-r;
ft = sv-type.t;
- fc = sv-c.ul;
+ fc = sv-c.ii;
if(fc=0)
sign=0;
@@ -686,7 +686,7 @@ void store(int r, SValue *sv)
} else if(v == VT_CONST) {
v1.type.t = ft;
v1.r = fr~VT_LVAL;
- v1.c.ul = sv-c.ul;
+ v1.c.ii = sv-c.ii;
v1.sym=sv-sym;
load(base=14, v1);
fc=sign=0;
@@ -751,7 +751,7 @@ static void gcall_or_jmp(int is_jmp)
if ((vtop-r (VT_VALMASK | VT_LVAL)) == VT_CONST) {
uint32_t x;
/* constant case */
-x=encbranch(ind,ind+vtop-c.ul,0);
+x=encbranch(ind,ind+vtop-c.ii,0);
if(x) {
if (vtop-r VT_SYM) {
/* relocation case */
@@ -765,7 +765,7 @@ static void gcall_or_jmp(int is_jmp)
o(0xE51FF004); // ldr pc,[pc,#-4]
if (vtop-r VT_SYM)
greloc(cur_text_section, vtop-sym, ind, R_ARM_ABS32);
- o(vtop-c.ul);
+ o(vtop-c.ii);
}
} else {
/* otherwise, indirect call */
@@ -1419,19 +1419,19 @@ int gtst(int inv, int t)
v = vtop-r VT_VALMASK;
r=ind;
if (v == VT_CMP) {
-op=mapcc(inv?negcc(vtop-c.i):vtop-c.i);
+op=mapcc(inv?negcc(vtop-c.ii):vtop-c.ii);
op|=encbranch(r,t,1);
o(op);
t=r;
} else if (v == VT_JMP || v == VT_JMPI) {
if ((v 1) == inv) {
- if(!vtop-c.i)
- vtop-c.i=t;
+ if(!vtop-c.ii)
+ vtop-c.ii=t;
else {
uint32_t *x;
int p,lp;
if(t) {
- p = vtop-c.i;
+ p =
Re: [Tinycc-devel] broken tcc build after latest git pull
Hello list, 2015-03-09 10:17 GMT+08:00 Roy Tam roy...@gmail.com: Hello list, The compiled tcc binary is not able to compile itself, after git pull today: tcc -o i386-tcc.exe tcc.c -DONE_SOURCE -DTCC_TARGET_I386 -I. -O2 tcc: error: file 'crt1.o' not found tcc: error: file 'crti.o' not found In file included from tcc.c:22: In file included from libtcc.c:21: In file included from tcc.h:41: d:/tinycc/win32/include/time.h:12: error: #error Only Win32 target is supported! make: *** [i386-tcc.exe] Error 1 I found out that git 76af94862352a3f1d26249d9ea6f795d107c1d7f breaks building in MSYS, and TCC_TARGET_PE is not defined when building *tcc.exe! @seyko please fix it! for now I can provide a hack to workaround it: diff --git a/Makefile b/Makefile index 16b806c..a8572a8 100644 --- a/Makefile +++ b/Makefile @@ -156,6 +156,10 @@ PROGS+=$(PROGS_CROSS) TCCLIBS+=$(LIBTCC1_CROSS) endif +ifdef CONFIG_WIN32 +CPPFLAGS+= -DTCC_TARGET_PE +endif + all: $(PROGS) $(TCCLIBS) $(TCCDOCS) # Host Tiny C Compiler Regards, Roy ___ 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] broken tcc build after latest git pull
Hello list, The compiled tcc binary is not able to compile itself, after git pull today: tcc -o i386-tcc.exe tcc.c -DONE_SOURCE -DTCC_TARGET_I386 -I. -O2 tcc: error: file 'crt1.o' not found tcc: error: file 'crti.o' not found In file included from tcc.c:22: In file included from libtcc.c:21: In file included from tcc.h:41: d:/tinycc/win32/include/time.h:12: error: #error Only Win32 target is supported! make: *** [i386-tcc.exe] Error 1 I found out that git 76af94862352a3f1d26249d9ea6f795d107c1d7f breaks building in MSYS, and TCC_TARGET_PE is not defined when building *tcc.exe! @seyko please fix it! Regards, Roy ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] [PATCH] Convert some lines from ISO-8859-1 to UTF-8.
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? 2015-03-08-utf-8.patch.gz Description: Binary data ___ 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
[Tinycc-devel] (no subject)
I figured I'd reply to my own questions:
1) When compiling resources, just sticking with windres 32 bit hacked to
call tcc seems to generate working resources, that will link into both 32
and 64-bit code.
2) I traced my issues with not being able to call certain comdlg32
functions, to issues with structure packing. Commenting out the #pragma
pack(push,1) in commdlg.h fixed it, and now I have working code in 32-bit
and 64-bit. 32-bit seems to like 1-byte alignment, and 64-bit presumably
defaults to 8-byte alignment.
Thanks so much everyone that's worked on this!
Best Wishes,
Jonathan
Hi,
I've been able to successfully use windres to compile, then tcc 0.9.26 to
link resources into a 32-bit program.
However, I'm kinda stuck trying to get tcc to link to a 64-bit windres
generated resource file.
1) Check for magic not yet supporting x86-64
In file tccpe.c, the pe_load_res is looking for 32-bit magic
//if (hdr.filehdr.Machine != 0x014C
if (hdr.filehdr.Machine != 0x8664
|| hdr.filehdr.NumberOfSections != 1
|| strcmp(hdr.sectionhdr.Name, .rsrc) != 0) {
printf(Machine: %lx, hdr.filehdr.Machine);
goto quit;
}
2) Resource files appear to be slightly different between win32 and x86-64
The reltype shows up as 3 in my compiled 64-bit resource but tcc is
expecting 7.
lower in same function...
printf(rsrc_reloc: %x %x %x\n, rel.offset, rel.size, rel.type);
// debugging
if (rel.type != 7) /* DIR32NB */ {
printf(ERROR: rel.type != 7 Got: %d\n,rel.type); //
prints a 3 for 64-bit resources
goto quit;
}
Has anyone pushed a bit further and managed to get tcc linking to 64-bit
resources?
Best Wishes,
Jonathan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] broken tcc build after latest git pull
By the logic a native compiler on the windows must have a name 386-win-tcc.exe not i386-tcc. The i386-tcc.exe is supposed to be a compiler for the i386 Linux. A makefile target must be somehow modified. ifeq ($(ARCH),i386) PROGS:=$($(I386_CROSS)_LINK) $($(I386_CROSS)_LINK)_TCC = yes endif ifeq ($(ARCH),x86-64) PROGS:=$($(X64_CROSS)_LINK) $($(X64_CROSS)_LINK)_TCC = yes endif There is a targetos variable in the configure script which defines mingw32=yes. But we need a host_os variable in a configure and makefile. I will try to introduce this. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] broken tcc build after latest git pull
Hello list, The compiled tcc binary is not able to compile itself, after git pull today: tcc -o i386-tcc.exe tcc.c -DONE_SOURCE -DTCC_TARGET_I386 -I. -O2 tcc: error: file 'crt1.o' not found tcc: error: file 'crti.o' not found In file included from tcc.c:22: In file included from libtcc.c:21: In file included from tcc.h:41: d:/tinycc/win32/include/time.h:12: error: #error Only Win32 target is supported! make: *** [i386-tcc.exe] Error 1 Regards, Roy ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Is there a some communication policy?
Le mardi 27 janvier 2015, 14:34:09 Sergey Korshunoff a écrit : Looking a http://repo.or.cz/w/tinycc.git A commit Fix macro expansion of empty args has a too short description. This comment don't explain what was before a patch. I don't see a post or discussion about this patch. There was a patch for the same puspose in my set of the patches. And no discussion about my patch too. Why to post a patches if others don't comminicate? Ideally we would comment on all patch but we desperately lack of enough review bandwith for this. I still encourage people to post patch for review unless they have a long experience with tcc or compilers in general. 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] [TIPS?] array in struct initialization w/o '{', case3
I failed to resolve a problem. In any case there must be present a
special code for handling a cast's inside a struct initialization
code. Place array initialization in the {} brakets or use some of the
above described workarounds.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
