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

Sunny <shiladitya.biswas@gmail.com> wrote:
 
> 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.

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 :

http://sources.redhat.com/gdb/current/onlinedocs/gdb_18.html#SEC165

Enjoy,

_Ico

-- 
:wq
^X^Cy^K^X^C^C^C^C

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

Sunny <shiladitya.biswas@gmail.com> wrote:

>        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, 

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.

Sunny wrote:

>        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

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.

In article <1137745092.243486.3920@f14g2000cwb.googlegroups.com>,
Sunny <shiladitya.biswas@gmail.com> wrote:
>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.

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:
   http://docs.freebsd.org/info/gdb/gdb.info.Remote.html
   http://billgatliff.com/drupal/node/26
   http://sources.redhat.com/gdb/current/onlinedocs/gdb_18.html

-- 
   Wim Lewis <wiml@hhhh.org>, Seattle, WA, USA. PGP keyID 27F772C1

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