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


Date: Thu, 18 Jul 2019 04:10:42 +0000
From: Benjamin Welton <welton@xxxxxxxxxxx>
Subject: Re: [DynInst_API:] BPatch_image->findFunction() behavior with weak symbols
A small correction on my previous email: The function to get all functions in an image is BPatch_Image->getProcedures().

Ben

On Wed, Jul 17, 2019 at 5:09 PM Tim Haines <thaines.astro@xxxxxxxxx> wrote:
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
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
[← Prev in Thread] Current Thread [Next in Thread→]