Sysprogs forums › Forums › VisualGDB › Embedded thread and remote compilation
- This topic has 6 replies, 2 voices, and was last updated 8 years, 7 months ago by support.
-
AuthorPosts
-
April 26, 2016 at 12:37 #8101j.jemineParticipant
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?
April 26, 2016 at 12:54 #8102j.jemineParticipantMy gdb executable is also on Linux only
April 27, 2016 at 01:21 #8114supportKeymasterHi,
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.
April 27, 2016 at 09:03 #8120j.jemineParticipantHi,
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!
April 28, 2016 at 19:42 #8133supportKeymasterHi,
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.
April 29, 2016 at 14:32 #8135j.jemineParticipantHi,
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!
April 30, 2016 at 04:58 #8139supportKeymasterHi,
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.
-
AuthorPosts
- You must be logged in to reply to this topic.