9front - general discussion about 9front
 help / color / mirror / Atom feed
* 5l breakage on zynq
@ 2020-05-12 14:08 qwx
  2020-05-12 15:08 ` [9front] " ori
  0 siblings, 1 reply; 4+ messages in thread
From: qwx @ 2020-05-12 14:08 UTC (permalink / raw)
  To: 9front

Hello,

5l no longer works on my aijuboard after update:

; cd /sys/src/cmd/5l
; mk
5c -FTVw asm.c
5c -FTVw list.c
5c -FTVw noop.c
5c -FTVw obj.c
5c -FTVw optab.c
5c -FTVw pass.c
5c -FTVw span.c
5c -FTVw ../5c/enam.c
5c -FTVw compat.c
5l  -o 5.out asm.5 list.5 noop.5 obj.5 optab.5 pass.5 span.5 enam.5 compat.5
5l 2567: suicide: sys: trap: alignement fault write addr=0x0002e5b6 pc=0x0000a428
mk: 5l  -o ...  : exit status=rc 2565: 5l 2567: sys: trap: alignement fault write addr=0x0002e5b6 pc=0x0000a428

; acid 2567
/proc/2567/text:arm plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/arm
acid: lstk()
lookup(v=0x0,symb=0x1fcfb)+0x118 /sys/src/cmd/5l/obj.c:1110
	l=0x3
	h=0xe3
	s=0x2e5b6
ldobj(f=0x4,pn=0xdfffff88,c=0x172cc)+0x2b4 /sys/src/cmd/5l/obj.c:786
	nfilen=0x2e570
	bsize=0x21cf8
	bloc=0x1fcfb
	di=0x0
	h=0x0
	ipc=0x0
	skip=0x0
	o=0x1
	sig=0x0
	stop=0x1fcfd
	v=0x11
	s=0x0
	p=0xffffffff
	r=0x0
objfile(file=0xdfffff88)+0x148 /sys/src/cmd/5l/obj.c:356
	name=0x7
	f=0x4
	magbuf=0x3c01114d
	l=0x172cf
	arhdr=0xf924
	esym=0x7c2c
	off=0x2e54c
	cnt=0x789
	start=0x8
	stop=0xf5c8
	work=0x6
	e=0x8
	pname=0x18160
	s=0x18539
main(argc=0x9,argv=0xdfffff54)+0x32c /sys/src/cmd/5l/obj.c:242
	_argc=0x6f
	_args=0xdfffff81
strstr+0x4c /sys/src/libc/port/strstr.c:24
acid: src(lookup+0x118)
/sys/src/cmd/5l/obj.c:1110
 1105			gethunk();
 1106		s = (Sym*)hunk;
 1107		nhunk -= sizeof(Sym);
 1108		hunk += sizeof(Sym);
 1109	
>1110		s->name = malloc(l);
 1111		memmove(s->name, symb, l);
 1112	
 1113		s->link = hash[h];
 1114		s->type = 0;
 1115		s->version = v;


The 5? were built on amd64, not on zynq.
5l works again when reverting commit 7668:

changeset:   7668:6c63b0f4ecce
user:        cinap_lenrek@felloff.net
date:        Sat Apr 11 05:03:49 2020 +0200
summary:     cc, ?[acl]: fix gethunk() and move common memory allocator code to cc/compat

; hg revert -r 7667 /sys/src/cmd/^(5a 5c 5l cc 6c 6a 6l)

... and rebuilding compilers/loaders and libc/libbio.

Any idea what broke?

Thanks,

qwx


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9front] 5l breakage on zynq
  2020-05-12 14:08 5l breakage on zynq qwx
@ 2020-05-12 15:08 ` ori
  2020-05-12 20:09   ` cinap_lenrek
  0 siblings, 1 reply; 4+ messages in thread
From: ori @ 2020-05-12 15:08 UTC (permalink / raw)
  To: qwx, 9front


> 
> ; hg revert -r 7667 /sys/src/cmd/^(5a 5c 5l cc 6c 6a 6l)
> 
> ... and rebuilding compilers/loaders and libc/libbio.
> 
> Any idea what broke?
> 
> Thanks,
> 

Yeah -- I think I see it:
	
	 1106		s = (Sym*)hunk;
	 1107		nhunk -= sizeof(Sym);
	 1108		hunk += sizeof(Sym);
	 1109	
	>1110		s->name = malloc(l);

This assumes that hunk is aligned, but the change to
malloc in the commit you flagged may leave it unaligned:

	void*
	alloc(long n)
	{
		void *p;
	
		while((uintptr)hunk & 7) {
			hunk++;
			nhunk--;
		}
		while(nhunk < n)
			gethunk();
		p = hunk;
		nhunk -= n;
		hunk += n;
		return p;
	}

Here, we always align the hunk on entry, but we ma
leave hunk unaligned on exit, if n is not a multiple
of 8. Then, when it's used directly, 's' is misaligned.

Try this patch, which aligns 'n' to a multiple of 8
before we allocate:

diff -r 965e0f59464d sys/src/cmd/cc/compat
--- a/sys/src/cmd/cc/compat	Sun May 10 22:51:40 2020 +0200
+++ b/sys/src/cmd/cc/compat	Tue May 12 08:02:58 2020 -0700
@@ -107,6 +107,7 @@
 {
 	void *p;
 
+	n = (n + 7) & (~7);
 	while((uintptr)hunk & 7) {
 		hunk++;
 		nhunk--;



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9front] 5l breakage on zynq
  2020-05-12 15:08 ` [9front] " ori
@ 2020-05-12 20:09   ` cinap_lenrek
  2020-05-12 20:17     ` qwx
  0 siblings, 1 reply; 4+ messages in thread
From: cinap_lenrek @ 2020-05-12 20:09 UTC (permalink / raw)
  To: 9front

pushed a fix by removing all the hunk pointer fiddling from
the linker and put a explaination of the problem in the
commit message.

ori's patch is correct. but i think it is better just to
stop making all these internal hidden assumptions and just
use malloc().

overall, we might even start just phasing out the hunk stuff
and just use malloc()/relloc() calls, but link with a fast
non-freeing implementation from cc/.

--
cinap


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9front] 5l breakage on zynq
  2020-05-12 20:09   ` cinap_lenrek
@ 2020-05-12 20:17     ` qwx
  0 siblings, 0 replies; 4+ messages in thread
From: qwx @ 2020-05-12 20:17 UTC (permalink / raw)
  To: 9front

Thanks, the linkers now work as normal.

Cheers,

qwx


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-05-12 20:17 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-12 14:08 5l breakage on zynq qwx
2020-05-12 15:08 ` [9front] " ori
2020-05-12 20:09   ` cinap_lenrek
2020-05-12 20:17     ` qwx

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).