Subject: ld.so-1.9.x for mips

From: Michael Shmulevich <[email-masked]>
Date: Mon, 23 Apr 2001 18:40:58 +0300

Hi,

I have seen a compiled version of ld.so-1.9.11_mips on ftp.rfc882.com 
site.I am searching for its sources.

Where can I find them, please?

Thanks.

Sincerely yours,
Michael Shmulevich
______________________________________
Software Developer
Jungo - R&D
email: [email-masked]
web: http://www.jungo.com
Phone: 1-877-514-0537(USA)  +972-9-8859365(Worldwide) ext. 233
Fax:   1-877-514-0538(USA)  +972-9-8859366(Worldwide)

---

From: Fabrice Bellard <[email-masked]>
Date: Mon, 23 Apr 2001 18:31:20 +0200 (MEST)

Hi!

Did someone make a patch so that gdb can do single step on mips-linux ? If
not, do you prefer a patch to gdb or a patch in the kernel to support the
PTRACE_SINGLESTEP command ?

Fabrice.

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 23 Apr 2001 17:03:02 -0300

> Where can I find them, please?

While this package surprisingly compiles for MIPS it shouldn't be used
ever for anything on Linux/MIPS as we don't have libc4 / libc 5.  The
equivalent for libc6 aka glibc 2 is part of glibc.

Florian, can you remove this package from Debian/MIPS?

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 23 Apr 2001 17:04:25 -0300

> PTRACE_SINGLESTEP command ?

Last I used GDB single stepping has been working fine for me, so I wonder
what is broken?

  Ralf

---

From: Michael Shmulevich <[email-masked]>
Date: Tue, 24 Apr 2001 10:25:59 +0300

Ralf,

> ever for anything on Linux/MIPS as we don't have libc4 / libc 5. 

You're right about Libc5, but I need it for uClibc. Besides it 
surprisingly does not compile for MIPS, as it misses many parts of MIPS 
assembly code, usually found under sysdep part of ld.so.

> The equivalent for libc6 aka glibc 2 is part of glibc.

The whole idea behind uClibc was to get rid of that huge chunk of 
memory-wasting package, and I do not mean to use any part of it.
Unless you can tell me how ld.so of glibc can be compiled standalone :-)

> Florian, can you remove this package from Debian/MIPS?

Florian, please, if you still have sources, can you tell me where they are?

Sincerely yours,
Michael Shmulevich

---

From: Ryan Murray <[email-masked]>
Date: Tue, 24 Apr 2001 01:24:09 -0700

> Florian, please, if you still have sources, can you tell me where they are?

the binary package has already been removed from Debian for almost
every arch (including mips).  You can find the latest source on any
debian mirror, in the pool/main/l/ld.so directory.

-- 
Ryan Murray, Debian Developer ([email-masked], [email-masked])
The opinions expressed here are my own.

---

From: Michael Shmulevich <[email-masked]>
Date: Tue, 24 Apr 2001 11:46:06 +0300

Ryan,

> debian mirror, in the pool/main/l/ld.so directory.

The ld.so-1.9.11-15 that is on debian FTP site does not have any support 
for mips ELF. This is the reason why I was asking Florian, how did he 
manage to compile it for MIPS.

Sincerely yours,
Michael Shmulevich

---

From: Ian Soanes <[email-masked]>
Date: Tue, 24 Apr 2001 10:04:48 +0100

> Last I used GDB single stepping has been working fine for me, so I wonder

Hi Fabrice,

This may not be totally relevant, but I'm currently trying to get
gdbserver working on a RC32334 IDT board. I've been having some issues
with single stepping, but am making a bit of progress.

1/ I started with a mips gdbserver port kindly supplied by Martin
Rivers. It mostly works well but had some problems single stepping
through conditional branches (the problem may have been due to a
different target than Martin was using, or me... I am kind of new to
this :)

2/ Previously I've had some luck single stepping kernel and module code
with the kernel gdbstub (arch/mips/kernel/gdb-stub.c), so I ported the
relevant single stepping code into gdbserver. The results were much
better. The only thing that seems to be wrong now is stepping over
function calls isn't working quite right. I can step into functions OK
though.

If you're interested I'll let you know how I get on over the next few
days. If not, I won't be offended :)

Best regards,
Ian

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 24 Apr 2001 12:49:46 +0200

> manage to compile it for MIPS.

Its the ld.so package from potato which itself does not contain
the ld.so but "ldconfig". This was a misnaming for a while in debian.

Flo
-- 
Florian Lohoff                  [email-masked]             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 24 Apr 2001 12:48:28 +0200

> Where can I find them, please?

Its ftp.rfc822.org - Any yes there is one in the debian packages
i and Ryan Murray built on all debian ftp server for mips and mipsel.

