passing string arguments generates broken code about go.arm64

[mwhudson]

Soo... this turns out to be something like this:

agen is called for the string argument, which is a OINDREG node with n->val.u.reg of SP/R31
agen wraps its argument in a OADDR node and calls gins(AMOV, OADDR-node, ...)
gins calls naddr() on the OADDR node
this makes an D_CONST Addr with reg set REGSP
... but REGSP is also REGZERO, so this means that this D_CONST is just interpreted as a constant, not as a memory reference.

[mwhudson]

This reminds me of issue #14 in some ways -- a Addr with type D_CONST and reg == 31 is ambiguous, does it mean a constant 0 or an indirection through SP? I guess if offset is not 0 it isn't ambiguous in this way, but ...

[4ad]

I don't understand, where does the D_CONST come from? naddr does not set D_CONST.

[4ad]

Can you please describe in more detail and more clearly what you think is going on? I don't understand exactly what you mean.

Regarding the const ambiguity, I don't understand what you mean either, there is no ambiguity. For constants, a->reg is usually NREG (e.g. no register). It can also be 31, but then it's always ZR. It can never be SP, and it can never be any other register. Something like 16(SP) is not D_CONST, it is D_OREG. 16(ZR) doesn't exist, so no ambiguity there. 0(R31) is Z_OREG, but its meaning is clear in the optab table. Every optab line has a known meaning of R31. When there is ambiguity in the implementation in asmout (e.g. if many optab lines map to the same case in optab), that ambiguity is solved by using (or not) REGSP in the optab param field. So there's no ambiguity there.

[4ad]

Note that $16(SP) (e.g. effective address of dword on stack) is also D_CONST with a->reg=NREG (32), NOT 31. a->name will be D_AUTO, and there is again no ambiguity there. Something like $8(R5) doesn't exist (our tools seem to accept that form too, and think it's also D_AUTO, but it's a bug, they should reject it). Again I don't see any ambiguity.

[mwhudson]

"I don't understand, where does the D_CONST come from? naddr does not set D_CONST." -- sure it does, https://github.com/4ad/go/blob/dev.arm64/src/cmd/7g/gsubr.c#L1258

" It can also be 31, but then it's always ZR. It can never be SP, and it can never be any other register." -- but REGZERO and REGSP are both 31?

Anyway to explain what is going on, I suggest: running 7g -l -g -M to compile the file I pasted above, set a breakpoint on agen and step through the second time agen is called.

[4ad]

On Mon, Feb 2, 2015 at 7:23 PM, Michael Hudson-Doyle <
[email protected]> wrote:

but REGZERO and REGSP are both 31?

Yes, so? D_CONST will never have any register set, except for ZR.

Aram Hăvărneanu

[mwhudson]

Well maybe I'm chasing the wrong fish entirely, I'm happy to not debug it myself :) You do see that the current output is completely wrong, though?

[4ad]

Yes, it is very wrong.

[4ad]

D_CONST will never have any register set, except for ZR.

s/will/should

It's currently possible to generate an Addr with an arbitrary register for D_CONST, but that's clearly a bug.

[mwhudson]

This also affects passing arguments as interface{} too. It's basically blocking further progress at this point.

[davecheney]

Hello,

my take so far this morning is passing arguments of any fat type is faulty. The compiler tries to copy the interface onto the stack for the call but ends up buggering it up completely causing a SIGBUS.

This is why it affects strings, interfaces and other fat types.

The code generated by 7g is similar to 9g, but dissimilar to 5g as 5g has a working componentgen.

[forsyth]

On 2 February 2015 at 21:41, Dave Cheney [email protected] wrote:

my take so far this morning is passing arguments of any fat type is
faulty. The compiler tries to copy the interface onto the stack for the
call but ends up buggering it up completely causing a SIGBUS.

yes, it's trying to generate a block assignment and not doing too well.

[4ad]

The problem is that a->reg should be NREG, not REGSP, and a->name should be D_AUTO (if it already isn't).

[4ad]

One line fix, 238 LOC comment.

[4ad]

This was a PITA to fix because while I had the fix ready in minutes, the printing code for constants still printed wrong code. It took hours until I used objdump on the binary to see that it is in fact fixed.

[4ad]

Ok, we now have a different problem:

0x0020 00032 (b.go:12)  MOV 8(R1),R2
0x0024 00036 (b.go:12)  MOV R2,8(R0)
0x0028 00040 (b.go:12)  MOV 8(R1),R2
0x002c 00044 (b.go:12)  MOV R2,8(R0)

That should be (R1)8! and similar. sgen is broken.

[4ad]

Fixed in 582e07f.