[lldb-dev] C++ API: Passing information from debuggee to debugger

[Duane Ellis]

> The problem is that there are complications if the target is stripped off symbols,

SIMPLE - see my reply from a few minutes ago.

If you write your “DEBUGGER_CALL” function- you could decorate it with some signature pattern.

For example, in assembly language:

	.ascii	“DEBUGGER_CALL_FUNCTION_START===>”
DEBUGGER_CALL:
	mov		r0,-1
	return
	nop
	nop
	nop
	nop
	nop
	.ascii	“<====DEBUGGER_CALL_FUNCTION_END”

Then search the target text segment, you should look for and find exactly ONE instance of the strings.
Or maybe you will find others in various shared libraries that might be loaded
Again, the solution is simple - Search the text segment for your string pattern


>  I probably can work around by still sending a signal

DO NOT use signals - Signals do not work on targets that do not have an operating system

Another reason is you want to be able to insert these types of things in main line code that gets executed a reasonable number of times, you don’t want SIGNALS going off, they delay things

Instead, you have a single instance of a couple instructions, in a  more modern computer these few opcodes live in the CPU cache and become almost ZERO overhead

Thus you can leave them in … and not really effect overall system performance meaningfully

> Another vague worry is if overzealous compiler would optimize it out,

Hence you write this in assembly language, you also must worry about optimizing linkers but you can probably control that more easily.

You supply a *LIBRARY* (binary) that your users would link against, that library contains exactly that one function above nothing else
 
> I do not fully understand why we need mutex here... Each thread allocates data in its own memory (either allocated or on stack) and when it breaks each thread has its own local pointer (either on stack or in register). I.e. it seems this can be made lock-free.

YES in the example I give, the “DEBUGGER_CALL” data structure would most likely live on the current threads CPU STACK  Hence it is thread safe

**END**

-Duane.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150602/688ee27e/attachment.html>