This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH 2/2] MIPS16: MIPS16 support proper


Steve,

> After some poking around I think the problem is not the glibc that I built but with crti.o and crtn.o.  If I use
> regular mips32 versions of these crt files and mips16 built versions of everything else (main program, glibc,
> libgcc, etc.) then I can run a simple hello world program, if I use the mips16 versions of crti and crtn I get:
> 
> 
> mips-mti-linux-gnu-gcc -mips32r2 -mips16 '-Wl,--dynamic-linker=/local/home/sellcey/gcc/mips16/sysroot-mips-mti-linux-gnu/mips16/usr/lib/ld-2.17.90.so' '-Wl,-rpath=/local/home/sellcey/gcc/mips16/sysroot-mips-mti-linux-gnu/mips16/usr/lib:/local/home/sellcey/gcc/mips16/install-mips-mti-linux-gnu/mips-mti-linux-gnu/lib/mips16' hi.c -o x
> 
> mips-mti-linux-gnu-qemu -r 2.6.38 ./x
> hi
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> 
> Note that it did print 'hi' before getting the signal.
> 
> If I try adding '-static' then I get:
> 
> mips-mti-linux-gnu-gcc -static -mips32r2 -mips16 hi.c -o x
> mips-mti-linux-gnu-qemu -r 2.6.38 ./x
> qemu: uncaught target signal 4 (Illegal instruction) - core dumped
> 
> 
> 
> I was wondering if you have any idea what could be causing this.  Should the standard qemu be able
> to run mips16 executables with no changes?

 I am fairly sure QEMU has issues with MIPS16 code, and I wouldn't be 
surprised if user-mode emulation actually required porting QEMU, rather 
than merely fixing bugs, to support MIPS16 binaries -- it may not be 
prepared to handle the ISA bit at all.

 Have you tried running your code on actual hardware?  This is how we did 
testing of all these changes.

 Please also note that as I mentioned along the patch submission mixing 
execution modes in static constructors or destructors installed as single 
lumps of code (that is with the use of the DT_INIT or DT_FINI dynamic 
tags) cannot be supported.  Can you run `objdump -j .init -j .fini -d' on 
your binary and make sure the disassembly looks right?

 Here's an example of correct MIPS16 code from one of the test cases:

Disassembly of section .init:

00400a2c <_init>:
  400a2c:	f000 6a02 	li	v0,2
  400a30:	f692 0b10 	la	v1,3fa0c0 <_DYNAMIC-0x60dc>
  400a34:	f400 3240 	sll	v0,16
  400a38:	e269      	addu	v0,v1
  400a3a:	64c4      	save	32,ra
  400a3c:	659a      	move	gp,v0
  400a3e:	d204      	sw	v0,16(sp)
  400a40:	f030 9a6c 	lw	v1,-32724(v0)
  400a44:	2304      	beqz	v1,400a4e <_init+0x22>
  400a46:	f030 9a4c 	lw	v0,-32724(v0)
  400a4a:	ea40      	jalr	v0
  400a4c:	653a      	move	t9,v0
  400a4e:	6500      	nop
  400a50:	1a00 036e 	jal	400db8 <frame_dummy>
  400a54:	6500      	nop
  400a56:	1a00 0400 	jal	401000 <__do_global_ctors_aux>
  400a5a:	6500      	nop
  400a5c:	6444      	restore	32,ra
  400a5e:	e8a0      	jrc	ra

Disassembly of section .fini:

00401050 <_fini>:
  401050:	f000 6a02 	li	v0,2
  401054:	f072 0b0c 	la	v1,3fa0c0 <_DYNAMIC-0x60dc>
  401058:	f400 3240 	sll	v0,16
  40105c:	e269      	addu	v0,v1
  40105e:	64c4      	save	32,ra
  401060:	659a      	move	gp,v0
  401062:	d204      	sw	v0,16(sp)
  401064:	1a00 035a 	jal	400d68 <__do_global_dtors_aux>
  401068:	6500      	nop
  40106a:	6444      	restore	32,ra
  40106c:	e8a0      	jrc	ra

  Maciej


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]