GDB internal question

Hi, I am new to this group. So please excuse me if my question is not proper for this group.

I want to retarget gdb to debug an embedded Nios II processor. This processor is inside an Altera Stratix II FPGA which supports JTAG Boundary scan.

I want to know, how does a host based debugger actually works, eg on Linux . So when I run some program ( gdb ./a.out) and then send a command to display a variable, how is gdb able to show me that value. Does it run some code on the CPU, which simply reads the value at that memory address and dumps it at some place and then gdb process can show me the value. Or does gdb , which is separate process, fetch the value itself. So when I hit a breakpoint in my code, what is the process which is running on the CPU, is it gdb or the a.out process ? I want to know how gdb process can gain control of another process in order to debug it.

My aim is to retarget gdb to the NiosII embedded processor. Thanks

Reply to
Sunny
Loading thread data ...

Yes, that's about it. gdb uses a well-defined protocol to communicate with a small piece of software on the CPU, which is called a 'stub'. If it needs to set a breakpoint, get register or memory contents, etc, it sends a message to the stub, which will handle the command and return the results. By default, gdb is capable of talking to a stub over TCP or any device like /dev/ttyS0. If you need a different protocol, it is often easy to write a simple 'gateway' which connects over TCP.

Take a look at the gdb documentation for more info about the stub and the protocol :

formatting link

Enjoy,

_Ico

--
:wq
^X^Cy^K^X^C^C^C^C
Reply to
Ico

Thanks for the info.

So that means gdb memory requests are sent to stub and then stub really gets the memory contents of that address. But if there is virtual memory, then gdb will only be sending the logical addresss to the stub. How does the stub figure out the physical address for the process a.out ? The stub will have to access the page table entries of process a.out. My second question is, is stub a part of gdb process or a.out process ? Thanks

Reply to
Sunny

There almost certainly isn't. Not in the target system anyway. Try to keep your mental image of this clear. You have *two* CPUs, two completely separate operating systems, separate RAM and everything. The only connection between the two is a communication channel between GDB (running on your Linux host) and the target.

If the debug goes via JTAG, there may not be any stub involved. JTAG can work in different ways, but generally, it means GDB can stop the target CPU (or most of it) dead in its tracks, and read/write whatever it wants to from inside it, and then allow it to continue. It can still mean that for more involved jobs, like talking to other devices connected to the CPU, or searching for some data, it's more efficient to run a small program in the target CPU instead of doing it by hand directly through JTAG.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Things get very complicated if you are running multiple contexts. Running gdb on an executable inside a general-purpose OS makes the application being debugged a subprocess of gdb itself - so they run in the same context.

There's some threading support in gdb, but I don't completely understand how it works. In embedded environments, the easiest thing to do (if possible) is avoid using different contexts.

Note: Requests for memory from the gdb stub go through MMU like any other request. So for example if your MMU maps logical address

0x00100000 to physical address 0xff000000, this translation will be honored if you use gdb to inspect location 0x00100000.
Reply to
larwe

If I'm debugging a process on the same machine the deubgger is running on, gdb asks the OS to read some part of the target task's memory space. On Linux this is done with ptrace(2), I think.

If the process is on a different machine (e.g., an embedded cpu), then gdb speaks a "remote debugger" protocol to the remote machine, and there's code on that machine which can read out sme part of the target task's address space. (If there's no virtual memory on the target machine, then it's really simple; if there is virtual memory, then the remote stub has to deal with that somehow.) The remote debugger protocol has commands like "read out memory address FOO" or "set cpu register 12 to BAR".

Here are some web pages which might help explain:

formatting link
formatting link
formatting link

--
   Wim Lewis , Seattle, WA, USA. PGP keyID 27F772C1
Reply to
Wim Lewis

Thanks Lewis That was really helpful. In fact I have used a remote s/w debugger frontend called Codelab which rides on top of a JTAG based debugger from a company called FirstSilicon II. I think it is a some kind of rom monitor program. But I want to integrate the target processor, Nios 2 on Altera's Stratix II chip, with gdb.

I want to know how much effort/pain that it takes. I know I will need to write a debugging agent to begin with. Is sparc-stub.c an example of such an agent ? If you have some idea or experience please share it with me. :-) Thanks

Reply to
Sunny

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.