Embedded thread and remote compilation

[j.jemine]

The toolchain I am using for my embedded project works under Linux only.

I’ve made my own IVirtualThreadProvider as described here: http://visualgdb.com/tutorials/arm/threads/

I’d like to compile on my distant Linux machine (like with a Custom project) while having embedded threads (like with an Embedded project).

Is it currently possible?

[j.jemine]

My gdb executable is also on Linux only

[support]

Hi,

Currently it is only supported with the Embedded projects that are built locally.Is there any reason you cannot setup a locally built project for your target?

We could also add experimental support for virtual threads to Linux projects if this helps.

[j.jemine]

Hi,

Is there any reason you cannot setup a locally built project for your target?

We’re working with a space qualified RTEMS toolchain, re-compiling it for Windows would break the qualification. We can only work with the provided qualified Linux binaries.

 

We could also add experimental support for virtual threads to Linux projects if this helps.

Yes, that would be perfect!

[support]

Hi,

This makes sense. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.1.4.685.msi

It adds support for the EmbeddedThreadPlugin node in the Linux project properties similar to the embedded ones. Let us know if you encounter any problems with it.

[j.jemine]

Hi,

It’s almost working:

• My virtual threads are correctly enumerated in the ‘Threads’ window
• The displayed callstack of each thread is the callstack of the thread that reached the breakpoint (same story for the program counter).
• It feels slow, breaking into the code takes significantly more time, but I think it’s not VisualGDB’s fault: the interactions with the GDB stub are slow.

I’m going to debug my GetSavedRegisters() method to be sure that I’m returning correct values.

I’m guessing that you’re giving the register values to GDB to produce a callstack ? Could you give me a little more details about this so I can try to reproduce the process manually ?

I think that I probably have a mismatch between the name of the registers that I give and what GDB expects.

 

Another question:

Since my GDB stub is slow, I’d like to avoid calling IGlobalExpressionEvaluator.EvaluateIntegralExpression too often.

Are my VirtualThread re-used between debug breaks ? Or is IVirtualThreadProvider.GetVirtualThreads called everytime that I break into the code ? (in which case I could use a single lazy evaluation for each thread)

 

Thanks for your time!

[support]

Hi,

If this helps, VisualGDB handles the virtual threads as follows:

• It queries your interface for the registers of each thread
• Then it forces gdb to set current register values to the ones reported by the stub
• Then it asks gdb to list the stack frames

You can diagnose the problem by checking the gdb log to see if VisualGDB sets the registers to the correct values before it asks gdb to list the frames.

GetVirtualThread() is called each time a break happens because VisualGDB does not know which of the threads are still alive.

You might be able to improve the performance if you run your gdb stub remotely, but use Windows gdb from one of our toolchains. It won’t affect the code you build (hence won’t break your certification), but will significantly reduce the latencies for gdb commands.

[Author]

Posts