Hi Bart or anyone else who might know.

(note that I haven't read other threads yet as I am busy with this)

I made this change to get around a problem when
using cc64 but I don't know what is at fault:

C:\devel\pdos\pdpclib>git show 0d02ad6a8ac164f280f72a64077f5a7aa5d46386
commit 0d02ad6a8ac164f280f72a64077f5a7aa5d46386 (HEAD -> master, origin/master, origin/HEAD)
Author: Paul Edwards <mutazilah@gmail.com>
Date: Sat Sep 9 16:52:51 2023 +0800

handle negative floating point numbers for cc64 at least

diff --git a/pdpclib/stdio.c b/pdpclib/stdio.c
index f6479f9d..831fcebb 100644
--- a/pdpclib/stdio.c
+++ b/pdpclib/stdio.c
@@ -6792,7 +6792,13 @@ static void dblcvt(double num, int cnvtype, int nwidth,

if ( num < 0 )
{
- b = -num;
+ /* When using cc64, this line caused a crash */
+ /* I'm not sure if you can take a negative of a negative
+ number to make it positive, but regardless, I just did
+ a multiplication of -1.0 instead. I don't know if this
+ is applicable to other compilers. */
+ /* b = -num; */
+ b = num * -1.0;
sign = '-';
}
else

C:\devel\pdos\pdpclib>

A simple test case didn't reproduce the problem.

C:\devel\pdos\pdpclib>git diff pdptest.c
diff --git a/pdpclib/pdptest.c b/pdpclib/pdptest.c
index b877649e..1e2461c3 100644
--- a/pdpclib/pdptest.c
+++ b/pdpclib/pdptest.c
@@ -17,8 +17,11 @@

static char buf[6144]; /* arbitrary buffer size */

+double ddd = -1.0;
+ int main(int argc, char **argv)
{
+ double b;
FILE *fp;
FILE *fq;
char *in_name;
@@ -37,6 +40,11 @@ int main(int argc, char **argv)
#endif

printf("welcome to pdptest\n");
+ if (ddd < 0)
+ {
+ ddd = -ddd;
+ }
+ printf("done\n");
#ifndef SEGHACK

#if defined(__SUBC__) && defined(__64BIT__)

C:\devel\pdos\pdpclib>

Original issue made into more of a (complex) testcase is:

C:\devel\pdos\pdpclib>git diff stdio.c
diff --git a/pdpclib/stdio.c b/pdpclib/stdio.c
index 831fcebb..01c73ec5 100644
--- a/pdpclib/stdio.c
+++ b/pdpclib/stdio.c
@@ -292,7 +292,7 @@ __PDPCLIB_API__ __DUMMYFILE *__iob_func(void)
#endif
#endif

-static void dblcvt(double num, int cnvtype, int nwidth,
+void dblcvt(double num, int cnvtype, int nwidth,
int nprecision, char *result);
static int vvprintf(const char *format, va_list arg, FILE *fq, char *s);
static int vvscanf(const char *format, va_list arg, FILE *fp, const char *s);
@@ -6781,7 +6781,7 @@ static char *int_strtok(char *s1, const char *s2)

*/

-static void dblcvt(double num, int cnvtype, int nwidth,
+void dblcvt(double num, int cnvtype, int nwidth,
int nprecision, char *result)
{
double b,round;
@@ -6798,6 +6798,7 @@ static void dblcvt(double num, int cnvtype, int nwidth,
a multiplication of -1.0 instead. I don't know if this
is applicable to other compilers. */
/* b = -num; */
+ printf("got a negative\n");
b = num * -1.0;
sign = '-';
}
@@ -7121,5 +7122,13 @@ static void dblcvt(double num, int cnvtype, int nwidth,
pdigits--;
}
strcat(result,work);
+ printf("result is %s\n", result);
+ if ( num < 0 )
+ {
+ b = -num;
+ printf("done negation\n");
+ printf("done negation\n");
+ printf("done negation\n");
+ }
return;
}

C:\devel\pdos\pdpclib>

C:\devel\pdos\pdpclib>objdump -d stdio.obj >temp.txt

0000000000002410 <dblcvt>:
2410: 55 push %rbp
2411: 48 8b ec mov %rsp,%rbp
2414: 48 81 ec d0 00 00 00 sub $0xd0,%rsp
241b: 66 0f d6 45 10 movq %xmm0,0x10(%rbp)
2420: 48 89 55 18 mov %rdx,0x18(%rbp)
2424: 4c 89 45 20 mov %r8,0x20(%rbp)
2428: 4c 89 4d 28 mov %r9,0x28(%rbp)
242c: f3 0f 7e 45 10 movq 0x10(%rbp),%xmm0
2431: 66 0f 2f 04 25 e8 03 comisd 0x3e8,%xmm0
2438: 00 00
243a: 0f 83 33 00 00 00 jae 2473 <dblcvt+0x63>
2440: 48 83 ec 20 sub $0x20,%rsp
2444: 48 b9 41 03 00 00 00 movabs $0x341,%rcx
244b: 00 00 00
244e: e8 0d dc ff ff call 60 <printf>
2453: 48 83 c4 20 add $0x20,%rsp
2457: f3 0f 7e 45 10 movq 0x10(%rbp),%xmm0
245c: f2 0f 59 04 25 f0 03 mulsd 0x3f0,%xmm0
2463: 00 00
2465: 66 0f d6 45 f8 movq %xmm0,-0x8(%rbp)
246a: c6 45 c0 2d movb $0x2d,-0x40(%rbp)
246e: e9 0c 00 00 00 jmp 247f <dblcvt+0x6f>
2473: 48 8b 45 10 mov 0x10(%rbp),%rax
2477: 48 89 45 f8 mov %rax,-0x8(%rbp)
247b: c6 45 c0 20 movb $0x20,-0x40(%rbp)
247f: c7 45 d8 00 00 00 00 movl $0x0,-0x28(%rbp)
2486: f3 0f 7e 45 f8 movq -0x8(%rbp),%xmm0
248b: 66 0f 2f 04 25 f8 03 comisd 0x3f8,%xmm0
2492: 00 00

....

2db7: 48 b9 59 03 00 00 00 movabs $0x359,%rcx
2dbe: 00 00 00
2dc1: 48 8b 55 30 mov 0x30(%rbp),%rdx
2dc5: e8 96 d2 ff ff call 60 <printf>
2dca: 48 83 c4 20 add $0x20,%rsp
2dce: f3 0f 7e 45 10 movq 0x10(%rbp),%xmm0
2dd3: 66 0f 2f 04 25 b0 04 comisd 0x4b0,%xmm0
2dda: 00 00
2ddc: 0f 83 58 00 00 00 jae 2e3a <l289+0x6e0>
2de2: f3 0f 7e 45 10 movq 0x10(%rbp),%xmm0
2de7: 66 0f 57 04 25 e0 02 xorpd 0x2e0,%xmm0
2dee: 00 00
2df0: 66 0f d6 45 f8 movq %xmm0,-0x8(%rbp)
2df5: 48 83 ec 20 sub $0x20,%rsp
2df9: 48 b9 67 03 00 00 00 movabs $0x367,%rcx
2e00: 00 00 00
2e03: e8 58 d2 ff ff call 60 <printf>
2e08: 48 83 c4 20 add $0x20,%rsp
2e0c: 48 83 ec 20 sub $0x20,%rsp
2e10: 48 b9 76 03 00 00 00 movabs $0x376,%rcx
2e17: 00 00 00
2e1a: e8 41 d2 ff ff call 60 <printf>
2e1f: 48 83 c4 20 add $0x20,%rsp
2e23: 48 83 ec 20 sub $0x20,%rsp
2e27: 48 b9 85 03 00 00 00 movabs $0x385,%rcx
2e2e: 00 00 00
2e31: e8 2a d2 ff ff call 60 <printf>
2e36: 48 83 c4 20 add $0x20,%rsp
2e3a: 48 81 c4 d0 00 00 00 add $0xd0,%rsp
2e41: 5d pop %rbp
2e42: c3 ret
2e43: 48 81 c4 d0 00 00 00 add $0xd0,%rsp
2e4a: 5d pop %rbp
2e4b: c3 ret
2e4c: 90 nop
2e4d: 90 nop
2e4e: 90 nop
2e4f: 90 nop

The only instructions I can see that could be causing an
issue are:

2de7: 66 0f 57 04 25 e0 02 xorpd 0x2e0,%xmm0
2dee: 00 00
2df0: 66 0f d6 45 f8 movq %xmm0,-0x8(%rbp)

Note that the three identical printfs are an eyecatcher.

And here's what I get at runtime:

C:\devel\pdos\cc64>doit2

C:\devel\pdos\cc64>del cc64.exe

C:\devel\pdos\cc64>pdmake -f makefile.c64
pdcc -E -DBLDGENERIC -D__WIN32__ -D__STATIC__ -D__64BIT__ -DNOUNDMAIN -I . -I ../pdpclib -o cc64.i cc64.c
cc64 -c -out:cc64.obj cc64.i
Compiling cc64.i to cc64.obj
rm -f cc64.i
pdcc -E -DBLDGENERIC -D__WIN32__ -D__STATIC__ -D__64BIT__ -DNOUNDMAIN -I . -I ../pdpclib -o junk.i junk.c
cc64 -c -out:junk.obj junk.i
Compiling junk.i to junk.obj
rm -f junk.i
pdld -s -nostdlib --no-insert-timestamp --image-base 0x400000 -o cc64.exe ../pdpclib/p32start.obj cc64.obj junk.obj ../pdpclib/pdpwin64.lib ../src/kernel32.lib
cc64 -c -out:stdlib.obj stdlib.i
Compiling stdlib.i to stdlib.obj
result is 0
result is 1
result is 1
result is 0
result is 1
got a negative
result is -1
[cc64.exe] Error -1073741819: Unknown error

C:\devel\pdos\cc64>

Full code is here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/stdio.c

Is this the correct generated code to convert a negative
floating point number into a positive?

Another possibility is a wild pointer that is sensitive to the
number of bytes of code being generated, so switching to
a multiply masks some other problem.

Thanks. Paul.

I realized the stack variable wasn't aligned on a 16-byte
boundary so I added another dummy double local, so it
is now aligned:

2df0: 66 0f d6 45 f0 movq %xmm0,-0x10(%rbp)

2dc5: e8 96 d2 ff ff call 60 <printf>
2dca: 48 83 c4 20 add $0x20,%rsp
2dce: f3 0f 7e 45 10 movq 0x10(%rbp),%xmm0
2dd3: 66 0f 2f 04 25 b0 04 comisd 0x4b0,%xmm0
2dda: 00 00
2ddc: 0f 83 58 00 00 00 jae 2e3a <l289+0x6e0>
2de2: f3 0f 7e 45 10 movq 0x10(%rbp),%xmm0
2de7: 66 0f 57 04 25 e0 02 xorpd 0x2e0,%xmm0
2dee: 00 00
2df0: 66 0f d6 45 f0 movq %xmm0,-0x10(%rbp)
2df5: 48 83 ec 20 sub $0x20,%rsp

But result is the same.

got a negative
result is -1
[cc64.exe] Error -1073741819: Unknown error

I also added another printf for good measure and it is
"definitely" going into the "if":

Compiling stdlib.i to stdlib.obj
result is 0
result is 1
result is 1
result is 0
result is 1
got a negative
result is -1
inside if
[cc64.exe] Error -1073741819: Unknown error

BFN. Paul.

The 2e0 is presumably this:

C:\devel\pdos\pdpclib>objdump -D stdio.obj >temp.txt

Disassembly of section .data:

....

00000000000002e0 <fchsmask_pd>:
2e0: 00 00 add %al,(%rax)
2e2: 00 00 add %al,(%rax)
2e4: 00 00 add %al,(%rax)
2e6: 00 80 00 00 00 00 add %al,0x0(%rax)
2ec: 00 00 add %al,(%rax)
2ee: 00 80 add %al,0x5a5a5a5a(%rax)

00000000000002f0 <kk1>:
2f0: 5a pop %rdx
2f1: 5a pop %rdx
2f2: 5a pop %rdx
2f3: 5a pop %rdx
2f4: 5a pop %rdx
2f5: 5a pop %rdx
2f6: 5a pop %rdx
2f7: 41 rex.B
2f8: 2e 24 24 cs and $0x24,%al
2fb: 24 00 and $0x0,%al

BFN. Paul.

I realized I now have gdb.

C:\devel\pdos\cc64>gdb --args cc64 -c -out:stdlib.obj stdlib.i

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from cc64...
(No debugging symbols found in cc64)
(gdb) go
Command requires an argument.
(gdb) run
Starting program: C:\devel\pdos\cc64\cc64.exe -c -out:stdlib.obj stdlib.i
Compiling stdlib.i to stdlib.obj
result is 0
result is 1
result is 1
result is 0
result is 1
got a negative
result is -1
inside if

Program received signal SIGSEGV, Segmentation fault.
0x0000000002d499c6 in ?? ()
(gdb) where
#0 0x0000000002d499c6 in ?? ()
#1 0x0000000002f5f0ca in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) quit
A debugging session is active.

Inferior 1 [process 3108] will be killed.

Quit anyway? (y or n) y

C:\devel\pdos\cc64>

That's all the gdb I actually know.

BFN. Paul.

On 09/09/2023 11:35, Paul Edwards wrote:
> Hi Bart or anyone else who might know.
>
> (note that I haven't read other threads yet as I am busy with this)
>
> I made this change to get around a problem when
> using cc64 but I don't know what is at fault:
>
> C:\devel\pdos\pdpclib>git show 0d02ad6a8ac164f280f72a64077f5a7aa5d46386
> commit 0d02ad6a8ac164f280f72a64077f5a7aa5d46386 (HEAD -> master, origin/master, origin/HEAD)
> Author: Paul Edwards <mutazilah@gmail.com>
> Date: Sat Sep 9 16:52:51 2023 +0800
>
> handle negative floating point numbers for cc64 at least
>
> diff --git a/pdpclib/stdio.c b/pdpclib/stdio.c
> index f6479f9d..831fcebb 100644
> --- a/pdpclib/stdio.c
> +++ b/pdpclib/stdio.c
> @@ -6792,7 +6792,13 @@ static void dblcvt(double num, int cnvtype, int nwidth,
>
> if ( num < 0 )
> {
> - b = -num;
> + /* When using cc64, this line caused a crash */

What type is b? Is it a local variable, or a global?

Is this function a callback function called from code not compiled with
cc64? Because I recall an obscure bug do with that, but I'm not sure it
was a cc64 problem.

Anyway, if compiling with cc64 (ie. my product), just before the error
line where it crashes, try adding a label like this:

fred:
b = -num;

(Use anything which is distinct). Then compile the module using:

cc -s file.c # or whatever it's called

The look inside file.asm (etc) for 'fred', which will show a line like this:

L237: !<fred>

(There is a tab between : and !.) This is to just to isolate and display
the relevant code using assembly rather then trying to disassemble a binary.

But there seems to be nothing remarkable about this code:

if (num < 0) {
b = -num;

when 'b' is a local double variable.

> + /* I'm not sure if you can take a negative of a negative
> + number to make it positive,

I think you can! The method used is to xor the 64-bit float in an XMM
register with the bit-pattern 0x8000'0000'0000'0000. It literally flips
the sign bit.

> 0000000000002410 <dblcvt>:
> 2410: 55 push %rbp
> 2411: 48 8b ec mov %rsp,%rbp
> 2414: 48 81 ec d0 00 00 00 sub $0xd0,%rsp
> 241b: 66 0f d6 45 10 movq %xmm0,0x10(%rbp)
> 2420: 48 89 55 18 mov %rdx,0x18(%rbp)
> 2424: 4c 89 45 20 mov %r8,0x20(%rbp)
> 2428: 4c 89 4d 28 mov %r9,0x28(%rbp)
> 242c: f3 0f 7e 45 10 movq 0x10(%rbp),%xmm0
> 2431: 66 0f 2f 04 25 e8 03 comisd 0x3e8,%xmm0
> 2438: 00 00
> 243a: 0f 83 33 00 00 00 jae 2473 <dblcvt+0x63>
> 2440: 48 83 ec 20 sub $0x20,%rsp
> 2444: 48 b9 41 03 00 00 00 movabs $0x341,%rcx

I find the source examples you post with its + and - signs signed very
confusing. But what is this a disassembly of, working code or crashing code?

Is it my generated code? (The AT&T syntax is not helpful either!)

On Saturday, September 9, 2023 at 8:25:53 PM UTC+8, Bart wrote:

First the easy things:

> > - b = -num;
> > + /* When using cc64, this line caused a crash */
> What type is b? Is it a local variable, or a global?

void dblcvt(double num, int cnvtype, int nwidth,
int nprecision, char *result)
{ double qqqqqq;
double b,round;

b is a local double. I added the qqqqqq since then to
force 16-byte alignment.

> Is this function a callback function called from code not compiled with
> cc64?

No - everything has been compiled with cc64 other than
a little bit of hand-written assembler and the calls to
very basic kernel32 functions.

> > + /* I'm not sure if you can take a negative of a negative
> > + number to make it positive,
> I think you can! The method used is to xor the 64-bit float in an XMM
> register with the bit-pattern 0x8000'0000'0000'0000. It literally flips
> the sign bit.

Is either the above or the code below in error?
As there are two x'80' in the 16-byte value below:

00000000000002e0 <fchsmask_pd>:
2e0: 00 00 add %al,(%rax)
2e2: 00 00 add %al,(%rax)
2e4: 00 00 add %al,(%rax)
2e6: 00 80 00 00 00 00 add %al,0x0(%rax)
2ec: 00 00 add %al,(%rax)
2ee: 00 80 add %al,0x5a5a5a5a(%rax)

> I find the source examples you post with its + and - signs signed very
> confusing. But what is this a disassembly of, working code or crashing code?

Crashing code. The working code is run first (multiply by -1.0)
and then later on (after I see the result), I try doing the original
negative operation, and get the crash.
> Is it my generated code? (The AT&T syntax is not helpful either!)

Yes, your code. objdump only seems to give AT&T as an
option. But at least all the register names are standard
this way as opposed to cc64 output.

I have been learning more things in gdb and all the memory
that is used is addressable and has the expected values,
as does xmm0.

I'll do the other stuff requested in due course.

Thanks. Paul.

Ok, some more things before doing Bart's stuff.

The issue with the two x'80' could be deficiencies
in the C header files I use that were only designed
for 32-bit, but I don't think so.

And here is the gdb info.

(gdb) where
#0 0x0000000002d499c6 in ?? ()
#1 0x0000000002f5f0ca in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

So that address 2d499c6 is probably either the failing instruction
itself, or the instruction AFTER the failing instruction. Here is the
data at that address:

(gdb) x/9xb 0x2d499c6
0x2d499c6: 0x66 0x0f 0x57 0x04 0x25 0x48 0xe9 0xce
0x2d499ce: 0x02

Corresponding to the second instruction here:

2df9: f3 0f 7e 45 10 movq 0x10(%rbp),%xmm0
2dfe: 66 0f 57 04 25 e0 02 xorpd 0x2e0,%xmm0
2e05: 00 00
2e07: 66 0f d6 45 f0 movq %xmm0,-0x10(%rbp)

The previous instruction is:

(gdb) x/5xb 0x2d499c1
0x2d499c1: 0xf3 0x0f 0x7e 0x45 0x10

So the first instruction is still intact, and we can look at
the data at rbp + 0x10 and see:

(gdb) info r
rax 0xa 10
rbx 0x2cc74b2 46953650
rcx 0x0 0
rdx 0x0 0
rsi 0x2f5ed48 49671496
rdi 0x2cc74bb 46953659
rbp 0x2f5f030 0x2f5f030
rsp 0x2f5ef60 0x2f5ef60
r8 0x2f5ebe8 49671144
r9 0x1 1
r10 0x0 0
r11 0x246 582
r12 0x35ef648 56555080
r13 0x35ef688 56555144
r14 0x0 0
r15 0x0 0
rip 0x2d499c6 0x2d499c6
eflags 0x10206 [ PF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
(gdb)

0x2f5f030 + 0x10 = 0x2f5f040:

(gdb) x/16xb 0x2f5f040
0x2f5f040: 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0xbf
0x2f5f048: 0x67 0x00 0x00 0x00 0x00 0x00 0x00 0x00

I have no reason to question that value, and it arrived in xmm0,
but not necessarily from that instruction:

(gdb) info all-registers
rax 0xa 10
rbx 0x2cc74b2 46953650
rcx 0x0 0
rdx 0x0 0
rsi 0x2f5ed48 49671496
rdi 0x2cc74bb 46953659
rbp 0x2f5f030 0x2f5f030
....
--Type <RET> for more, q to quit, c to continue without paging--
xmm0 {v8_bfloat16 = {0x0, 0x0, 0x0, 0xffff, 0x0, 0x0, 0x0, 0x0}, v4_float = {0x0, 0xffffffff, 0x0, 0x0}, v2_double = {0xffffffffffffffff, 0x0}, v16_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xbf, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0xbff0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0xbff00000, 0x0, 0x0}, v2_int64 = {0xbff0000000000000, 0x0}, uint128 = 0xbff0000000000000}
xmm1 {v8_bfloat16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x0}

Noting that it looks like only 8 bytes, not 16 bytes, was copied,
which is to be expected from a movq instruction.

So it's more likely to be this instruction that is failing:

2dfe: 66 0f 57 04 25 e0 02 xorpd 0x2e0,%xmm0
2e05: 00 00

And the address has changed from 0x2e0 to:

0x2d499c6: 0x66 0x0f 0x57 0x04 0x25 0x48 0xe9 0xce
0x2d499ce: 0x02

0x2cde948

And at that address we find:

(gdb) x/16b 0x2cde948
0x2cde948: 0x00 0x64 0x6f 0x5f 0x6d 0x6f 0x76 0x00
0x2cde950: 0x67 0x65 0x74 0x72 0x65 0x67 0x63 0x6f
(gdb)

which looks like corruption. I assume the full 16 bytes are used,
and it presumably creates an invalid floating point value, which
is what causes the exception.

It seems to have been clobbered by:

(gdb) x/16c 0x2cde948
0x2cde948: 0 '\000' 100 'd' 111 'o' 95 '_' 109 'm' 111 'o' 118 'v' 0 '\000'
0x2cde950: 103 'g' 101 'e' 116 't' 114 'r' 101 'e' 103 'g' 99 'c' 111 'o'
(gdb)

do_mov and getregco...

both strings present in cc64:

C:\devel\pdos\cc64>grep do_mov cc64.c | grep "\""
cc64.c: (byte*)"do_mov",
cc64.c: (byte*)"do_mov",
cc64.c: (byte*)"do_movsx",
cc64.c: (byte*)"do_movsxd",
cc64.c: (byte*)"do_movxmm",
cc64.c: (byte*)"do_movdqx",

C:\devel\pdos\cc64>grep getregco cc64.c | grep "\""
cc64.c: (byte*)"getregcoder",
cc64.c: (byte*)"getregcodeb",
cc64.c: (byte*)"getregcodebx",
cc64.c: (byte*)"getregcoderx",

C:\devel\pdos\cc64>

So I need to find out what is causing this trashing of memory.

It's almost certainly a problem in PDPCLIB (or cc64 code
generation from PDPCLIB), as previous testing was done
with standard msvcrt.dll - this is the first time I am doing
static linking.

Note that the reason I am doing static linking in the first place
is because I had a problem when cc64 was being run under
UCX64 where a replacement msvcrt.dll is effectively provided,
effectively exposing cc64 to cc64-compiled pdpclib.

BFN. Paul.

On 09/09/2023 14:43, Paul Edwards wrote:
> Ok, some more things before doing Bart's stuff.
>
> The issue with the two x'80' could be deficiencies
> in the C header files I use that were only designed
> for 32-bit, but I don't think so.

The x80 thing is of no signifance, as they are data not code. Using -s
on a minimal program that negates a float will reveal these lines within
the .asm file:

segment idata
align 16
fchsmask_ps: dq 0x80000000'80000000, 0x80000000'80000000
fchsmask_pd: dq 0x80000000'00000000, 0x80000000'00000000

The masks will negate either 4 floats or 2 doubles; bcc only uses the
bottom 32 or 64 bits of the 128-bit register. This looks similar to the
negate method used by gcc-generated code (so, negating 0.0 will likely
yield -0.0).

(Note that 'fchs' is the x87 negate instruction; x87 is now little used.)

> C:\devel\pdos\cc64>grep do_mov cc64.c | grep "\""
> cc64.c: (byte*)"do_mov",
> cc64.c: (byte*)"do_mov",
> cc64.c: (byte*)"do_movsx",
> cc64.c: (byte*)"do_movsxd",
> cc64.c: (byte*)"do_movxmm",
> cc64.c: (byte*)"do_movdqx",
>
> C:\devel\pdos\cc64>grep getregco cc64.c | grep "\""
> cc64.c: (byte*)"getregcoder",
> cc64.c: (byte*)"getregcodeb",
> cc64.c: (byte*)"getregcodebx",
> cc64.c: (byte*)"getregcoderx",

These strings are just function tables which are used for reflection in
the original language used to implement bcc. Your cc64.c file is from
2020; I no longer generate that info for all functions. (It was making
the executables bigger than needed.)

On 09/09/2023 13:41, Paul Edwards wrote:
> On Saturday, September 9, 2023 at 8:25:53 PM UTC+8, Bart wrote:

>> Is it my generated code? (The AT&T syntax is not helpful either!)
>
> Yes, your code. objdump only seems to give AT&T as an
> option. But at least all the register names are standard
> this way as opposed to cc64 output.

I can probably change that in my upcoming C compiler (I want to touch
the existing one as little as possible). But there needs to be an option
to show either, as I need my designations for my own debugging. I
consider the Intel register names to be a zoo.

On Saturday, September 9, 2023 at 9:43:28 PM UTC+8, Paul Edwards wrote:

> 0x2d499c6: 0x66 0x0f 0x57 0x04 0x25 0x48 0xe9 0xce
> 0x2d499ce: 0x02
>
> 0x2cde948

I stuffed this up - it should have been 0x2cee948.

I went looking for the code causing corruption and the
data area is not corrupt - at least in the latest test.

inside if
02CEE948 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 80
parm is 00000024

Program received signal SIGSEGV, Segmentation fault.
0x0000000002d49dcb in ?? ()
(gdb) x/9xb 0x0000000002d49dcb
0x2d49dcb: 0x66 0x0f 0x57 0x04 0x25 0x48 0xe9 0xce
0x2d49dd3: 0x02
(gdb) x/16xb 0x2cee948
0x2cee948: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80
0x2cee950: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80
(gdb) x/5xb 0x0000000002d49dc6
0x2d49dc6: 0xf3 0x0f 0x7e 0x45 0x10
(gdb)

And neither instruction looks like it should fail to me.

(gdb) info r
rax 0x11 17
rbx 0x2cc74b2 46953650
rcx 0x0 0
rdx 0x0 0
rsi 0x2f5ed08 49671432
rdi 0x2cc74c2 46953666
rbp 0x2f5f030 0x2f5f030
rsp 0x2f5ef60 0x2f5ef60
r8 0x2f5eba8 49671080
r9 0x1 1
r10 0x0 0
r11 0x246 582
r12 0x3535648 55793224
r13 0x3535688 55793288
r14 0x0 0
r15 0x0 0
rip 0x2d49dcb 0x2d49dcb
eflags 0x10206 [ PF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
(gdb) x/16xb 0x2f5f040
0x2f5f040: 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0xbf
0x2f5f048: 0x67 0x00 0x00 0x00 0x00 0x00 0x00 0x00
(gdb)

BFN. Paul.

On Saturday, September 9, 2023 at 8:25:53 PM UTC+8, Bart wrote:

> Anyway, if compiling with cc64 (ie. my product), just before the error
> line where it crashes, try adding a label like this:
>
> fred:
> b = -num;
>
> (Use anything which is distinct). Then compile the module using:
>
> cc -s file.c # or whatever it's called
>
> The look inside file.asm (etc) for 'fred', which will show a line like this:
>
> L237: !<fred>
>
> (There is a tab between : and !.) This is to just to isolate and display
> the relevant code using assembly rather then trying to disassemble a binary.

With the latest code, which includes:

strcat(result,work);
+ if (__G_live == 2) __G_debug((void *)0x23);
+ printf("result is %s\n", result);
+ if ( num < 0 )
+ {
+ printf("inside if\n");
+ if (__G_live == 2) __G_debug((void *)0x24);
+ fredblog:
+ b = -num;
+ if (__G_live == 2) __G_debug((void *)0x25);
+ printf("done negation\n");
+ printf("done negation\n");
+ printf("done negation\n");
+ }
return;
}

C:\devel\pdos\pdpclib>git diff stdio.c

(note the "fredblog" label as requested)

And with a result of:

result is X-1.0000000000000000000000000000X
result is X-1.00000000000000000000000000000X
result is X-1.000000000000000000000000000000X
02CEE948 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 80
parm is 00000022
02CEE948 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 80
parm is 00000023
result is -1
inside if
02CEE948 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 80
parm is 00000024

(crash)

I have generated assembler of:

mov A0, [`__G_live*]
cmp A0, 2
jnz L355
sub Dstack, 32
mov D10, 36
call `__G_debug*
add Dstack, 32
L355:
L1: !<fredblog>
movq XMM0, [Dframe+16]
xorpd XMM0, [fchsmask_pd]
movq [Dframe-16], XMM0
mov A0, [`__G_live*]
cmp A0, 2
jnz L356
sub Dstack, 32
mov D10, 37
call `__G_debug*
add Dstack, 32
L356:
sub Dstack, 32
mov D10, KK18
call `printf

Note that this debug gets printed:

mov D10, 36

36 = 0x24

The only thing I can see odd is:

xorpd XMM0, [fchsmask_pd]

accessing two x'80':

02CEE948 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 80

but you already said that was OK, and regardless, I don't
expect a SEGV from that, I expect some sort of floating
point error if there is something wrong with the data.

BFN. Paul.

On Sunday, September 10, 2023 at 9:08:35 AM UTC+8, Paul Edwards wrote:

> The only thing I can see odd is:
>
> xorpd XMM0, [fchsmask_pd]
>
> accessing two x'80':
> 02CEE948 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 80

After a lot of effort - that address ends with 8, not 0!!!

Suspecting pdld error now, not cc64.

BFN. Paul.

..data

..p2align 4

zzz:
..quad 0x0000000000000000
zzz2:
..quad 0x0000000000000000
..quad 0x0000000000000000
..quad 0x0000000000000000
..quad 0x0000000000000000
..quad 0x0000000000000000

..text

..globl myfunc
myfunc:
nop
nop
nop
# change this zzz to zzz2 and you get 16-byte
# alignment and it works
xorpd zzz,%xmm0
nop
nop
nop
ret

On 10/09/2023 09:17, Paul Edwards wrote:
> On Sunday, September 10, 2023 at 9:08:35 AM UTC+8, Paul Edwards wrote:
>
>> The only thing I can see odd is:
>>
>> xorpd XMM0, [fchsmask_pd]
>>
>> accessing two x'80':
>> 02CEE948 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 80
>
> After a lot of effort - that address ends with 8, not 0!!!

Looking at that cc64-generated .asm file of your earlier post, how was
fchsmask_pd defined? It should be something like this:

segment idata
align 16
fchsmask_ps: dq 0x80000000'80000000, 0x80000000'80000000
fchsmask_pd: dq 0x80000000'00000000, 0x80000000'00000000

If that 'align 16' was missing, then it's wrong. This data must be
16-byte-aligned.

I tried to run my 2020 cc64.c, but it hangs compiling anything. but then
it may be unrelated to the version you have.

However, inside its 'cc_genasm_writefabs' function, it does generate
that correct 'align 16' instruction. You might check your version.

> Suspecting pdld error now, not cc64.

It could be an error in the back-end of cc64 which is its assembler.
Although that is used extensively elsewhere, it is only with C programs
that multiple idata segments from different files are combined.

Still, all such 'idata' data is combined into a single segment; it will
know the current alignment, and the whole segment is aligned to a
512-byte boundary.

If you take the .asm file, and add a line like this following fchsmask_pd:

dq 0x1122334455667788, 0x8877665544332211

assemble it with my 'aa' assembler, then this should be easier to search
for within the final executable.

On Sunday, September 10, 2023 at 5:26:14 PM UTC+8, Bart wrote:

> > After a lot of effort - that address ends with 8, not 0!!!

> Looking at that cc64-generated .asm file of your earlier post, how was
> fchsmask_pd defined? It should be something like this:
> segment idata
> align 16
> fchsmask_ps: dq 0x80000000'80000000, 0x80000000'80000000
> fchsmask_pd: dq 0x80000000'00000000, 0x80000000'00000000
> If that 'align 16' was missing, then it's wrong. This data must be
> 16-byte-aligned.

cc64 is doing the right thing ...

segment idata
align 16
fchsmask_ps: dq 0x80000000'80000000, 0x80000000'80000000
fchsmask_pd: dq 0x80000000'00000000, 0x80000000'00000000

.... at least if the assembler can be trusted.

We'll wait on Slovakia to agree that it's his problem to fix. :-)

He normally fixes bugs my overnight (his day).

BFN. Paul.

On Sunday, September 10, 2023 at 5:34:38 PM UTC+8, Paul Edwards wrote:

> We'll wait on Slovakia to agree that it's his problem to fix. :-)
>
> He normally fixes bugs my overnight (his day).

But acknowledged, fixed and committed.

BFN. Paul.