For non-debianers - You can extract the .deb by using "ar x <file.deb>"
and then you get 2 tar.gz one data which contains the files and
the control.tar.gz which contains the package informations.

Flo

---

From: Michael Shmulevich <[email-masked]>
Date: Tue, 24 Apr 2001 13:59:47 +0300

> the ld.so but "ldconfig". This was a misnaming for a while in debian.

 From this I conclude: no-one ever tried to check if ld.so works for 
mips ELF. Is it so?

Thanks.

Sincerely yours,
Michael Shmulevich

---

From: Ian Soanes <[email-masked]>
Date: Tue, 24 Apr 2001 13:45:58 +0100

> > Last I used GDB single stepping has been working fine for me, so I wonder

<snip>

> function calls isn't working quite right. I can step into functions OK

<snip>

Hi,

Sorry, I made a mistake (forgetting to clear a breakpoint) when I ported
the stub single step code into gdbserver. As far as I can tell, single
stepping works fine now.

BTW, should I be worried about MIPS16 instructions? (single step
breakpoints are always placed on a 4 byte increment) ...or is that a
silly question?

Best regards,
Ian

---

From: Martin Rivers <[email-masked]>
Date: Tue, 24 Apr 2001 09:17:01 -0400

Ian,

Hmmm, this was the most problematic portion of the code.  I remember that I
fought the kernel support in what it wanted to report as the epc (pc).  The
module of interest (at least for 2.4 linux) is arch/mips/kernel/traps.c and the
function do_bp().  In an earlier version of the kernel (if I remember right), it
would call a routine to "fix up" the pc.  This lead to the pc being backed up by
4 bytes which confused gdb.  Anyway, you want to make sure that the kernel is
reporting the pc of the bpt instruction with your version of linux.

Also, in regards to your subsequent email, you are correct in reporting that
mips16 is not supported (at least by my code).  We never use it as we support
various models of the cpu that don't support that instruction set.

martin

---

From: Alan Cox <[email-masked]>
Date: Tue, 24 Apr 2001 14:43:51 +0100 (BST)

> Unless you can tell me how ld.so of glibc can be compiled standalone :-)

You might want to look at newlib instead. That has mips support but not afaik
MIPS linux syscall bindings yet. Its used for things like eCos

---

From: Fabrice Bellard <[email-masked]>
Date: Tue, 24 Apr 2001 15:49:19 +0200 (MEST)

Hi!

I was speaking about gdb support in user mode, not the gdb stub in the
kernel. Does someone use gdb to debug user space programs on linux-mips ?
Maybe someone added the PTRACE_SINGLESTEP command of the ptrace syscall in
recent mips kernel, but I do not have it in my kernel (linux-2.4.0 on sgi
site).

I patched gdb 5.0 so that single step on mips is correctly supported in
user mode. I also modified gdbserver so that it works when you debug mips
code in user mode.

Fabrice.

---

From: Ian Soanes <[email-masked]>
Date: Tue, 24 Apr 2001 15:07:38 +0100

<snip>

Hi Fabrice,

I know you meant user mode... it's just that I had some success adapting
the kernel stub code for use in Martin's gdbserver for debugging user
mode code. I guess now we have 2 gdbservers :-)

Best regards,
Ian

---

From: Martin Rivers <[email-masked]>
Date: Tue, 24 Apr 2001 10:38:45 -0400

Ian,

I'm confused.  The gdbserver stuff I gave you was all directed at user mode
stuff too.  I don't do any kernel debug with gdbserver.

martin

---

From: Ian Soanes <[email-masked]>
Date: Tue, 24 Apr 2001 15:56:58 +0100

Martin,

I seem to have confused everyone (including myself)...

I'm also talking about user mode... my references to the kernel stub
code only refer to the single_step() function... I borrowed and adapted
it for use in gdbserver... for user mode.

Sorry, I'll go and stand in the corner for a while...
Ian

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 24 Apr 2001 12:02:24 -0300

>  From this I conclude: no-one ever tried to check if ld.so works for 

I definately won't work.

  Ralf

---

From: Michael Shmulevich <[email-masked]>
Date: Wed, 25 Apr 2001 10:42:32 +0300

>>  From this I conclude: no-one ever tried to check if ld.so works for 

Well, I maybe overoptimistic about it, but ld.so consist of 80% C-code 
with some intrusions of #define and __asm__. I see no reason why such a 
definitive "no" should be here :-)

If someone can tell me in which register (or where) the GOT should be 
upon loading the executable and stuff like relocation types (I guess I 
can find most of them in binutils' code) then it's all fixed. I don't 
think kernels are *that* different for sparc and mips.