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

[Benjamin Welton <welton@xxxxxxxxxxx>]

Hey German,

> Checking the API of BPatch_function I noticed the method getNames (in plural)

Yeah the dual interfaces for getting string names is a bit weird (and exists mainly for user application compatibility purposes). My understanding is that in most cases you should use the (std::vector<X> &) for any feature that has dual interfaces.

> But if I try to use the second one, I'm getting this linking error:

This is a strange and these functions *should* be available. What version of Dyninst are you using and are you linking your tool against the correct version of libDyninstAPI.so?

> 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).

Yeah this is problematic and Dyninst is doing something wrong here. Is the binary you are running your tool on (the application with these mpi_init functions) small enough to send over e-mail so that I can reproduce this locally?

> Is there any debug variable that I may turn on that would help to see what's going on, or anything else that I could try?

Right now I am thinking that this could be one of four potential issues:

1. Dyninst isn't aware of these functions at all and is missing them during parsing

2. Dyninst isn't applying the symbol name to the function correctly (using a generic targXXXX function name instead).

3. Dyninst regex searching is broken and only returning partial results.

4. All of the weak symbols not present in the output point to either no function or the same function (for which in the first case might result in no function being created and in the second case a single function would have X names).

Assuming we can get the "getNames" issue fixed, one of the ways this can be narrowed down is by performing a manual search of all the functions in the binary.

The dyninst function BPatch_image->getAllProcesdures(vector<BPatch_function> &ret) will return every function contained in the binary (or address space if used on a process).

What i suggest is using getAllProcesdures() and comparing the name of each function to the set of "mpi_init" names. If all the names are found, then this is very likely a dyninst regex bug that will have to be tracked down. If this does not find all of the various mpi_init entries, then we would likely need to directly examine the binary to see what these weak symbols are pointing too.

Ben

On Wed, Jul 17, 2019 at 2:40 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