Since every FUNC record (in breakpad) is a compilation unit, creating the
function for the CU allows ResolveSymbolContext to resolve
eSymbolContextFunction.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp | ||
---|---|---|
405–406 | Can you check if we can remove this now? I originally thought that we can remove this entire function, but I forgot about PUBLIC records -- we don't have functions or compile units for those, so they will have to stay. | |
lldb/test/Shell/SymbolFile/Breakpad/line-table.test | ||
54 | We should have a more explicit test for this. Some interesting things to check might be
|
Add tests.
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp | ||
---|---|---|
405–406 | Removing it causes FUNC records not showing up in symtab when doing image dump symtab ... and fails some tests.
|
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp | ||
---|---|---|
405–406 | It's expected that the tests verifying symtab contents need updating after you remove some things from it. It's also possible some other tests will need minor tweaks (like the one in line-table.test:54) because of small differences in output format. Whether this is a reasonable change cannot be judged by failing tests alone. You also need to evaluate the overall quality of the debugger output. That will have to be a judgement call, but I'm hoping it won't be a hard one. For example, the change in line-table.test was definitely for the better.
And if an address is covered both by a Symtab Symbol, and an SymbolFile Function, lldb will preferentially (in backtraces, for instance) display information from the Function, so I think (hope) that this is going to work exactly as desired. |
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp | ||
---|---|---|
405–406 | These two commands image lookup -n ... and image show-unwind -n .. also failed to give any information if the name is from FUNC records. |
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp | ||
---|---|---|
405–406 | Oh, maybe those commands use FindFunctions to lookup for function by name? |
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp | ||
---|---|---|
405–406 | Yes, that will most likely be it. If implementing FindFunctions ends up being non-trivial, we can do that (along with the symtab removal) in a separate patch. |
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp | ||
---|---|---|
405–406 | After implementing FindFunctions and removing this, image lookup -a 0x4000b0 -v in (lldb/test/Shell/SymbolFile/Breakpad/symtab.test) shows: Function: id = {0x00000001}, name = "f1_func", range = [0x00000000004000b0-0x00000000004000bc) Symbol: id = {0x00000000}, range = [0x00000000004000b0-0x00000000004000c0), name="f1" The symbol name is different from function because symbol name is from symtab and function name is from function in CU. And image lookup -n f1 and image lookup -n f1_func both give: Address: symtab.out[0x00000000004000b0] (symtab.out.PT_LOAD[0]..text2 + 0) Summary: symtab.out`f1_func Looks like we don't want to remove this part. |
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp | ||
---|---|---|
405–406 |
I would say this is actually a good thing, because you get more information (in verbose mode). it's also precisely what would happen in the "regular" case if say elf symtab and dwarf for whatever reason disagreed on the name of the function. In non-verbose contexts (the Summary field in image lookup, in backtraces, etc.) which just want a single name, lldb should prefer the one from the Function. So all of this sounds WAI to me. In fact, it probably should have been implemented that way from the start, but I was too lazy to bother with creating Functions. |
Sorry for the delay. Just a couple of (hopefully final) requests.
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp | ||
---|---|---|
245 | It would be nice to handle the case when this fails to find any sections. The most likely way for this to happen is a mismatched symbol file. | |
339 | How did you come to pick this? I get that this is not critical functionality for your use case, but it seems rather strange to be claiming that you're looking up methods here. If you don't care what you look up exactly, then maybe you could just skip this check completely, possibly leaving a TODO to implement this in a better way. (The Symtab class has code (heuristics) which tries to classify symbols into functions, methods, etc., but I'm not sure if it actually works with breakpad symbols (them being demangled), nor am I sure that we should replicate that here.) | |
382 | It'd probably be better to inline this lambda now. You can do that as a follow-up commit. No need for review. | |
lldb/test/Shell/Minidump/breakpad-symbols.test | ||
18–19 | It'd be better to modify the test inputs here to replace FUNC with PUBLIC records. This test checks that breakpad symbols files work with minidump cores, and checking for num_symbols = 0 is not very helpful, as that's precisely what would happen if the symbol files did _not_ work. |
Address comments.
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp | ||
---|---|---|
339 | I just found that name_type_mask always has eFunctionNameTypeMethod. |
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp | ||
---|---|---|
339 | This is probably the only value used by the tests, but one can definitely get other values too, for example through various arguments to the "breakpoint set" command. While a (very) brave soul could in theory try to set breakpoints and debug a live process with breakpad debug info, I think that's unlikely to happen in practice. So the usefulness of this function will probably remain limited to tests. |
It would be nice to handle the case when this fails to find any sections. The most likely way for this to happen is a mismatched symbol file.