Re: [9fans] _tos puzzle

["Russ Cox" <rsc@swtch.com>]

> I set EAX before starting the executable, but still no luck :(
> On Plan 9, for /bin/mk:
>
> acid: symbols("_tos")
> _tos		D	0x00016084
> acid: mem(0x00016084, "X")
> 0xdfffefc8
>
> I'm probing address 0x16084 on linux after every instruction (using
> ptrace's singlestep), and it consistently returns 0. EIP at the
> beginning of the program is 0x9fe4, and sure enough:
>
> acid: asm(0x9fe4)
> _main		SUBL	$0x48, SP
> _main+0x3	MOVL	AX, _tos(SB)
> ...
>
> So (MOVL, _tos(SB)) is definitely executed, but for some reason, the
> value of AX is not stored in 0x16084.

You should print AX after every instruction too, to see if
you've actually set it up the way you think you did.

> That brings me to the question
> of how 8a decides what address to put values like that in? Is the
> address the same everytime, i.e. hardcoded into the binary? (certainly
> seems to be)

_tos is no different than any other global variable.
8a doesn't use any address at all - it leaves a slot for 8l to fill in.
The eventual address of _tos depends on what other data
is in the binary.  I don't know why you say the address is
the same every time:

cpu% nm /bin/cat |grep _tos
    600c D _tos
cpu% nm /bin/ls |grep _tos
    d060 D _tos
cpu% nm /bin/echo |grep _tos
    9008 D _tos
cpu%

> I strip the symbol table from plan 9 executables and store only data,
> text and initialize bss in memory - maybe that has something to do
> with it. Does the symbol table need to be in memory too for
> instructions like (MOVL AX, _tos(SB)) to work?

No, the symbol table is only for debuggers and the like.
Plan 9 doesn't load it into memory either.

The good news is that you've identified the program
behaving incorrectly after executing only *two* instructions.
That should narrow things down considerably.

Russ