From: Josef W. <Jos...@gm...> - 2007-03-21 11:02:53
|
Hi, [BTW, I am not not subscribed to this mailing list, and I added valgrind developers mailing list to CC] > On Fri, Mar 16, 2007 at 11:35:53PM +0100, Josef Weidendorfer wrote: > > Obviously, on my OpenSuse 10.2, libz.so is stripped and does not have a > > symbol table, so opreport only shows the sum for all functions in the > > library. However, Valgrind also loads the dynamic symbol table, so that > > cachegrinds report showed the different functions in libz.so. > > Which is a fundamental error. The dynsym by its very nature does not > have unexported symbols, so any samples taken against those symbols will > be erroneously reported against the wrong symbol. As there are no > guarantees as to how the binary is laid out in memory, this means the > profile is at best incomplete and at worst totally misleading. Interesting. So you say that we can not rely on the sizes of dynamic symbols? If that is the case, we probably should change something in Valgrind, too. Here, the output of a "objdump -T ..." looks perfectly fine. With correct symbol sizes, there is no way to get misleading information. (Of course, unexported symbols will be aggregated into one entry). Josef |
From: Maurice v. S. <ma...@bl...> - 2007-04-04 17:49:45
|
I followed the discusion about loading symbols from a dynamic shared library. We are trying to profile an animation package (maya) which is built almost entirely from dso's, hence my interest. Any opinion on if it is worth building my own oprofile with Josef Weidendorfer's patch? Thanks. -- Maurice van Swaaij - Manager Technical Software - Blue Sky Studios NY [ http://www.blueskystudios.com | ma...@bl... ] |
From: Julian S. <js...@ac...> - 2007-03-21 11:27:55
|
I'm confused. So you're saying that Valgrind's handling of dynamic symbol tables is wrong? On Wednesday 21 March 2007 11:02, Josef Weidendorfer wrote: > Hi, > > [BTW, I am not not subscribed to this mailing list, and > I added valgrind developers mailing list to CC] > > > On Fri, Mar 16, 2007 at 11:35:53PM +0100, Josef Weidendorfer wrote: > > > Obviously, on my OpenSuse 10.2, libz.so is stripped and does not have a > > > symbol table, so opreport only shows the sum for all functions in the > > > library. However, Valgrind also loads the dynamic symbol table, so that > > > cachegrinds report showed the different functions in libz.so. > > > > Which is a fundamental error. The dynsym by its very nature does not > > have unexported symbols, fine > > so any samples taken against those symbols will > > be erroneously reported against the wrong symbol. I don't follow the implication. dynsym may not have unexported symbols, but what does that have to do with whether or not symbols have proper size/length information? J |
From: Josef W. <Jos...@gm...> - 2007-03-21 16:57:06
|
On Wednesday 21 March 2007, Julian Seward wrote: > > I'm confused. So you're saying that Valgrind's handling of dynamic > symbol tables is wrong? Ah, I think I got it. There nothing seems to be wrong in VG. I sent a patch for OProfile to also read in the dynamic symbol table. However, I did it in a rush and did not really check for correct behavior in general. So John's comment about "fundamental error" probably was not about using the dynamic symbol table in general, but about my patch ;-) OProfile does not seem to check symbol sizes as given in the symbol table entries, but calculates the sizes on its own by sorting the symbols according to their address, and calculate the size by address difference to the next symbol in the (sorted) list. However, I do not understand the reason why OProfile does it this way. Perhaps there were some buggy linkers in the past which generated bogus size values? Josef |
From: Julian S. <js...@ac...> - 2007-03-21 17:14:34
|
> There nothing seems to be wrong in VG. Good :-) > OProfile does not seem to check symbol sizes as given in the symbol table > entries, but calculates the sizes on its own by sorting the symbols > according to their address, and calculate the size by address difference to > the next symbol in the (sorted) list. > > However, I do not understand the reason why OProfile does it this way. > Perhaps there were some buggy linkers in the past which generated bogus > size values? I think I know. Imagine a situation where only part of the address range is covered, if you take in to acount the symbol sizes: symA start=0 len=10 symB start=20 len=20 Then for 10 .. 19 there is no associated symbol, and V's reader will say "there is no symbol here; I cannot help you." OProfile will regard symA as extending all the way to the start of symB. Of course that may be more confusing than helpful, but that's the effect. The situation is real, especially for stripped .so's like the mentioned libz.so etc, because the stripping process removes symbol information for non-exported functions, and so the symbol table is "full of holes" so to speak. I looked into this just recently (for libz.so.1.2.3, curiously enough). In fact Valgrind also has a symbol-table cleanup pass, canonicalise_symtab() which does truncate any overlapping symbol ranges, to guarantee that any address is only associated with at most one symbol. J |
From: John L. <le...@mo...> - 2007-03-21 18:38:14
|
On Wed, Mar 21, 2007 at 12:02:47PM +0100, Josef Weidendorfer wrote: > Interesting. > So you say that we can not rely on the sizes of dynamic symbols? In general that's the case. We used to rely upon the size field of the symbol entries but experience proved it not to be reliable enough. Ever since we've used an address-sorted list instead (essentially). Unfortunately I've completely forgotten the details. Maybe things have improved in the meantime, and it might be time to re-investigate this issue. Of course, we would need to create a bucket for samples that slip through the cracks and indicate to the user that they're for local symbols. regards john |