On Wed, 29 Aug 2018, Martin Liška wrote: > >> That said, it looks the shared library libgcov.so is overkill. > > > > It feels like that somehow. > > > >> Alexander may explain how that can be beneficial? > >> > >> Note that I can fix the segfault being caused by inter-DSO calls. > > > > I think that would be good and also amenable for backports. Just > > check for NULL before > > dereferencing.
Note if you have a call chain foo->bar->baz such that foo and baz are in the same DSO but bar is in another, with the NULL fix instead of segfaulting you'll probably record baz as direct callee of foo, which is not correct (but is a pre-existing problem, in the sense that it would also happen if the DSO with 'bar' was not instrumented at all). > Sure. Let's wait for Alexander. Maybe he's got something we missed. Well, here's the backstory. When people were discussing PR 83879 (multiple instances of __gcov_master due to dlopen) on IRC, with the fix being "advise the user to pass --dynamic-list-data", I butted in to say, >> imho it's a design mistake: gcov symbols that need to work across dso >> boundaries should have been a part of (currently non-existent) libgcov.so >> indirect call profiling across exe/library boundary is broken for a similar >> reason and later filed PR 84107 for the latter claim. I think in general if a design requires an object to exist in one instance like __gcov_master, for dynamic linking it should reside in a dynamic library. Otherwise, it puts the onus on users to ensure that it's exported from the main executable, not concealed in libraries by their version scripts. And even then it still might come up in two copies with dlopen (RTLD_LOCAL). In theory, another approach would be to have all gcov symbols have hidden visibility, no exceptions, and redesign the logic around __gcov_master to work properly when multiple instances are active in one program. Alexander
