Re: [Tinycc-devel] test failures on win32 x86-64
Hello, On Thu, 20 Oct 2022, avih wrote: > "dec %edi" truncates the %rdi register to 32bit by zero-extension, > so that ... this is now segfault. That only matters if the stack > (which %rdi points into) is setup such that it's beyond 32bit, > which ... is indeed the case on win10 for you. So, it's not > malloc() result, but it does have to do with address space layout. Thanks for pointing out the relation between my (somewhat off) addresses observation and the test failures. Are you able to shed some light on how some binaries (those compiled with msvc or new mingw gcc) exhibit ~44 bit addresses on Windows 10, but ~24 bits addresses on Windows 7? That's simply how the win10 runtime behaves a little different. stack and malloc memory ultimately all rely on memory pages gives out by the kernel to userspace (on unix that's mmap and on windows that's CreateFileMapping and friends), and the win10 kernel happens to give out pages residing beyond 4GB by default, while the win7 kernel does not (at least for you, in your cases; but I'm guessing that Microsoft is slowly but surely eliminating artifacts that still stem from compatibility considerations between win32 and win64: giving out pages below 4GB by default, even for 64bit processes, would be such compatibility hack) > The problem is that win64 is an IL32 platform, so that 'long' is not the > same size as a pointer, but the strncat1 implementation, coming from the > linux kernel, expects that to be the case. The below patch should fix it, > but I can't test on win64, so please check yourself and commit if it does. I think your patch will conflict with the fix on mob from few days ago: https://repo.or.cz/tinycc.git/commitdiff/bb80cbe0 Ah, I haven't checked mob before fiddling with this. However, do note that your patch replaces two instances of long with size_t, while bb80cbe0 replaces few more instances, so I'd imagine that's why the test was still failing with your patch (didn't check). Yup, as I said, I wasn't able to test for real ;-) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] test failures on win32 x86-64
On Wednesday, October 19, 2022, 03:36:59 PM GMT+3, Michael Matz wrote: > ... > "dec %edi" truncates the %rdi register to 32bit by zero-extension, > so that ... this is now segfault. That only matters if the stack > (which %rdi points into) is setup such that it's beyond 32bit, > which ... is indeed the case on win10 for you. So, it's not > malloc() result, but it does have to do with address space layout. Thanks for pointing out the relation between my (somewhat off) addresses observation and the test failures. Are you able to shed some light on how some binaries (those compiled with msvc or new mingw gcc) exhibit ~44 bit addresses on Windows 10, but ~24 bits addresses on Windows 7? > The problem is that win64 is an IL32 platform, so that 'long' is not the > same size as a pointer, but the strncat1 implementation, coming from the > linux kernel, expects that to be the case. The below patch should fix it, > but I can't test on win64, so please check yourself and commit if it does. I think your patch will conflict with the fix on mob from few days ago: https://repo.or.cz/tinycc.git/commitdiff/bb80cbe0 But I'd imagine it would have worked, as it replaces long with size_t, which is the same size (64 bits) as word which was set at bb80cbe0 . (I confirmed that sizeof void*/word/size_t at tcctest.c is 64 bits when compiled with either mingw gcc 64 or tcc win64, and long is 32). However, do note that your patch replaces two instances of long with size_t, while bb80cbe0 replaces few more instances, so I'd imagine that's why the test was still failing with your patch (didn't check). - avih ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] test failures on win32 x86-64
Hi,
On Wed, 19 Oct 2022, Domingo Alvarez Duarte wrote:
Looking through the code on "tests/tcctest.c" there is more places using
"[unsigned] long" that probably will need to be revised to use "[unsigned]
long long" or "size_t".
Nah, you can't just blindly grep for "long" and randomly replace stuff.
In most places it's correct. Sure, there's still a problem, so somebody
needs to at least run this through gdb, like last time.
Ciao,
Michael.
Probably in several other places see bellow for a search on my fork:
=
va_list.c
extern void *memcpy(void *dest, const void *src, unsigned long n);
[position 26:59]
ap->overflow_arg_area = (char*)((long long)(ap->overflow_arg_area +
align - 1) & -align); [position 59:42]
ap->overflow_arg_area = (char*)((long long)(ap->overflow_arg_area +
align - 1) & -align); [position 59:47]
va_list.c
extern void *memcpy(void *dest, const void *src, unsigned long n);
[position 26:59]
ap->overflow_arg_area = (char*)((long long)(ap->overflow_arg_area +
align - 1) & -align); [position 59:42]
ap->overflow_arg_area = (char*)((long long)(ap->overflow_arg_area +
align - 1) & -align); [position 59:47]
tcctest.c
enum ELong { [position 598:7]
EL_large = ((unsigned long)0xf000 << 31) << 1, [position 601:27]
i = ((long)p) >> 32; [position 927:11]
unsigned long flags; [position 1003:14]
unsigned long index; [position 1011:15]
unsigned long counters; [position 1015:15]
long u3; [position 1024:6]
long u4; [position 1025:6]
unsigned long compound_head; [position 1029:15]
} __attribute__((aligned(2 * sizeof(long; [position 1034:37]
unsigned long ul = 0x8000UL; [position 1585:14]
(long)p, (unsigned long)p, [position 1632:13]
(long)p, (unsigned long)p, [position 1632:31]
(long long)p, (unsigned long long)p); [position 1633:13]
(long long)p, (unsigned long long)p); [position 1633:18]
(long long)p, (unsigned long long)p); [position 1633:36]
(long long)p, (unsigned long long)p); [position 1633:41]
printf("0x%lx\n", (unsigned long)(int)ul); [position 1641:33]
long diff; [position 2353:5]
long __pa_symbol(void) [position 2848:1]
return ((long)(((unsigned long)())) -
(0x8000UL)); [position 2855:17]
return ((long)(((unsigned long)())) -
(0x8000UL)); [position 2855:34]
printf("cmpfn=%lx\n", (long)cmpfn); [position 2880:28]
printf("cmpfn=%lx\n", (long)cmpfn); [position 2886:28]
printf("sizeof(long) = %d\n", sizeof(long)); [position 3006:20]
printf("sizeof(long) = %d\n", sizeof(long)); [position 3006:42]
printf("sizeof(unsigned long) = %d\n", sizeof(unsigned long));
[position 3007:29]
printf("sizeof(unsigned long) = %d\n", sizeof(unsigned long));
[position 3007:60]
void consume_ulong (unsigned long i) [position 3078:15]
void consume_ulong (unsigned long i) [position 3078:30]
long pre = 48; [position 3131:5]
long post = 49; [position 3133:5]
printf ("stmtexpr: %ld %ld\n", (long)h.first, (long)h.last);
[position 3137:37]
printf ("stmtexpr: %ld %ld\n", (long)h.first, (long)h.last);
[position 3137:52]
consume_ulong(({ __label__ __here; __here: (unsigned long)&&__here;
})); [position 3140:14]
consume_ulong(({ __label__ __here; __here: (unsigned long)&&__here;
})); [position 3140:58]
:"0" (n/4), "q" (n),"1" ((long) to),"2" ((size_t) from) [position
3249:28]
:"0" (n/4), "q" (n),"1" ((long) to),"2" ((size_t) from) [position
3267:28]
unsigned long addr; [position 3336:14]
unsigned long mconstraint_test(struct struct1231 *r) [position 3339:10]
unsigned long ret; [position 3341:14]
unsigned long ret; [position 3363:14]
printf ("oc1: %d\n", ret == (unsigned long)); [position 3367:43]
"some_symbol: .long 0\n" [position 3415:18]
"2:\t.long 1b - 2b, %c0 - 2b\n" [position 3422:9]
".long 661b - .\n" /* This reference to 661 generates an external
sym*/ [position 3440:7]
register long val asm("r12"); [position 3484:14]
long val2; [position 3485:5]
long x1, x2; [position 3500:5]
static long cpu_number; [position 3511:8]
void trace_console(long len, long len2) [position 3512:20]
void trace_console(long len, long len2) [position 3512:30]
long pscr_ret__; [position 3531:15]
long pfo_ret__; [position 3535:24]
long pfo_ret__; [position 3544:24]
long rdi; [position 3566:3]
struct struct1231 s2 = { (unsigned long) }; [position 3668:40]
unsigned long asmret; [position 3673:14]
int force_get_order(unsigned long s) [position 4170:30]
elf.h
Re: [Tinycc-devel] test failures on win32 x86-64
Looking through the code on "tests/tcctest.c" there is more places using
"[unsigned] long" that probably will need to be revised to use
"[unsigned] long long" or "size_t".
Probably in several other places see bellow for a search on my fork:
=
va_list.c
extern void *memcpy(void *dest, const void *src, unsigned long n);
[position 26:59]
ap->overflow_arg_area = (char*)((long
long)(ap->overflow_arg_area + align - 1) & -align); [position 59:42]
ap->overflow_arg_area = (char*)((long
long)(ap->overflow_arg_area + align - 1) & -align); [position 59:47]
va_list.c
extern void *memcpy(void *dest, const void *src, unsigned long n);
[position 26:59]
ap->overflow_arg_area = (char*)((long
long)(ap->overflow_arg_area + align - 1) & -align); [position 59:42]
ap->overflow_arg_area = (char*)((long
long)(ap->overflow_arg_area + align - 1) & -align); [position 59:47]
tcctest.c
enum ELong { [position 598:7]
EL_large = ((unsigned long)0xf000 << 31) << 1, [position 601:27]
i = ((long)p) >> 32; [position 927:11]
unsigned long flags; [position 1003:14]
unsigned long index; [position 1011:15]
unsigned long counters; [position 1015:15]
long u3; [position 1024:6]
long u4; [position 1025:6]
unsigned long compound_head; [position 1029:15]
} __attribute__((aligned(2 * sizeof(long; [position 1034:37]
unsigned long ul = 0x8000UL; [position 1585:14]
(long)p, (unsigned long)p, [position 1632:13]
(long)p, (unsigned long)p, [position 1632:31]
(long long)p, (unsigned long long)p); [position 1633:13]
(long long)p, (unsigned long long)p); [position 1633:18]
(long long)p, (unsigned long long)p); [position 1633:36]
(long long)p, (unsigned long long)p); [position 1633:41]
printf("0x%lx\n", (unsigned long)(int)ul); [position 1641:33]
long diff; [position 2353:5]
long __pa_symbol(void) [position 2848:1]
return ((long)(((unsigned long)())) -
(0x8000UL)); [position 2855:17]
return ((long)(((unsigned long)())) -
(0x8000UL)); [position 2855:34]
printf("cmpfn=%lx\n", (long)cmpfn); [position 2880:28]
printf("cmpfn=%lx\n", (long)cmpfn); [position 2886:28]
printf("sizeof(long) = %d\n", sizeof(long)); [position 3006:20]
printf("sizeof(long) = %d\n", sizeof(long)); [position 3006:42]
printf("sizeof(unsigned long) = %d\n", sizeof(unsigned long));
[position 3007:29]
printf("sizeof(unsigned long) = %d\n", sizeof(unsigned long));
[position 3007:60]
void consume_ulong (unsigned long i) [position 3078:15]
void consume_ulong (unsigned long i) [position 3078:30]
long pre = 48; [position 3131:5]
long post = 49; [position 3133:5]
printf ("stmtexpr: %ld %ld\n", (long)h.first, (long)h.last);
[position 3137:37]
printf ("stmtexpr: %ld %ld\n", (long)h.first, (long)h.last);
[position 3137:52]
consume_ulong(({ __label__ __here; __here: (unsigned long)&&__here;
})); [position 3140:14]
consume_ulong(({ __label__ __here; __here: (unsigned long)&&__here;
})); [position 3140:58]
:"0" (n/4), "q" (n),"1" ((long) to),"2" ((size_t) from) [position
3249:28]
:"0" (n/4), "q" (n),"1" ((long) to),"2" ((size_t) from) [position
3267:28]
unsigned long addr; [position 3336:14]
unsigned long mconstraint_test(struct struct1231 *r) [position 3339:10]
unsigned long ret; [position 3341:14]
unsigned long ret; [position 3363:14]
printf ("oc1: %d\n", ret == (unsigned long)); [position 3367:43]
"some_symbol: .long 0\n" [position 3415:18]
"2:\t.long 1b - 2b, %c0 - 2b\n" [position 3422:9]
".long 661b - .\n" /* This reference to 661 generates an external
sym*/ [position 3440:7]
register long val asm("r12"); [position 3484:14]
long val2; [position 3485:5]
long x1, x2; [position 3500:5]
static long cpu_number; [position 3511:8]
void trace_console(long len, long len2) [position 3512:20]
void trace_console(long len, long len2) [position 3512:30]
long pscr_ret__; [position 3531:15]
long pfo_ret__; [position 3535:24]
long pfo_ret__; [position 3544:24]
long rdi; [position 3566:3]
struct struct1231 s2 = { (unsigned long) }; [position 3668:40]
unsigned long asmret; [position 3673:14]
int force_get_order(unsigned long s) [position 4170:30]
elf.h
libtcc.c
* License along with this library; if not, write to the Free
Software [position 17:13]
PUB_FUNC void *tcc_malloc_base(unsigned long size) [position 256:41]
PUB_FUNC void *tcc_mallocz_base(unsigned long size) [position 267:42]
PUB_FUNC void *tcc_malloc(TCCState
Re: [Tinycc-devel] test failures on win32 x86-64
Hello Michael !
Thank you for your great work !
I applied your changes to my fork but the tests continue to fail on
window see the result here
https://github.com/mingodad/tinycc/actions/runs/3282234645/jobs/5405354710 .
Cheers !
On 19/10/22 14:36, Michael Matz wrote:
Hello,
On Fri, 14 Oct 2022, avih via Tinycc-devel wrote:
0x7ff72b42b266 <+50>: repnz scas %es:(%rdi),%al
0x7ff72b42b268 <+52>: dec %edi
This is the problem. "dec %edi" truncates the %rdi register to 32bit
by zero-extension, so that ...
0x7ff72b42b26a <+54>: mov 0x30(%rbp),%ecx
0x7ff72b42b26d <+57>: dec %ecx
0x7ff72b42b26f <+59>: js 0x7ff72b42b277
0x7ff72b42b271 <+61>: lods %ds:(%rsi),%al
=> 0x7ff72b42b272 <+62>: stos %al,%es:(%rdi)
... this insn now segfault. That only matters if the stack (which
%rdi points into) is setup such that it's beyond 32bit, which ...
rdi 0xcb9ff955 3416258901
rbp 0x4ecb9ff8f0 0x4ecb9ff8f0
rsp 0x4ecb9ff8e0 0x4ecb9ff8e0
... is indeed the case on win10 for you. So, it's not malloc()
result, but it does have to do with address space layout.
The problem is that win64 is an IL32 platform, so that 'long' is not
the same size as a pointer, but the strncat1 implementation, coming
from the linux kernel, expects that to be the case. The below patch
should fix it, but I can't test on win64, so please check yourself and
commit if it does.
Ciao,
Michael.
--
diff --git a/tests/tcctest.c b/tests/tcctest.c
index f5bd9aab..1d625b0c 100644
--- a/tests/tcctest.c
+++ b/tests/tcctest.c
@@ -3254,7 +3254,7 @@ void local_label_test(void)
/* from linux kernel */
static char * strncat1(char * dest,const char * src,size_t count)
{
-long d0, d1, d2, d3;
+size_t d0, d1, d2, d3;
__asm__ __volatile__(
"repne\n\t"
"scasb\n\t"
@@ -3276,7 +3276,7 @@ return dest;
static char * strncat2(char * dest,const char * src,size_t count)
{
-long d0, d1, d2, d3;
+size_t d0, d1, d2, d3;
__asm__ __volatile__(
"repne scasb\n\t" /* one-line repne prefix + string op */
"dec %1\n\t"
___
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] test failures on win32 x86-64
Hello,
On Fri, 14 Oct 2022, avih via Tinycc-devel wrote:
0x7ff72b42b266 <+50>: repnz scas %es:(%rdi),%al
0x7ff72b42b268 <+52>: dec %edi
This is the problem. "dec %edi" truncates the %rdi register to 32bit by
zero-extension, so that ...
0x7ff72b42b26a <+54>: mov 0x30(%rbp),%ecx
0x7ff72b42b26d <+57>: dec %ecx
0x7ff72b42b26f <+59>: js 0x7ff72b42b277
0x7ff72b42b271 <+61>: lods %ds:(%rsi),%al
=> 0x7ff72b42b272 <+62>: stos %al,%es:(%rdi)
... this insn now segfault. That only matters if the stack (which %rdi
points into) is setup such that it's beyond 32bit, which ...
rdi 0xcb9ff955 3416258901
rbp 0x4ecb9ff8f0 0x4ecb9ff8f0
rsp 0x4ecb9ff8e0 0x4ecb9ff8e0
... is indeed the case on win10 for you. So, it's not malloc() result,
but it does have to do with address space layout.
The problem is that win64 is an IL32 platform, so that 'long' is not the
same size as a pointer, but the strncat1 implementation, coming from the
linux kernel, expects that to be the case. The below patch should fix it,
but I can't test on win64, so please check yourself and commit if it does.
Ciao,
Michael.
--
diff --git a/tests/tcctest.c b/tests/tcctest.c
index f5bd9aab..1d625b0c 100644
--- a/tests/tcctest.c
+++ b/tests/tcctest.c
@@ -3254,7 +3254,7 @@ void local_label_test(void)
/* from linux kernel */
static char * strncat1(char * dest,const char * src,size_t count)
{
-long d0, d1, d2, d3;
+size_t d0, d1, d2, d3;
__asm__ __volatile__(
"repne\n\t"
"scasb\n\t"
@@ -3276,7 +3276,7 @@ return dest;
static char * strncat2(char * dest,const char * src,size_t count)
{
-long d0, d1, d2, d3;
+size_t d0, d1, d2, d3;
__asm__ __volatile__(
"repne scasb\n\t" /* one-line repne prefix + string op */
"dec %1\n\t"
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] test failures on win32 x86-64
On Friday, October 14, 2022, 05:27:47 PM GMT+3, grischka wrote: >> and indeed, when tcc64 is compiled using tcc64 then on win10 >> s->sh_addr is ~22 bits, and all tests do pass _before_ d76e0323. > > Well, maybe behavior of malloc on Win10 has to do with the image-base > of the process. (see objdump -x file.exe/dll | grep ImageBase) To me this seems to suggest that the behavior depends on the specific binary, but the printouts on win7/10 were with the _same_ binaries. You can grab it from here https://0x0.st/ov4N.zip and examine for instance addr.gcc-12-2.exe which prints a ~22 bits address on win7 but ~44 bits address on my win10. > These can be set using -Wl,-image-base=0x..., for example > $ gcc tcctest.c -g -I.. -O0 -w -o tcctest.exe -Wl,-image-base=0x40 Again, it's an identical tcctest.gcc (at least as far as md5sum goes) which fails at strncat1 on win10 but succeeds on win7. > Ok, so it seems that it is tcctest.c compiled by gcc that crashes. > Which means this problem specifically hasn't to do anything with tcc. Yup, seems like it. > $ gdb tcctest.exe > > run > > bt > > disass > > info reg The printout below starts at the end of the "run" output. - avih [...] asm_test Thread 1 received signal SIGSEGV, Segmentation fault. 0x7ff72b42b272 in strncat1 () (gdb) disass Dump of assembler code for function strncat1: 0x7ff72b42b234 <+0>: push %rbp 0x7ff72b42b235 <+1>: push %rdi 0x7ff72b42b236 <+2>: push %rsi 0x7ff72b42b237 <+3>: sub $0x10,%rsp 0x7ff72b42b23b <+7>: lea 0x10(%rsp),%rbp 0x7ff72b42b240 <+12>: mov %rcx,0x20(%rbp) 0x7ff72b42b244 <+16>: mov %rdx,0x28(%rbp) 0x7ff72b42b248 <+20>: mov %r8,0x30(%rbp) 0x7ff72b42b24c <+24>: mov 0x28(%rbp),%r8 0x7ff72b42b250 <+28>: mov 0x20(%rbp),%r9 0x7ff72b42b254 <+32>: mov $0x0,%eax 0x7ff72b42b259 <+37>: mov $0x,%edx 0x7ff72b42b25e <+42>: mov %r8,%rsi 0x7ff72b42b261 <+45>: mov %r9,%rdi 0x7ff72b42b264 <+48>: mov %edx,%ecx 0x7ff72b42b266 <+50>: repnz scas %es:(%rdi),%al 0x7ff72b42b268 <+52>: dec %edi 0x7ff72b42b26a <+54>: mov 0x30(%rbp),%ecx 0x7ff72b42b26d <+57>: dec %ecx 0x7ff72b42b26f <+59>: js 0x7ff72b42b277 0x7ff72b42b271 <+61>: lods %ds:(%rsi),%al => 0x7ff72b42b272 <+62>: stos %al,%es:(%rdi) 0x7ff72b42b273 <+63>: test %al,%al 0x7ff72b42b275 <+65>: jne 0x7ff72b42b26d 0x7ff72b42b277 <+67>: xor %eax,%eax 0x7ff72b42b279 <+69>: stos %al,%es:(%rdi) 0x7ff72b42b27a <+70>: mov %ecx,%edx 0x7ff72b42b27c <+72>: mov %edi,%r8d 0x7ff72b42b27f <+75>: mov %esi,%r9d 0x7ff72b42b282 <+78>: mov %r9d,-0x4(%rbp) 0x7ff72b42b286 <+82>: mov %r8d,-0x8(%rbp) 0x7ff72b42b28a <+86>: mov %eax,-0xc(%rbp) 0x7ff72b42b28d <+89>: mov %edx,-0x10(%rbp) 0x7ff72b42b290 <+92>: mov 0x20(%rbp),%rax 0x7ff72b42b294 <+96>: add $0x10,%rsp 0x7ff72b42b298 <+100>: pop %rsi 0x7ff72b42b299 <+101>: pop %rdi 0x7ff72b42b29a <+102>: pop %rbp 0x7ff72b42b29b <+103>: ret End of assembler dump. (gdb) info reg rax 0x20 32 rbx 0x1 1 rcx 0x2 2 rdx 0x 4294967295 rsi 0x7ff72b431fdd 140699559469021 rdi 0xcb9ff955 3416258901 rbp 0x4ecb9ff8f0 0x4ecb9ff8f0 rsp 0x4ecb9ff8e0 0x4ecb9ff8e0 r8 0x7ff72b431fdc 140699559469020 r9 0x4ecb9ff950 338423707984 r10 0x0 0 r11 0x246 582 r12 0x1 1 r13 0x169230214a0 1551070532768 r14 0x16923021440 1551070532672 r15 0x0 0 rip 0x7ff72b42b272 0x7ff72b42b272 eflags 0x10202 [ IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x53 83 gs 0x2b 43 (gdb) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] test failures on win32 x86-64
On 14.10.2022 11:24, avih via Tinycc-devel wrote: So somehow, on win7 the address from malloc is always ~22 bits, while on win10 msvc and new mingw gcc procude ~43 bits address, while with tcc and old gcc malloc returns ~22 bits addresses. and indeed, when tcc64 is compiled using tcc64 then on win10 s->sh_addr is ~22 bits, and all tests do pass _before_ d76e0323. Well, maybe behavior of malloc on Win10 has to do with the image-base of the process. (see objdump -x file.exe/dll | grep ImageBase) The new gcc seems to set dll: ImageBase 0003.20e9 exe: ImageBase 0001.4000 whereas the old defaults (as used by tcc) were (both win32/64) dll: ImageBase .1000 exe: ImageBase .0040 These can be set using -Wl,-image-base=0x..., for example $ gcc tcctest.c -g -I.. -O0 -w -o tcctest.exe -Wl,-image-base=0x40 or $ tcc tcctest.c -g -I.. -O0 -w -o tcctest.exe -Wl,-image-base=0x32000 On win10 with gcc 12.2, the output ends with this: ./tcctest.gcc > test.ref make: *** [Makefile:110: test.ref] Error -1073741819 make: Leaving directory 'D:/tmp/tcc2/tests' and the last line at test.ref is " asm_test -" Ok, so it seems that it is tcctest.c compiled by gcc that crashes. Which means this problem specifically hasn't to do anything with tcc. Then, at tcctest.c, I commented out /* RUN(asm_test); */ and the test passes. I tried to find which line crashes at asm_test, and it's: strncat1(buf, " worldX", 3); (adding exit(42) just before it exits with code 42, but exit(42) after it is not reached). No idea why the strncat1() asm stuff now suddenly should fail, regardless whether with addresses hi or lo. Of course, most likely there is some reason ;) Some useful command if you happen to want find out: $ gdb tcctest.exe > run > bt > disass > info reg --- grischka I then tried also make -C tests clean make -C tests test3 and it's the same end of output as with test1, and same diagnostics (pass if commenting out RUN(asm_test), else crash at strncat1(buf, " worldX", 3)). - avih ___ 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] test failures on win32 x86-64
It seems that something changed on windows itself because my fork was
passing the tests before and now without any substantial change is
failing see here https://github.com/mingodad/tinycc/actions , and I also
tested on Windows7 32 bits and all tests pass.
On 14/10/22 11:24, avih via Tinycc-devel wrote:
In reply to the second half of:
https://lists.nongnu.org/archive/html/tinycc-devel/2022-10/msg00021.html
> As to spurious problems with MSYS2 I can only say that in my experience
> it is not a completely reliable build system.
>
> As a derivative from cygwin it shares the same fork() emulation hack,
> and I've seen it sub-processes just silently terminating (or maybe not
> even start them) with no failure code whatsoever.
>
> That would not affect the built tcc itself however it could affect the
> 'diff' used by the tests for example.
I think I removed the cygwin/fork/diff variables as follows:
I'm using this, which is a reproducible mingw env without cygwin:
https://github.com/skeeto/w64devkit/releases/tag/v1.16.1
building tcc (simply configure && make) within this environment
is producing identical tcc.exe, libtcc.dll, libtcc1.a on both my
Windows 10 system (32G ram) and my Windows 7 system (16G ram).
"make test" succeeds on win7 but fails on win10.
_Before_ commit d76e0323 (win64: hi-mem adjustments) test 104
failed also when invoked manually as:
cd tests/tests2 && path/to/inttalled/tcc 104+_inline.c -run 104_inline.c
where on win7 it printed things and exited successfully, while on
win10 it printed "tcc: error: internal error: relocation failed".
So it's also not an issue of diff not running correctly.
I took the liberty to print the value which fails ("diff") and its
origin (s->sh_addr at relocate_section), and noticed that on win10
it's 41-44 bits values, while on win7 it's 22-24 bits values.
I guessed that this might be an address from malloc, and checked
which values malloc returns using this program (source link below):
int msb(unsigned long long v) {
for (int i = 0;; ++i, v /= 2)
if (!v) return i;
}
int main(int argc, char **argv) {
unsigned long long a = (uintptr_t)malloc(1024);
printf("%s %d [%d]: malloc: %llu (%d/%d bits)\n",
cc, ccver, ccbits, a, msb(a), 8 * (int)sizeof(void*));
return 0;
}
I compiled this program using tcc (64) itself, as well as using
mingw gcc 5.5 (64), mingw gcc 12.2 (64), and msvc 2015 (64).
Source + binaries are available here https://0x0.st/ov4N.zip
On win7 these programs print results like this:
gcc 12 [64]: malloc: 1464336 (21/64 bits)
gcc 5 [64]: malloc: 8476688 (24/64 bits)
msvc 1900 [64]: malloc: 2635264 (22/64 bits)
tcc 927 [64]: malloc: 2185120 (22/64 bits)
While on win10 the same binaries print resuts like this:
gcc 12 [64]: malloc: 2620625130432 (42/64 bits)
gcc 5 [64]: malloc: 12260288 (24/64 bits)
msvc 1900 [64]: malloc: 1504834189600 (41/64 bits)
tcc 927 [64]: malloc: 8590208 (24/64 bits)
So somehow, on win7 the address from malloc is always ~22 bits,
while on win10 msvc and new mingw gcc procude ~43 bits address,
while with tcc and old gcc malloc returns ~22 bits addresses.
and indeed, when tcc64 is compiled using tcc64 then on win10
s->sh_addr is ~22 bits, and all tests do pass _before_ d76e0323.
--
On Thursday, October 13, 2022, 10:16:45 PM GMT+3, grischka
wrote:
>> from tests/tests2/:
>> - 104_inline.test
>
> This might be fixed on mob.
Confirmed, 104 now passes on win10 with gcc 12.2 (at d76e032).
> You can see the command when you call the test directly:
>
> make -C tests clean
> make -C tests test1
On win10 with gcc 12.2, the output ends with this:
./tcctest.gcc > test.ref
make: *** [Makefile:110: test.ref] Error -1073741819
make: Leaving directory 'D:/tmp/tcc2/tests'
and the last line at test.ref is " asm_test -"
Then, at tcctest.c, I commented out /* RUN(asm_test); */
and the test passes.
I tried to find which line crashes at asm_test, and it's:
strncat1(buf, " worldX", 3);
(adding exit(42) just before it exits with code 42, but exit(42)
after it is not reached).
I then tried also
make -C tests clean
make -C tests test3
and it's the same end of output as with test1, and same
diagnostics (pass if commenting out RUN(asm_test), else
crash at strncat1(buf, " worldX", 3)).
- avih
___
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] test failures on win32 x86-64
The github action is already working and the windows tests failed see
then here https://github.com/TinyCC/tinycc/actions/runs/3249532722 .
On 14/10/22 11:24, avih via Tinycc-devel wrote:
In reply to the second half of:
https://lists.nongnu.org/archive/html/tinycc-devel/2022-10/msg00021.html
> As to spurious problems with MSYS2 I can only say that in my experience
> it is not a completely reliable build system.
>
> As a derivative from cygwin it shares the same fork() emulation hack,
> and I've seen it sub-processes just silently terminating (or maybe not
> even start them) with no failure code whatsoever.
>
> That would not affect the built tcc itself however it could affect the
> 'diff' used by the tests for example.
I think I removed the cygwin/fork/diff variables as follows:
I'm using this, which is a reproducible mingw env without cygwin:
https://github.com/skeeto/w64devkit/releases/tag/v1.16.1
building tcc (simply configure && make) within this environment
is producing identical tcc.exe, libtcc.dll, libtcc1.a on both my
Windows 10 system (32G ram) and my Windows 7 system (16G ram).
"make test" succeeds on win7 but fails on win10.
_Before_ commit d76e0323 (win64: hi-mem adjustments) test 104
failed also when invoked manually as:
cd tests/tests2 && path/to/inttalled/tcc 104+_inline.c -run 104_inline.c
where on win7 it printed things and exited successfully, while on
win10 it printed "tcc: error: internal error: relocation failed".
So it's also not an issue of diff not running correctly.
I took the liberty to print the value which fails ("diff") and its
origin (s->sh_addr at relocate_section), and noticed that on win10
it's 41-44 bits values, while on win7 it's 22-24 bits values.
I guessed that this might be an address from malloc, and checked
which values malloc returns using this program (source link below):
int msb(unsigned long long v) {
for (int i = 0;; ++i, v /= 2)
if (!v) return i;
}
int main(int argc, char **argv) {
unsigned long long a = (uintptr_t)malloc(1024);
printf("%s %d [%d]: malloc: %llu (%d/%d bits)\n",
cc, ccver, ccbits, a, msb(a), 8 * (int)sizeof(void*));
return 0;
}
I compiled this program using tcc (64) itself, as well as using
mingw gcc 5.5 (64), mingw gcc 12.2 (64), and msvc 2015 (64).
Source + binaries are available here https://0x0.st/ov4N.zip
On win7 these programs print results like this:
gcc 12 [64]: malloc: 1464336 (21/64 bits)
gcc 5 [64]: malloc: 8476688 (24/64 bits)
msvc 1900 [64]: malloc: 2635264 (22/64 bits)
tcc 927 [64]: malloc: 2185120 (22/64 bits)
While on win10 the same binaries print resuts like this:
gcc 12 [64]: malloc: 2620625130432 (42/64 bits)
gcc 5 [64]: malloc: 12260288 (24/64 bits)
msvc 1900 [64]: malloc: 1504834189600 (41/64 bits)
tcc 927 [64]: malloc: 8590208 (24/64 bits)
So somehow, on win7 the address from malloc is always ~22 bits,
while on win10 msvc and new mingw gcc procude ~43 bits address,
while with tcc and old gcc malloc returns ~22 bits addresses.
and indeed, when tcc64 is compiled using tcc64 then on win10
s->sh_addr is ~22 bits, and all tests do pass _before_ d76e0323.
--
On Thursday, October 13, 2022, 10:16:45 PM GMT+3, grischka
wrote:
>> from tests/tests2/:
>> - 104_inline.test
>
> This might be fixed on mob.
Confirmed, 104 now passes on win10 with gcc 12.2 (at d76e032).
> You can see the command when you call the test directly:
>
> make -C tests clean
> make -C tests test1
On win10 with gcc 12.2, the output ends with this:
./tcctest.gcc > test.ref
make: *** [Makefile:110: test.ref] Error -1073741819
make: Leaving directory 'D:/tmp/tcc2/tests'
and the last line at test.ref is " asm_test -"
Then, at tcctest.c, I commented out /* RUN(asm_test); */
and the test passes.
I tried to find which line crashes at asm_test, and it's:
strncat1(buf, " worldX", 3);
(adding exit(42) just before it exits with code 42, but exit(42)
after it is not reached).
I then tried also
make -C tests clean
make -C tests test3
and it's the same end of output as with test1, and same
diagnostics (pass if commenting out RUN(asm_test), else
crash at strncat1(buf, " worldX", 3)).
- avih
___
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] test failures on win32 x86-64
Thank you ! I just accepted it and I'm waiting for an answer here https://github.com/repo-sync/github-sync/issues/104 to add something like I did here https://github.com/mingodad/tinycc/actions/runs/1638429826/workflow . On 14/10/22 11:12, Vlad Vissoultchev wrote: Just sent you an invitation from https://github.com/orgs/TinyCC org. In mob development fashion every member of the org has owner rights and can invite other people to configure CI for instance or anything needed. cheers, -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+wqweto=gmail@nongnu.org] On Behalf Of Domingo Alvarez Duarte Sent: Friday, October 14, 2022 10:54 AM To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] test failures on win32 x86-64 I noticed that there is a github mirror of tinycc repository, maybe it's a good idea to set a github action there that builds and test it on windows, mac and linux on every commit. On 13/10/22 20:59, grischka wrote: On 08.10.2022 22:39, avih via Tinycc-devel wrote: Hi, The following tests fail for me currently (0fd7376 gnu hash) when building tcc for win32 x86-64 (but pass when building i386) from tests/: - test3 - test1b Basically we would need to know first what part of the test fails at all. Is it tcc compiling itself, or the compiled tcc compiling tcctest, or is it tcctest running, or even is it maybe gcc that crashes? You can see the command when you call the test directly: make -C tests clean make -C tests test1 from tests/tests2/: - 104_inline.test This might be fixed on mob. --- grischka I sampled several revisions since release_0_9_27, and all of them fail somehow, mostly in tests (one revision also failed to build). This could be related to the mingw gcc I'm testing with - gcc 11.3.0 using mingw64 in MSYS2. I _think_ the x86-64 win32 tests did pass in thepast, so if someone could confirm the failures it may help. I tested as follows on Windows 10: - launch the mingw64 MSYS2 desktop shortcut - cd path/to/tinycc - git clean -xfd - ./configure --cpu=x86_64 --config-mingw32 && make && make test regards, avih ___ 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 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] test failures on win32 x86-64
In reply to the second half of:
https://lists.nongnu.org/archive/html/tinycc-devel/2022-10/msg00021.html
> As to spurious problems with MSYS2 I can only say that in my experience
> it is not a completely reliable build system.
>
> As a derivative from cygwin it shares the same fork() emulation hack,
> and I've seen it sub-processes just silently terminating (or maybe not
> even start them) with no failure code whatsoever.
>
> That would not affect the built tcc itself however it could affect the
> 'diff' used by the tests for example.
I think I removed the cygwin/fork/diff variables as follows:
I'm using this, which is a reproducible mingw env without cygwin:
https://github.com/skeeto/w64devkit/releases/tag/v1.16.1
building tcc (simply configure && make) within this environment
is producing identical tcc.exe, libtcc.dll, libtcc1.a on both my
Windows 10 system (32G ram) and my Windows 7 system (16G ram).
"make test" succeeds on win7 but fails on win10.
_Before_ commit d76e0323 (win64: hi-mem adjustments) test 104
failed also when invoked manually as:
cd tests/tests2 && path/to/inttalled/tcc 104+_inline.c -run 104_inline.c
where on win7 it printed things and exited successfully, while on
win10 it printed "tcc: error: internal error: relocation failed".
So it's also not an issue of diff not running correctly.
I took the liberty to print the value which fails ("diff") and its
origin (s->sh_addr at relocate_section), and noticed that on win10
it's 41-44 bits values, while on win7 it's 22-24 bits values.
I guessed that this might be an address from malloc, and checked
which values malloc returns using this program (source link below):
int msb(unsigned long long v) {
for (int i = 0;; ++i, v /= 2)
if (!v) return i;
}
int main(int argc, char **argv) {
unsigned long long a = (uintptr_t)malloc(1024);
printf("%s %d [%d]: malloc: %llu (%d/%d bits)\n",
cc, ccver, ccbits, a, msb(a), 8 * (int)sizeof(void*));
return 0;
}
I compiled this program using tcc (64) itself, as well as using
mingw gcc 5.5 (64), mingw gcc 12.2 (64), and msvc 2015 (64).
Source + binaries are available here https://0x0.st/ov4N.zip
On win7 these programs print results like this:
gcc 12 [64]: malloc: 1464336 (21/64 bits)
gcc 5 [64]: malloc: 8476688 (24/64 bits)
msvc 1900 [64]: malloc: 2635264 (22/64 bits)
tcc 927 [64]: malloc: 2185120 (22/64 bits)
While on win10 the same binaries print resuts like this:
gcc 12 [64]: malloc: 2620625130432 (42/64 bits)
gcc 5 [64]: malloc: 12260288 (24/64 bits)
msvc 1900 [64]: malloc: 1504834189600 (41/64 bits)
tcc 927 [64]: malloc: 8590208 (24/64 bits)
So somehow, on win7 the address from malloc is always ~22 bits,
while on win10 msvc and new mingw gcc procude ~43 bits address,
while with tcc and old gcc malloc returns ~22 bits addresses.
and indeed, when tcc64 is compiled using tcc64 then on win10
s->sh_addr is ~22 bits, and all tests do pass _before_ d76e0323.
--
On Thursday, October 13, 2022, 10:16:45 PM GMT+3, grischka
wrote:
>> from tests/tests2/:
>> - 104_inline.test
>
> This might be fixed on mob.
Confirmed, 104 now passes on win10 with gcc 12.2 (at d76e032).
> You can see the command when you call the test directly:
>
> make -C tests clean
> make -C tests test1
On win10 with gcc 12.2, the output ends with this:
./tcctest.gcc > test.ref
make: *** [Makefile:110: test.ref] Error -1073741819
make: Leaving directory 'D:/tmp/tcc2/tests'
and the last line at test.ref is " asm_test -"
Then, at tcctest.c, I commented out /* RUN(asm_test); */
and the test passes.
I tried to find which line crashes at asm_test, and it's:
strncat1(buf, " worldX", 3);
(adding exit(42) just before it exits with code 42, but exit(42)
after it is not reached).
I then tried also
make -C tests clean
make -C tests test3
and it's the same end of output as with test1, and same
diagnostics (pass if commenting out RUN(asm_test), else
crash at strncat1(buf, " worldX", 3)).
- avih ___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] test failures on win32 x86-64
Just sent you an invitation from https://github.com/orgs/TinyCC org. In mob development fashion every member of the org has owner rights and can invite other people to configure CI for instance or anything needed. cheers, -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+wqweto=gmail@nongnu.org] On Behalf Of Domingo Alvarez Duarte Sent: Friday, October 14, 2022 10:54 AM To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] test failures on win32 x86-64 I noticed that there is a github mirror of tinycc repository, maybe it's a good idea to set a github action there that builds and test it on windows, mac and linux on every commit. On 13/10/22 20:59, grischka wrote: > On 08.10.2022 22:39, avih via Tinycc-devel wrote: >> Hi, >> >> The following tests fail for me currently (0fd7376 gnu hash) when >> building tcc for win32 x86-64 (but pass when building i386) >> >> from tests/: >> - test3 >> - test1b > > Basically we would need to know first what part of the test fails at > all. Is it tcc compiling itself, or the compiled tcc compiling > tcctest, or is it tcctest running, or even is it maybe gcc that > crashes? > > You can see the command when you call the test directly: > >make -C tests clean >make -C tests test1 > >> from tests/tests2/: >> - 104_inline.test > > This might be fixed on mob. > > --- grischka > >> >> I sampled several revisions since release_0_9_27, and all of them >> fail somehow, mostly in tests (one revision also failed to build). >> >> This could be related to the mingw gcc I'm testing with - gcc 11.3.0 >> using mingw64 in MSYS2. I _think_ the x86-64 win32 tests did pass in >> thepast, so if someone could confirm the failures it may help. >> >> I tested as follows on Windows 10: >> - launch the mingw64 MSYS2 desktop shortcut >> - cd path/to/tinycc >> - git clean -xfd >> - ./configure --cpu=x86_64 --config-mingw32 && make && make test >> >> >> regards, >> avih >> >> ___ >> 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 mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] test failures on win32 x86-64
At 2022-10-14 15:53:56, "Domingo Alvarez Duarte" wrote: >I noticed that there is a github mirror of tinycc repository, maybe it's >a good idea to set a github action there that builds and test it on >windows, mac and linux on every commit. Maybe it is not a good idea. It seems to be synced manually, so the repository is not always up to date. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] test failures on win32 x86-64
I noticed that there is a github mirror of tinycc repository, maybe it's a good idea to set a github action there that builds and test it on windows, mac and linux on every commit. On 13/10/22 20:59, grischka wrote: On 08.10.2022 22:39, avih via Tinycc-devel wrote: Hi, The following tests fail for me currently (0fd7376 gnu hash) when building tcc for win32 x86-64 (but pass when building i386) from tests/: - test3 - test1b Basically we would need to know first what part of the test fails at all. Is it tcc compiling itself, or the compiled tcc compiling tcctest, or is it tcctest running, or even is it maybe gcc that crashes? You can see the command when you call the test directly: make -C tests clean make -C tests test1 from tests/tests2/: - 104_inline.test This might be fixed on mob. --- grischka I sampled several revisions since release_0_9_27, and all of them fail somehow, mostly in tests (one revision also failed to build). This could be related to the mingw gcc I'm testing with - gcc 11.3.0 using mingw64 in MSYS2. I _think_ the x86-64 win32 tests did pass in thepast, so if someone could confirm the failures it may help. I tested as follows on Windows 10: - launch the mingw64 MSYS2 desktop shortcut - cd path/to/tinycc - git clean -xfd - ./configure --cpu=x86_64 --config-mingw32 && make && make test regards, avih ___ 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] test failures on win32 x86-64
On 08.10.2022 22:39, avih via Tinycc-devel wrote: Hi, The following tests fail for me currently (0fd7376 gnu hash) when building tcc for win32 x86-64 (but pass when building i386) from tests/: - test3 - test1b Basically we would need to know first what part of the test fails at all. Is it tcc compiling itself, or the compiled tcc compiling tcctest, or is it tcctest running, or even is it maybe gcc that crashes? You can see the command when you call the test directly: make -C tests clean make -C tests test1 from tests/tests2/: - 104_inline.test This might be fixed on mob. --- grischka I sampled several revisions since release_0_9_27, and all of them fail somehow, mostly in tests (one revision also failed to build). This could be related to the mingw gcc I'm testing with - gcc 11.3.0 using mingw64 in MSYS2. I _think_ the x86-64 win32 tests did pass in thepast, so if someone could confirm the failures it may help. I tested as follows on Windows 10: - launch the mingw64 MSYS2 desktop shortcut - cd path/to/tinycc - git clean -xfd - ./configure --cpu=x86_64 --config-mingw32 && make && make test regards, avih ___ 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
