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

[Kopec, Matt]

Hi Sean,

No problem, I'm fine with Mr. Kopec as well :)

Resolution only occurs after we have found a symbol and find that it is indirect. There are two places where the resolution occurs.
-In AddOneFunction, if the function can't be resolved then it won't be added. Actually, it will assert and abort lldb. I don't see a reason why a symbol can't be resolved but maybe there is a better way to handle this?
-In GetFunctionAddress, we will fail if a function cannot be resolved in the target.

For the case of calling a function that the program hasn't called yet, this should be fine, as long as the symbol can be found and resolved in the inferior/linked libraries.

For instance, test/lang/c/strings/TestCString.py has this test:

        self.expect("expression -- (int)strlen(\"hello\")",
                    startstr = "(int) $2 = 5")

The binary generated for this test doesn't have a strlen call (strlen is an indirect function) and the test above works as expected.

I'm not sure what else lldb could do to force resolution. This is probably the simplest way. I think this is something that should be done on an as needed basis rather then, for instance, resolving all the indirect function addresses when the symbol table is generated.

Does this address your concerns?

Thanks,
Matt
________________________________________
From: Sean Callanan [scallanan at apple.com]
Sent: Friday, January 25, 2013 2:21 PM
To: Kopec, Matt
Cc: lldb-commits at cs.uiuc.edu
Subject: Re: [Lldb-commits] [Patch][Please Review] Add support for GNU indirect functions

Sorry, I should probably have addressed you as "Matt."  I looked at the headers wrong  :)

Sean

On Jan 25, 2013, at 11:19 AM, Sean Callanan <scallanan at apple.com> wrote:

> Kopec,
>
> one thing I noticed is that it looks like if the indirect symbol hasn't been resolved yet in the underlying process, it looks like we just give up.  What if the user wants to call a function that the program hasn't yet called?  Are there cases where this would blow up?  Is there something more that LLDB should be able to do to force resolution?
>
> Sean
>
> 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
>
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits