https://bugs.kde.org/show_bug.cgi?id=353192
--- Comment #15 from Paul Floyd <[email protected]> --- (In reply to Fredrik Tolf from comment #14) > If Valgrind simply > checks whether a mapped file is an ELF file, should that not effectively > remove the need for this platform variation? My concern is that some of the platform hard-codedness may be really necessary. > Again, to be clear, I'm speaking from almost complete ignorance here, so > please tell me what I'm missing, but when I'm using an unpatched Valgrind to > debug a program with this problem, and I want the symbol name for a certain > address, I just check the process' memory mappings, calculate the file > offset of the address, and then just use gdb on the file mapped at that > address to ask for the symbol corresponding to that "virtual address" (with > "info line *$address"). While somewhat laborious, this seems to work every > time. Is there a reason Valgrind can't just do basically the same thing for > any address whose page is mapped from an ELF file? That fundamentally seems > like the approach I'd take if I were to build an address-to-symbol mapper. I > guess what I'm saying is that I would think that all you really need is the > file path and offset for any file-mapped page in the guest address space, > and any "segment info" or other more abstract runtime information should be > superfluous. Am I wrong? Valgrind has its own DWARF reader. We're currently looking at switching to GPLv3 which would allow us to use code from gdb and binutuls. The problem here is detecting the conditions that trigger looking in a segment for symbols. There's more than just guest binary error callstacks. It's nice to be able to generate a proper callstack for Valgrind itself when "the impossible happens". We also need symbols for all of the redirection functions which use an encoding to indicate the function name and library that they should redirect. -- You are receiving this mail because: You are watching all bug changes.
