https://bugs.kde.org/show_bug.cgi?id=353192
--- Comment #14 from Fredrik Tolf <[email protected]> --- (In reply to Paul Floyd from comment #13) > There are two big headaches. > 1. As you see in the code there is a lot of variation between platforms. I'm > not sure if it's possible to have code that is genuinely generic and cross > platform. I will certainly admit that I didn't study the code in extreme detail, so I might certainly misunderstand what you are writing about, but from what I saw, the variation between platforms seemed to have mainly consisted in the various different segment property heuristics for the different platforms, which is exactly what I suggest to remove entirely. If Valgrind simply checks whether a mapped file is an ELF file, should that not effectively remove the need for this platform variation? > 2. This code gets called both for binaries that are already loaded and > whenever the guest loads a binary (at startup of via dlopen). The "already > loaded" case is horrible as Valgrind may have merged segments that are > contiguous. 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? -- You are receiving this mail because: You are watching all bug changes.
