Re: [OpenOCD-user] Address translation failure while using openocd/gdb load command

[Duane E. <op...@du...>]

sholla>> [paraphrased: i can step through the linux kernel, that works]

sholla>> [paraphrased: Now trying to step through a “hello world” app and it does not work - please help]

> Reading symbols from /mnt/builds/rootfs/lib/ld-linux.so.3...(no debugging symbols found)...done.

That line tells me what is wrong.

Your Hello world application is a “LINUX” application, I know this because GDB is reading the symbol table from the ld-linux.so library
this library is used by a *LINUX* application, not a bare metal application.

OpenOCD is not (currently) the correct tool for this.
Instead what you want to use is a “linux gdb server” 
(I say currently, because there are some commercial JTAG debuggers that can debug both the Linux kernel & Apps at the same time, OpenOCD does not have this feature)

In other words, you have an Linux APP your target needs to boot Linux - your APP requires Linux to run.
you need to get to the SHELL prompt of your target Linux machine, 
you then execute the GDB server command on your target linux box and launch your hello world app.

to debug your app your target Linux board will need some means that the GDB server can use to talk to the GDB debugger
the most common (99.9%) of the time this means you need a TCP/IP connection between your host Linux machine and your target board, a serial port is not sufficent.

Your target Linux distribution should have or come with a GDB server you should use that instead.

=====

So what’s going on here?
	OpenOCD is a bare metal debugger - by bare metal, it means there is no operating system controlling the target.
	There is no operating system that controls ‘single step’ - or captures the CPU registers after each instruction step.
	Instead, OpenOC does this - via the JTAG (or SWD) interface

	OpenOCD emulates a GDB server and speaks the GDB server protocol.

When you want to “remote debug” a Linux application (which is what you seem to have) you run an application (typically called GDB SERVER)
	The GDBSERVER on the target linux platform uses the “man 2 ptrace” Linux interface
	See:  http://linux.die.net/man/2/ptrace

What the LINUX GDB server does - is this: 
	It opens a socket connection and waits, you connect to the socket via GDB’s remote command.
	Your debugger (GDB) sends various commands - for example SINGLE STEP over the TCP/IP connection
	The GDB server uses the PTRACE_SINGLESTEP  call to perform an instruction single step.
	The Linux operating system then manages the single step process.
	
	There are others, for example GDB can send a “read memory” packet, or a “write memory packet”
	The GDB server converts the packet into various PTRACE calls.

In contrast - the OPENOCD GDB Server for ARM7M (i.e.: Cortex M3) - does this:
	Reference: ARM Document: ARM DDI 0403D, Section C1.5.1
	In short: There is a hardware register called DHSCR (Debug Halting Status And Control Register)
	In that register there is a bit that controls single stepping.

	OpenOCD uses JTAG (or SWD) and the ARM DAP to read/write these bits in the DHCR register.
	In the end, the CPU performs the single step.

	Likewise, OpenOCD converts the Read/Write memory packets into various JTAG/SWD operations to read/write target memory

In summary:
	In the OpenOCD GDB SERVER case, there is no operating system running on top of the “bare metal” of the chip
	In contrast, the Linux case there is an operating system between the metal and the app being debugged.

	It is quite a different process

=======

If what you want is a stand alone “hello world” application that does not run on top of Linux, then you are linking your program and writing your program the wrong way.

A bare metal program - has a body of code called “the startup code” which needs to:
	1) Configure the hardware at hard reset -
		This includes setting the CPU stack pointer
		Turning on the clocks, programing the PLLs
		Initializing the DDR memory (if present)
	2) zero-ing memory at startup
	3) Initialzing global memory that is non-zero at startup
	4) And many other things …

The last thing the startup code does is jump to your applications: “main()” function

I’m only giving a very high level overview here, there is much more to this process, including the way you link your application and the libraries your application uses.

=======

-Duane.