Hi Ken--

I built GdbARMv8Plugin on macOS without a hitch, but it failed primitively before doing any actual work, during startup.

Before that I tried to build in Linux on a Raspberry Pi, but there was multi-level header-ordering hell even worse that the one involving Linux features.h and our sq.h. When I got to the point of two Linux headers both saying they should be included before the other, I stopped.

I do think, though, that Tobias' theory is compelling:

On 21/6/21 04:20, Tobias Pape wrote:

Hi

...

On 21. Jun 2021, at 12:15, Bruce O'Neel bruce.oneel@pckswarms.ch

wrote:

...

Hi,

I have now gone back and checked this carefully. The git repository

at the commit before this one produces the right answer for 2 raisedTo: 64 on Aarch64. It produces the wrong answer, 0, when this commit is included.

...

So it's this commit. I'll look at the code to see if I can see why

the code is bad.

...

BTW, how would one find the two referenced packages?

https://source.squeak.org/VMMaker/ has all the packages. (or

http://source.squeak.org/VMMaker.html)

The diff for the first one

(https://source.squeak.org/VMMaker/VMMaker.oscog-eem.2799.diff) ist truncated,

while the diff-changeset is ok:

http://source.squeak.org/VMMaker/changes/VMMaker.oscog-eem.2799(2798).cs

(you see all changed methods, but not the actual diff)

But this only adds the JumpMulOverflow / JumpNoMulOverflow

names/class-vars.

The implementation diff is found at http://www.squeaksource.com/ClosedVMMaker/ClosedVMMaker-eem.98.diff

I would suggest that our bug does not concern Jumps, but rather only

Mul, so we have to start looking

at the differences for concretizeMulOverflowRRR ...

From what I see, tho, is that the MUL and the SMULH instruction

order has been reversed.

(Also, the arm blog uses an different interesting method of detecting

overflow,

by missusing the argument shitfter of CMP:

https://community.arm.com/developer/ip-products/processors/b/processors-ip-b...

Although this is written for older arm, it seems to be applicable to

the 64-variant too)

Best regards -Tobias

-C

***

On 26/6/21 15:43, ken.dickey@whidbey.com wrote:

Small progress.

The stack interpreter and cog VMs share the LargeIntegers plugin, but stack: (16r8000000000000000 * 16) printStringHex."--> '80000000000000000' " cog: (16r8000000000000000 * 16) printStringHex." --> '0' "

I was able to build a SpurVMMaker.image using the stack-interpreter VM and would like to invoke: StackToRegisterMappingCogit genAndDis: Integer class>>#xReadFrom:base:

But have had zero success in building the required GdbARMv8Plugin [Linux/aarch64].

Can some kind soul who actually knows how to deal with the fragile and complex C environment help me out?

Thanks much, -KenD

-- Craig Latta :: research computer scientist Black Page Digital :: Berkeley, California 663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE