Subject: glibc2

From: Stefan Hanske <[email-masked]>
Date: Thu, 30 Jul 1998 15:19:35 +0200 (METDST)

Hi,

I've tried all the hints from the mailing list... (changing binfmt_elf.c 
to load ld-linux.so at 0x1000 higher than usual and changing 
include/asm/elf.h - ELF_EXEC_PAGESIZE to 0x1000 in all combinations; 
compiling everything  again with -mapcs-32 -mcpu=arm7, that means 
libgcc.a, glibc-2.0.94, test program), and nothing's changed except the 
address of the exception. The kernel says:

small: memory violation ... pc=0x00004010, lr=0x400033f8, bad address 
0x00004010 (code 3).

So this should be a problem with the dynamic linker. I then renamed 
ld-linux.so.2, the binary complained about not finding it. Good...

The shared library should be loaded at 0x40000000 (the link register 
should point to the library somewhere). After restoring ld-linux.so.2 I 
renamed the libc.so.6 (a link) and libc-2.0.94 (the binary) and got the 
SEGV again. This leads to the dynamic linker as cause of the trouble 
during execution.
(I wonder what ld-linux has to do at 0x40000000 *before* loading the 
shared library. Is something getting mapped there after loading the 
binary and the linker???)

However, calling ld-linux.so.2 from the command line with --list works. It 
tells the following load addresses:
	libc.so.6 -> 0x40000000
	ld-linux.so.2 -> 0x1000.
Calling ld-linux.so.2 with only an executable as argument fails again, 
but at different addresses.

( I'm using gcc-2.8.1, binutils-2.9.1.0.6 & glibc-2.0.94 )

----------------------------------------------------------
|mailto: Stefan Hanske ([email-masked] |
|WWW : http://www.rzuser.uni-heidelberg.de/~shanske      |
|phone: I'm not silly                                    |
|--------------------------------------------------------|
| And don't forget to remember what you remembered not   |
| to forget to remember...				 |
----------------------------------------------------------

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Thu, 30 Jul 1998 15:11:10 +0100

>but at different addresses.

Beware that ld-linux.so.2 gets loaded differently depending on whether it's 
being run implicitly as the interpreter, or explicitly because you named it on 
the command line.  So when you use --list to get the load addresses, you must 
then run ld-linux.so.2 giving it your program as an argument in order to get a 
matching crash.

>(changing binfmt_elf.c to load ld-linux.so at 0x1000 higher than usual

I'm not convinced this is necessary, actually.

If you have no luck then feel free to mail me your offending binary and I'll 
try and figure out what the problem is.  But I'm going to be on holiday all 
next week and I probably won't get a chance to look at it until after I get 
back.

I _will_ try and make some patches for glibc 2.0.95 before I go, so people can 
experiment with the current state of the art.

p.

---

From: Stefan Hanske <[email-masked]>
Date: Thu, 30 Jul 1998 16:34:04 +0200 (METDST)

> then run ld-linux.so.2 giving it your program as an argument in order to get a 

Sure.

> I'm not convinced this is necessary, actually.

I gave it a try.

Btw., can anyone tell me how to interprete the code numbers in

small: memory violation ... bad address 0x00004010 (code [123])?

Thanx

---

From: Philip Blundell <[email-masked]>
Date: Thu, 30 Jul 1998 16:32:50 +0100

>small: memory violation ... bad address 0x00004010 (code [123])?

I think it's in fault-armv.c.  From memory, bit 0 is `user' and should always 
be set; bit 1 is whether it was a read or a write.

p.