Re: [DynInst_API:] BPatch_image->findFunction() behavior with weak symbols

[Benjamin Welton <welton@xxxxxxxxxxx>]

German, 

You should also try testing out if mangled names ( getMangledNames() ) are having the same weird output. If the mangled names are correct, it increases the likelihood of a demangling issue. 

Tim may be in a better position to answer if the GNU demangler is better to use. 

Ben

On Thu, Jul 18, 2019 at 3:11 AM German Llort Sanchez <gllort@xxxxxx> wrote:

Hi Tim!

I haven't tried Ben's suggestions yet, but I confirm that I'm using the
latest release 10.1, and also using the libiberty demangler. Should I
try the GNU demangler instead?

Thanks!
-- G.

El 2019-07-18 00:09, Tim Haines escribiÃ:
> Hi, German.
>
> Are you using Dyninst-10.1? If not, I would strongly recommend
> upgrading as there was an enhancement to the build system where the
> USE_GNU_DEMANGLER flag was fixed to work correctly. Previously, there
> was an ambiguity about which demangler was compiled into Dyninst:
> either GNU demangler or libiberty.
>
> Thanks.
>
>  - Tim
>
> On Wed, Jul 17, 2019 at 3:45 PM German Llort Sanchez
> <german.llort@xxxxxx> wrote:
>
>> Hi,
>>
>> Just adding a little extra information, but I'm not sure if
>> clarifies
>> anything or opens a second issue. Checking the API of
>> BPatch_function I
>> noticed the method getNames (in plural), with this comment saying
>> that
>> it returns all names of the symbol including those weak. So I
>> figured
>> out that maybe the match returned by findFunction corresponds to
>> the
>> first name in the list, but maybe in the whole list of names all
>> the
>> other decorations appear, so I could check if the one I am
>> expecting for
>> is present in the list.
>>
>> I tried that, dumping the names like this:
>>
>> BPatch_Vector<const char *> names;
>> found_funcs[0]->getNames(names);
>>
>> cerr << "getRoutine: Searching for " << routine << " found " <<
>> found_funcs.size() << " with " << names.size() << " names: ";
>> for (int i=0; i<names.size(); i++)
>> {
>> cerr << names[i] << " ";
>> }
>>
>> And the output looks like this:
>>
>> getRoutine: Searching for MPI_Init found 1 with 4 names: `a `a `a
>> `a
>> getRoutine: Searching for mpi_init found 1 with 16 names: `a `a `a
>> `a `a
>> `a `a `a `a `a `a `a `a `a `a `a
>> getRoutine: Searching for mpi_init_ found 1 with 16 names: `a `a `a
>> `a
>> `a `a `a `a `a `a `a `a `a `a `a `a
>> getRoutine: Searching for mpi_init__ found 1 with 16 names: `a `a
>> `a `a
>> `a `a `a `a `a `a `a `a `a `a `a `a
>> getRoutine: Searching for MPI_INIT found 1 with 16 names: `a `a `a
>> `a `a
>> `a `a `a `a `a `a `a `a `a `aStarting program execution
>>
>> For each symbol that I look for, there's only 1 BPatch_function
>> match,
>> and for each object, there's several names found, but the names
>> look
>> like that (`a).
>>
>> Also note that the getNames method that I'm using from
>> BPatch_function
>> class is this one:
>>
>> bool getNames(BPatch_Vector<const char *> &names);
>>
>> There's another one with strings:
>>
>> bool getNames(std::vector<std::string> &names);
>>
>> But if I try to use the second one, I'm getting this linking error:
>>
>> launcher.cpp:(.text+0x2aa): undefined reference to
>> `BPatch_function::getNames(std::vector<std::string,
>> std::allocator<std::string> >&)'
>>
>> I have the same problem with several other methods that use the
>> string
>> interface.
>>
>> Thanks for your help!
>> -- G.
>>
>> El 2019-07-15 17:22, GermÃn Llort escribiÃ:
>>> Hi,
>>>
>>> We're using BPatch_image->findFunction() to look for MPI symbols
>> in a
>>> binary. When the binary is Fortran code, different compilers may
>> add
>>> different decorations to the MPI functions. For example, for
>>> "MPI_Init", different compilers may end up naming this function
>> like:
>>>
>>> - mpi_init (all lowercase)
>>> - mpi_init_ (1 underscore at the end)
>>> - mpi_init__ (2 underscores at the end)
>>> - MPI_INIT (all uppercase)
>>>
>>> And sometimes, all these variants are present.
>>>
>>> When we use findFunction to look for these different names, ,
>> there's
>>> always a match, but in all cases it matches with "mpi_init__" (2
>>> underscores). For example:
>>>
>>> found_funcs.clear();
>>> if (appImage->findFunction ("mpi_init", found_funcs) != NULL)
>>> {
>>> fprintf(stderr, "match %s\n",
>> found_funcs[0]->getName().c_str());
>>> }
>>>
>>> This results in finding "mpi_init__".
>>>
>>> We use this to discover dynamically the name mangling scheme that
>> was
>>> applied by the compiler, and since all these searches end up
>> matching
>>> with the symbol with 2 underscores, it's misleading for us.
>>>
>>> The particularity with these symbols is that they're defined as
>> weak.
>>> Is this the expected behavior of the search when the symbols are
>> weak?
>>> Or maybe we're doing something wrong?
>>>
>>> Thanks!
>>> -- G.
>>
>> http://bsc.es/disclaimer [1]
>> _______________________________________________
>> Dyninst-api mailing list
>> Dyninst-api@xxxxxxxxxxx
>> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api [2]
>
>
> Links:
> ------
> [1] http://bsc.es/disclaimer
> [2] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api


http://bsc.es/disclaimer
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api