From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Wed, 21 Aug 2013 17:44:03 -0400
To: 9fans@9fans.net
Message-ID: <1c77ed407dc1ed28544e2033df7088ce@brasstown.quanstro.net>
In-Reply-To: <0A2E2FB2-B2F1-444E-AF62-85FAC05335EA@bitblocks.com>
References: <2332222c9f75f30c6395f16787280535@brasstown.quanstro.net>
	<20130821184909.51FA2B827@mail.bitblocks.com>
	<d92931b41d270e71c61f582b9860649c@brasstown.quanstro.net>
	<0A2E2FB2-B2F1-444E-AF62-85FAC05335EA@bitblocks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] more on why vc can't produce amd64 executables
Topicbox-Message-UUID: 73ae1e0c-ead8-11e9-9d60-3106f5b1d025

#include <u.h>
#include <libc.h>

void
f(void)
{
	write(1, "hello\n", 6);
}

void (*call)(void) = f;

void
main(void)
{
	call();
	exits("");
}

the asm is the same when compiled on any arch,

; acid 6.crash4-mips
6.crash4-mips:amd64 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/amd64
acid; asm(main)
main 0x0020004e	SUBQ	$0x8,SP
main+0x4 0x00200052	MOVQ	call(SB),AX
main+0xc 0x0020005a	CALL*	AX
main+0xe 0x0020005c	MOVL	$.string+0x7(SB),BP
main+0x13 0x00200061	CALL	exits(SB)
main+0x18 0x00200066	ADDQ	$0x8,SP
main+0x1c 0x0020006a	RET
_main 0x0020006b	SUBQ	$0x90,SP

but the data is incorrect in the mips-compiled binary.
	acid; *(call\Y)
	0x0020002800000000

mikro; diff -c crash4-mipsa crash4-amd64a
crash4-mipsa:417,423 - crash4-amd64a:417,423
  2005af 48c7c532000000	(4)	MOVQ	$50,BP
  2005b6 0f05	(5)	SYSCALL	,
  2005b8 c3	(6)	RET	,
- 400010 0000000028002000	(823)	DATA	call+0(SB)/8,$f+0(SB)
+ 400010 2800200000000000	(823)	DATA	call+0(SB)/8,$f+0(SB)
  400030 68656c6c6f0a0000	(829)	DATA	.string<1>+0(SB)/8,$"hello\n\z\z"
  400028 6d61696e	(18)	DATA	_exits<2>+0(SB)/4,$"main\z\z\z\z"
  400000 23632f7069640000	(829)	DATA	.string<7>+0(SB)/8,$"#c/pid\z\z"

i think a bug is setting inuxi8[i+4] = inuxi8[i] for 0<=i<4.
mikro; diffy -c *.c
diff -c /n/dump/2013/0821/sys/src/cmd/6l/obj.c obj.c
/n/dump/2013/0821/sys/src/cmd/6l/obj.c:1455,1471 - obj.c:1455,1471
  	int i, c;

  	for(i=0; i<4; i++) {
- 		c = find1(0x04030201L, i+1);
+ 		c = find1(0x0807060504030201ULL, i+1);
  		if(i < 2)
  			inuxi2[i] = c;
  		if(i < 1)
  			inuxi1[i] = c;
- 		inuxi4[i] = c;
+ 		if(i < 4){
+ 			inuxi4[i] = c;
+ 			fnuxi4[i] = c;
+ 		}
  		inuxi8[i] = c;
- 		inuxi8[i+4] = c+4;
- 		fnuxi4[i] = c;
  		fnuxi8[i] = c;
- 		fnuxi8[i+4] = c+4;
  	}
  	if(debug['v']) {
  		Bprint(&bso, "inuxi = ");
/n/dump/2013/0821/sys/src/cmd/6l/obj.c:1492,1504 - obj.c:1492,1504
  }

  int
- find1(long l, int c)
+ find1(uvlong l, int c)
  {
  	char *p;
  	int i;

  	p = (char*)&l;
- 	for(i=0; i<4; i++)
+ 	for(i=0; i<8; i++)
  		if(*p++ == c)
  			return i;
  	return 0;
/n/dump/2013/0821/sys/src/cmd/6l/obj.c:1505,1517 - obj.c:1505,1517
  }

  int
- find2(long l, int c)
+ find2(uvlong l, int c)
  {
  	short *p;
  	int i;

  	p = (short*)&l;
- 	for(i=0; i<4; i+=2) {
+ 	for(i=0; i<8; i+=2) {
  		if(((*p >> 8) & 0xff) == c)
  			return i;
  		if((*p++ & 0xff) == c)


unfortunately, compiling on mips *still* doesn't work right.
print prints %%p for %p.  i don't know if my fix is wrong, or
if there is another bug.

- erik