About me

I'm Kevin Pouget, from Grenoble area, France. I received my PhD in Computer Science last February (2014) after defending my thesis on ''Programming-Model Centric Interactive Debugging for Multicore Embedded Systems'', in partnership with STMicroelectronics Crolles.

Now I'm post-doc/engineer at University Joseph Fourier, still on the Nanosim/CORSE, continuing my PhD work as part of the Nano2017 national research project (although debugging and embedded system has (nothing) to do with nano technologies!).

My research (and personal) interests deal with:

interactive debuggers (implementation, enhancement, usage, ...), in particular GDB,
live debugging and tracing tools in general (strace, ltrace, valgrind, pdb, ...)
design and implementation of runtime libraries (for GPU computing, multithreading, message passing, ...)
operating systems (Linux kernel) and programming language (C/asm, Python, ...) support for all of the above

I am also a free software enthusiast (i.e. avid user in my computing environment, promoter if it comes to the discussion, contributor if I need to add missing features to the tool I use) and maybe a software hacker (in ESR's sense): I love understanding how things (*nix tools, Linux, Python) are implemented, how they're supposed to be used, and how you can utilize them to do something completely different.

When I've got a bit of free time on a computer, I also do some Java/Web development (WebAlbums project) for managing my photo collection, and work on my online weather station report, although I can frankly say that I have PHP and Javascript programming languages! I also work on my VPS Linux server, the one hosting this very blog, where I learn about Apache administration and different web services. I also like playing/trying with multiple *nix/Linux distribution: Fedora on my work laptop, Archlinux on my desktop, Debian on the VPS, Raspbian on my rasberry and Mint on my wife's laptop!

And when I manage to let my computers alone, I like going into the surrounding mountains for a walk, a hike or a ski tour, almost never without a camera. I also train weekly in Judo and scuba diving (level 2* diver), and I love white water paddling in kayak, but barely have time for that any more.

Ijaz :

Hi John Doe,

Thank you so much for your nice blogs in debugging. I am here to query few things. Any help from your side will be highly appreciated.

As from this post:
https://blog.0x972.info/?d=2014/11/13/10/40/50-how-does-a-c-debugger-work-gdb-ptracex86-example

You mentioned that gdbserver can access jtag, if this is so why do we need to use openocd to establish communication between gdb and jtag? can't gdb directly communicate with JTAG? And how ptrace is applicable in case of jtag connected to let say any target device like corte-m microcontroller (no operating system on target device like microcontroller)?

Kevin :

@Ijaz :

hello,

`gdbserver` cannot access the JTAG, `gdbserver` does two things: 1/ connect to a process (like `gdb`) and 2/ send information on the network about this process, via [Remote Serial Protocol](https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html). That's it, it's a 'deported' head of GDB.

What `openocd` can do is to open a jtag connection with a processor (similar to step 1 above), and send its information to back to GDB (identical to step 2).

`Ptrace` is not involved in the case of system debugging (it's only for Linux processes debugging). Here, the on-board jtag controller does 'the same job' as `ptrace`: inspect and control the state of a running system (be it a full system or one isolated inside a user process)

ijaz :

@Kavin

Thanks for your nice reply. You indeed explain things very well. Allow me to explain what i understood from you answer.

1. GDB can only connect to processes via ptrace. As in case of JTAG, there is no process so openOCD opens a connection (a process) to processor.. Then GDB attaches to the process openOCD just created. (does it connects to openocd through ptrace?).

2. In case of system debugging, the onbaord controller acts like ptrace. forwarding signals to GDB. so no ptrace is required....
.
.
But if JTAG acts as ptrace and processor as child process, then why can't GDB directly communicate with processor via JTAG (ptrace here)?? why we need openOCD as all we need here is ptrace (jtag) and processor (child process)?

Thanks in advance

Kevin :

Hello,

> does it connects to openocd through ptrace?

no, it connect through the Serial Remote Protocol. OpenOCD provides *similar* information to what ptrace provide, but ptrace and OpenOCD don't retrieve the information the same way at all. Ptrace queries Linux internal structures, whereas OpenOCD and the JTAG controller probe electric pins inside the CPU !

another way to see it is if you try to debug Qemu with GDB, with `qemu -s`, and `(gdb) target remote :1234`. Here, Qemu will act similarly to OpenOCD/JTAG, and inform GDB about the state of the processor it is emulating, by querying its own internal structures

ijaz :

Thanks you so much @Kevin for the nice explanation.

John Doe :

Hi Kevin,

Sometimes, in a multi-threaded application, I have encountered No symbols "" in current context. Is it that current thread doesn't have the required symbols/reference?

Found few blogs to this effect but didn't find proper answer.

Also, changing compilation flags for binary is not an option for me.

Could you please explain more on this?

Kevin :

hello,

in what context do you get this message ?

No symbols "abc" in current context

this means that you (or GDB) are trying to access symbol "abc", for instance with a print, or a call:

(gdb) p start
No symbol "start" in current context.

I don't understand how the symbol name can be empty. Either it's a bug somewhere in GDB, or you took it out?