Differential D35607
Extend 'target symbols add' to set symbol file for a given module Authored by eugene on Jul 18 2017, 9:25 PM.
Details Now -shlib flag can be provided alongside with names of symbols files: (lldb) target symbols add --shlib stripper-lib.so unstripper-lib.so This is helpful when default matching mechanisms by name and UUID
Diff Detail
Event TimelineComment Actions I think Jim (or maybe Greg?) should take a look at this. Right now I'll just comment on the test.
Comment Actions Btw, will this work correctly if we are cross-debugging from a mac? (because then we will use the fancy DownloadObjectAndSymbolFile implementation) Comment Actions This seems like an okay change. You want to make sure that passing the file name and UUID into AddModuleSymbols doesn't override a UUID mismatch against the symbol file however you find it. It looks like that function does the right thing, but can you add a test for this? You also need to fix up the error messages (around line 4270.) At present they assume that the uuid & file option's are mutually exclusive. It's disconcerting to specify two things and have the error mention only one. This is more Greg's area than mine, so he should also give it the okay. Comment Actions So we should just make sure this works: (lldb) target symbols add --shlib a.out debug_binaries/a.out The --uuid option is there to help you match up without having to specify the file path. If I am understanding correctly, "a.out" has no UUID or build ID, but "debug_binaries/a.out" does? In that case, there is no need to specify the --uuid option. If the UUID do match, then you could just do: (lldb) target symbols add debug_binaries/a.out It would extract the UUID from "debug_binaries/a.out" and then match it to the file. So the "--shlib" option is there to point you in the right direction. When the UUIDs don't match, we should make sure that "target symbols add --shlib a.out debug_binaries/a.out" by recognizing that "a.out" doesn't have a valid UUID so the UUID doesn't need to match in order for "debug_binaries/a.out" to be an acceptable match for it as a symbol file. This might make some of the changes above go away and move them to the ModuleSpec matching code. Comment Actions In this case, neither of the files has a build id/UUID. However, the tricky part here is that in this case we "invent" a UUID by doing a checksum of the whole file. This is done to support the .gnu_debuglink https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html method of finding symbols. It works like this:
This works fine for the gnu_debuglink case, as then the rest of the machinery will match the files based on their UUIDs. However, it does not work for the general case without the debug link, as then the files will end up with two different "UUID"s (because they are based on the file content), and everything will consider them as different. The solution that would seem best to me here would be to leave the UUID of files which don't have a build-id as empty, as the gnu_debuglink is not really a UUID -- it's main function is to contain a file path, and the crc just acts as a sanity check. This should make the logic for matching two uuid-less files saner, but it would require us to implement the gnu_debuglink method in a different way (which I think is fine, as the current way seems pretty hacky, and causes us to often compute crcs of large files needlessly). I have no idea how much of our existing code would blow up if we started having files without a uuid though. What do you think about that? Comment Actions The UUID is assumed to be a unique identifier that isn't based on the entire file contents, but on the content the the important bits (.text, .data, etc). On Mac, the mach-o files have a LC_UUID which is generated by carefully doing and MD5 checksum on only the bits that don't change due to debug info or strings from debug info. This means a binary that is built in /tmp/a or in /tmp/b with debug info will result in the same UUID. When we create a stand alone debug info file, this UUID gets copied into it. One other thing we could try is to add a type to the lldb_private::UUID class that specifies the type of the UUID: namespace lldb_private {
class UUID {
public:
enum Type {
eTypeBuildID,
eTypeFileCRC, // CRC of the entire file contents
eTypeDebugInfoCRC, // CRC of the debug info
};
};If I understood your comments above, one file would have a UUID::eTypeBuildID type and the other would have either a UUID::eTypeFileCRC or UUID::eTypeDebugInfoCRC. Then we teach the ObjectFile subclasses to properly set the UUID type. When comparing UUID values, we then could note that the types are not the same and do something more intelligent. Like when adding a symbol file, we could ignore the UUID mismatch if the UUID::Type doesn't match and just go on filename. But we would honor the mismatch if the UUID::Type was the same. Comment Actions I like this, and I'm going to implement it. Pavel is right and the way UUID is set for modules without build-id is kinda strange, but changing it seems like a big and risky change. Comment Actions One other idea if we go with the UUID::Type solution: if we have UUIDs that are different, we could ask the ObjectFile (ObjectFileELF) to see if it thinks the files go together. Not sure if there is anything in the ELF file that would allow us to do that. In Mach-O we have all definitions for the .text and .data sections, just not the bytes. So it would be easy to compare the file address and file sizes of the sections that are in both to see if they match. Something like: bool ObjectFile::FilesAreRelated(ObjectFile &rhs); In Mach-O it could run through the segments and compare the ones in common to ensure things match. Comment Actions Found a way to implement what I need much easily and switched to using file names instead of UUID. Please take another look. Comment Actions Looks fine, just add an error that checks that when the --file options is used, that only one argument (symbol file) is specified.
| ||||||||||||