RE: ptrace Problem

RE: ptrace Problem

[Jean-Denis Boyer]

Kent,

> It lists a series of numbers ranging from 2.0 to 2.2.2.

Actually, there are obviously many ways to know the glibc version. When running on the embedded platform, you can issue a:
  ldd --version
But my "preferred" way is by looking at the soft link "libc.so.6" and confirm it matches on both the embedded system being debugged, and the system where gdb runs.

An idea: Does running native gdb (on the embedded system) debug correctly?

I'm currently using the following setup, which runs correctly both natively and in cross-debugging:
  MPC8250 (603e core, Hip4)
  Kernel 2.4.21
  binutils 2.13.90.0.18 (from ftp://ftp.kernel.org)
  gcc 3.2.3
  glibc 2.3.2 (with pthread)
  gdb 5.3
(Note that everything here was cross-compiled)

This version of binutils is the one recommended for powerpc-linux
(see http://gcc.gnu.org/install/specific.html#powerpc-*-linux-gnu*)

Regards,
--------------------------------------------
 Jean-Denis Boyer, Eng.
 Software Designer
 M5T Centre d'Excellence en Télécom Inc.
 4283 Garlock Street
 Sherbrooke (Québec)
 J1L 2C8  CANADA
 (819)829-3972 x241
--------------------------------------------

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ptrace Problem

[Kent Borg]

On Wed, Jul 16, 2003 at 12:37:51PM +0200, Kenneth Johansson wrote:
>
> On Tue, 2003-07-15 at 23:49, Kent Borg wrote:
>
> > Looking at likely source tarballs we have sitting around it seems very
> > likely that binutils were built from 2.13.2.1, and glibc 2.3.2.  (How
> > can I be sure?)
>
> binutils binaries usually respond with the version when given -V on the
> command line.

Oh!  I thought that was a version of an individual component, but
lordy, nm and objdump both give the same number and it matches the tar
I had guessed we had used.

> libc can be checked with objdump -x and checking the Version
> definitions.

It lists a series of numbers ranging from 2.0 to 2.2.2.

> This should not be a problem gdb dose all the work using ptrace.

Indeed, gdb didn't drag me down into any libraries.

> Regarding your gdb problems have you tried with a kernel without bdi2000
> support in the kernel.

No, but I will now.


Thanks,

-kb

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ptrace Problem

[Kenneth Johansson]

On Tue, 2003-07-15 at 23:49, Kent Borg wrote:

> Looking at likely source tarballs we have sitting around it seems very
> likely that binutils were built from 2.13.2.1, and glibc 2.3.2.  (How
> can I be sure?)

binutils binaries usually respond with the version when given -V on the
command line.

libc can be checked with objdump -x and checking the Version
definitions.

This should not be a problem gdb dose all the work using ptrace.


Regarding your gdb problems have you tried with a kernel without bdi2000
support in the kernel.


--
Kenneth Johansson
Ericsson AB                       Tel: +46 8 719 70 20
Tellusborgsvägen  90              Fax: +46 8 719 29 45
126 25 Stockholm                  ken@switchboard.ericsson.se


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ptrace Problem

[Kent Borg]

On Tue, Jul 15, 2003 at 12:30:26PM -0400, Jean-Denis Boyer wrote:

> Which chip is it?

An unreleased 603-ish core with other stuff added.

> Is it correctly recognized by the kernel
> (arch/ppc/kernel/cputable.c)?

I long ago added an entry to cputable.c, and am using it.  I'll look
at those specifics again though.  Good tip.  ...and I just made a
change that might help...  and that didn't help

> This is a silly question, but, did you try to unplug the BDI-2000
> before running gdbserver? Just in case it stops on some exceptions...

If I understood correctly: use Abatron to download my code, make sure
things are running, them pull that power, and things still run.
Attempt to do gdb/gdbserver and it malfunctions in the same way--or at
least I think so, I don't have an Abatron hooked up.

> Do you use a somewhat recent version of glibc, and was it built
> against a somewhat recent version of kernel? Can you also tell us
> the version of binutils and gcc ? Not all the combinations are
> reliable ;-)

Looking at likely source tarballs we have sitting around it seems very
likely that binutils were built from 2.13.2.1, and glibc 2.3.2.  (How
can I be sure?)

gcc reports 3.2.2.

Are those a compatible set?


Thanks,

-kb

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: ptrace Problem

[Jean-Denis Boyer]

Kent, here are some ideas...

> The kernel is 2.4.21-rc1 with stuff done to it to support some
> hardware that is under development (the chip has a 603-style core).

Which chip is it?  Is it correctly recognized by the kernel (arch/ppc/kernel/cputable.c)? If not, it will choose a "Generic PPC", which might not have the correct attributes (for example, if it is a 8270, I think it is currently not recognized; the kernel would boot but the MMU would behave badly).

> Once this happens my Abatron BDI-2000 is somehow hosed and can no
> longer write to memory.  My next download takes all the time I would
> expect, but the results are all 0x0 unless I first powercycle the
> Abatron.

This is a silly question, but, did you try to unplug the BDI-2000 before running gdbserver? Just in case it stops on some exceptions...

> I have tried changing from our previous gdb and gdbserver
> to the Denx versions with same results.

Do you use a somewhat recent version of glibc, and was it built against a somewhat recent version of kernel? Can you also tell us the version of binutils and gcc ? Not all the combinations are reliable ;-)

Regards,
--------------------------------------------
 Jean-Denis Boyer, Eng.
 Software Designer
 M5T Centre d'Excellence en Télécom Inc.
 4283 Garlock Street
 Sherbrooke (Québec)
 J1L 2C8  CANADA
 (819)829-3972 x241
--------------------------------------------

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

ptrace Problem

[Kent Borg]

I am trying to get ptrace() working correctly so I can use gdbserver
so we can debug with more power than printf()'s.

The kernel is 2.4.21-rc1 with stuff done to it to support some
hardware that is under development (the chip has a 603-style core).

I can fire up gdbserver, I can attach to it with a gdb on my host.  I
can watch the little ptrace transactions go by and (after eliminating
some false leads) they all do seem to be doing sensible things.  But
when I try an "si", everything seems OK upto the _switch at which
point the kernel SIGSTOPs on a 0x0 instruction at the first
instruction of my application (or is it the second instruction?--I am
not sure, the address complained about is first+4, maybe one worked).

Once this happens my Abatron BDI-2000 is somehow hosed and can no
longer write to memory.  My next download takes all the time I would
expect, but the results are all 0x0 unless I first powercycle the
Abatron.

The kernel seems to otherwise be working quite well.  As this is new
hardware, I cannot state that it is certainly working correctly.

Obviously I suspect that something is wrong with how some memory
management data structure is set up when the ptrace calls are being
made by gdbserver, but I am not smart enough to have a clear idea of
what to look for.  (I don't want to get lost in walking page tables
and tracing TBL faulting and whatnot for another week--not if I don't
have to.)  I have tried changing from our previous gdb and gdbserver
to the Denx versions with same results.

Suggestions?


Thanks,

-kb

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/