Functions with same name in multiple compilation targets do not increase counters

[foolswood]

I have some functions with the same name in multiple plugin-like .so files.

I annotated the first and it picked it up and reported a number of realtime functions, when the second was annotated that number did not change. Renaming the function caused the count to increase.

This may well be intentional (and my own fault for running across multiple targets), but I thought it might be worth asking about.

[tobiasherzke]

Looks like stoat has no concept of multiple definitions of the same symbol in different RTLD_LOCAL contexts, and considers them to be the same function. And in my opinion, this is a good thing, and should stay that way.
Benefit if it stays like this: If you forget to tag the signal processing entry point in one plugin, then that function will be checked anyway by stoat.
Disadvantage if stoat learned about this particular dlopen feature: stoat would get more complicated for no relevant gain. You would have to tell stoat somehow which .bc files form together one plugin. Future requests for solving other corner cases in stoat will have a precedent.

[fundamental]

Stoat generally assumes that one function symbol name is associated with a single underlying C/C++ implementation. This approach is fairly useful in the case where a function may receive multiple definitions (e.g. static/local functions or template code definitions). As you can see the drawback exists when you have a variety of translation units (C/C++ source files) which build into multiple different libraries or executables.

It is possible to get stoat to automatically recognize which LLVM bitcode files are associated with which binaries eventually, but for the moment the recommended course of action would be specifying the bitcode files yourself (e.g. stoat -r common-build-dir/ specific-plugin-file.bc ).

(Notes for feature implementation)
For the structure to be recognized automatically stoat will need to:

1. recognize the linker phase of a project's build (e.g. $CC -o BIN file.o file2.o file3.o)
2. dump an additional metadata piece of information specifying the dependent .bc files
3. do the above in a recursive process for projects that may have a complex build (e.g. 1.o 2.o 3.o => lib.a, lib.a 4.o => binary)
4. expose a way for stoat to consume the metadata (the metadata files could be as simple as a list of bitcode files)

[foolswood]

I had a bit of a play with this from the perspective of compilation units (as opposed to targets):
https://github.com/fundamental/stoat/compare/master...foolswood:compilation_unit_example?expand=1

Building main with different sub implementations yields different results:

• sub_safe.c - Summary: 3 functions, all safe. (Actually 4 functions in example).
• sub_unsafe.c - Summary: 5 functions, 2 unsafe. (Actually 4 functions in example).
• sub_safe2.c - Summary: 6 functions, 2 unsafe. (Actually 5 in example). In this case a false contradiction is reported.

Don't know if my experimenting here is useful or annoying, but I thought the false positive might be of interest.
That said I have not been able to sneak anything realtime unsafe past stoat :)