Re: [Tinycc-devel] test failures on win32 x86-64

2022-10-20 Thread avih via Tinycc-devel
 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

2022-10-20 Thread Michael Matz

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