• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 1282 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Error when using remote GDB on AM389x

Tyson
Prodigy 130 points
Other Parts Discussed in Thread: AM3894

I get the following error message when executing remote GDB commands:

 

(gdb) break main

Remote 'g' packet reply is too long: 00000000381f87be000000000000000000000000000000000000000000000000000000000000000000000

0000000000000000000501e87be00000000b0070040100000000000000000000000000000000000000000000000000000000000000000000

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

00000000000

 

Some background information:

I'm trying to debug a simple "hello world" program on an EVM running an AM389x (Arm Cortex A-8).  My host machine is a x86 box running Ubuntu 10.04.  The distro that I received did not include gdb or gdbserver so I had to build it.  I built gdb and gdbserver using the gdb-7.2 source tree.  The error that I'm experiencing could easily be introduced in this step.  Here is how I build the gdb and gdbserver:

1. Download gdb-7.2 

2. Untar the sources in a directory called gdb-7.2

3. Make a gdb_client directory for the gdb program.  gdb-7.2/gdb_client

4. Make sure the CC environment variable is cleared (or set to the gcc for the Linux host machine).  This will make sure gdb is built with the correct compiler in step 5.

5. CD into gdb_client and run the configure command: ../configure --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi

6. run 'make' on the make file that was created in step 5 (this will build gdb)

7. Back in the main GDB directory (gdb-7.2), create a gdb_server directory.  gdb-7.2/gdb_server

8. Make sure the CC environment variable is set to point to the gcc for the ARM tool chain.  In my case CC=/home/foo/CodeSourcery/arm-2009q1/bin/arm-none-linux-gnueabi-gcc.  This will make sure the gdbserver is built with the arm toolchain.

9. CD into gdb_server and run the configure command for the gdbserver: ../gdb/gdbserver/configure --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi

10. Run 'make' on the make file that was created in step 9 (this will build gdbserver)

Once this is done I moved the gdbserver to my target machine's /bin folder.  Next I built a debug version of my "Hello World" program using the -g option.  This program was compiled using the arm cross-compiler used in step 8 above.  I moved the debug "Hello World" program over to my target machine and verified it worked.  After that I ran the gdbserver with the following command: gdbserver x.x.x.x:10000 ./HelloWorld.out

At this point everything looks good on the target side.  I get the following message on my console:

Process HelloWorld.out created; PID = 848

Listening on port 10000

Now, on the host side I execute gdb with my HelloWorld debug program (targeted for the ARM) using the following command:  ./gdb ./HelloWorld.out

Here is the output from this command:

GNU gdb (GDB) 7.2

Copyright (C) 2010 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...

Reading symbols from /home/cognoid/GDB/gdb-7.2/arm_linux_gnu_target_client/gdb/a.out...done.

Setting up the environment for debugging gdb.

Function "internal_error" not defined.

Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]

Function "info_command" not defined.

Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]

.gdbinit:8: Error in sourced command file:

Argument required (one or more breakpoint numbers).

Then I connect to the remote host by the following
(gdb) target remote x.x.x.x:10000
Remote debugging using x.x.x.x:10000
warning: Can not parse XML target description; XML support was disabled at compile time
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
0x400007b0 in ?? ()
(gdb)
On the target it looks like there has been a successful connection because I see the following message: Remote debugging from host y.y.y.y
Up to this point all looks fine until you try and execute any commands.  Most command that I try to execute will result in the message at the top of this post (Remote 'g' packet reply is too long).  I also get this message at times: During symbol reading, DW_AT_name missing from DW_TAG_base_type.  I am able to send the 'kill' command and see that the gdbserver releases the HelloWorld.out program.  I've done some searching and can't seem to find any information that will fix this problem.  All suggestions are welcome.  Thanks in advance.