> 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.
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
