[Lldb-commits] [Patch][Please Review] Add support for GNU indirect functions

[Greg Clayton]

I believe that this patch isn't what we want, and let me explain why, and you let me know if I am missing something:

On MacOSX, any PLT entry symbols are marked with a special type of lldb::eSymbolTypeTrampoline, not as lldb::eSymbolTypeCode like other code symbols that are actually functions. This allows us to always ignore these symbols and also keeps the expression parser from finding these symbols when doing lookups by name. When the expression parser does try and lookup say "strcat", it finds the actual one and only copy in libSystem.B.dylib (libc.so on linux?) and never needs to do any resolving. Registering these symbols as eSymbolTypeTrampoline also allows our stepping code to do something special when you step into the PLT jump table code. 

So if we teach the ELF symbol table parser to mark all PLT entries as eSymbolTypeTrampoline, this might solve the problem correctly.

Does this sound plausible? Or are the indirect functions something different?

Greg 


On Jan 18, 2013, at 2:33 PM, "Kopec, Matt" <matt.kopec at intel.com> wrote:

> Hi all,
> 
> This patch allows indirect functions to work on Linux when evaluating expressions. I'm not sure if this is a feature supported on Mac OS X.
> 
> This is needed to support some library functions such as strcat and strlen when used in an expression. If one of these functions are used, the function will run once in the context of the inferior, which after completion, will return the address of the actual implementation of the function.
> 
> Some more details on indirect functions if interested: http://www.agner.org/optimize/blog/read.php?i=167
> 
> Thanks,
> Matt
> <exprfix.patch>_______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits