OSDev.org

Posted: **Thu May 21, 2009 4:51 am**

When attempting to implement dynamic linking in my OS I started implementing my own version of libc to use in link testing.
After blaming my kernel, then the dynamic linker it seems that the problem is in the binary file itself.

The problem is that when the code tries to get the address of the GOT, the address is two bytes out.
objdump output:

Code: Select all

     627:	e8 00 05 00 00       	call   b2c <_sbrk+0xa5>
     62c:	81 c3 aa 1d 00 00    	add    $0x1daa,%ebx
     632:	c7 45 ec 00 00 00 00 	movl   $0x0,-0x14(%ebp)
     639:	c7 45 f0 00 00 00 00 	movl   $0x0,-0x10(%ebp)
     640:	8b 83 f8 ff ff ff    	mov    -0x8(%ebx),%eax
     646:	8b 00                	mov    (%eax),%eax
**SNIP**
     b2c:	8b 1c 24             	mov    (%esp),%ebx
     b2f:	c3                   	ret

The address of the GOT obtained from the LD linking map is 0x23d8, but the value in EBX after the second instruction is 0x23d6.

I am using the standard linux toolchain (Ubuntu 9.04, gcc 4.3.3, binutils 2.19.1), compiling the library with

Code: Select all

$(CC) -Wall -fPIC -nostdinc -fno-builtin -I./include -fleading-underscore -DBUILD_SO -o $@ -c $<

and linking with

Code: Select all

$(LD) -x -shared -soname libc.so.1 $(OBJ_LIBC) -o $@ -Map map.txt -e _SoMain

Does anyone know what could be causing this error?

Posted: **Thu May 21, 2009 5:17 am**

Hi,

I must say that I'm stumped. The code is functioning correctly - 0x62c+0x1daa is indeed 0x23d6. Does "readelf -d libc.so" agree with your linker map number of 0x23d8?

Cheers,

James

Posted: **Thu May 21, 2009 5:24 am**

JamesM: Yes it does (0x00000003 (PLTGOT) 0x23d8) and so does my dynamic linker.

I'm almost considering just binary editing the file to change the value used for the add, but I don't really like hacks like that.

Posted: **Thu May 21, 2009 5:29 am**

Code: Select all

     62c:	81 c3 aa 1d 00 00    	add    $0x1daa,%ebx

If you look closer, there are two bytes (opcode + R/M) before the displacement in this particular instruction. Could it be that these need to be accounted for? If you add 0x1DAA to 0x62E you actually get the correct GOT address.

Then again, I have no experience whatsoever with the ELF format, so the reasoning could be wrong.

Posted: **Thu May 21, 2009 5:37 am**

I think that is why GCC/ld is getting it wrong.
The location of the displacement means nothing. The first line gets the address of the next instruction and puts it into ebx, this then has 0x1daa added to it.

Looking at the dump of the object file, it appears that the operand to add is relocated during linking as a R_386_GOTPC with an addend of 0, and hence uses the address of the operand instead of the current IP.

Posted: **Fri May 22, 2009 8:49 am**

I found the bug. The toolchain I was using by default does not append leadning underscores but I was forcing it to, this meant that the GOT's symbol was different and hence was not treated properly.
I've disabled the "-fleading-underscore" flag in gcc and the problem was fixed.

OSDev.org

ELF Shared Library compilation troubles (badly aligned ptrs)

ELF Shared Library compilation troubles (badly aligned ptrs)

Re: ELF Shared Library compilation troubles (badly aligned ptrs)

Re: ELF Shared Library compilation troubles (badly aligned ptrs)

Re: ELF Shared Library compilation troubles (badly aligned ptrs)

Re: ELF Shared Library compilation troubles (badly aligned ptrs)

Solved: ELF Shared Library compilation troubles