This patch teaches SymbolFileBreakpad to parse the line information in
breakpad files and present it to lldb.
The trickiest question here was what kind of "compile units" to present
to lldb, as there really isn't enough information in breakpad files to
correctly reconstruct those.
The twoA couple of options Iwere considered were:
- have the entire file be one compile unit
- have one compile unit for each FILE record
- have one compile unit for each FUNC record
The main drawbacks of the first approach areis that thall of the files would
be compile unit creatednsidered "headers" by lldb, and so they wouldn't be searched if
this way will be huge,target.inline-breakpoint-strategy=never. and there isn't a good way to name it (I decidedThe single compile unit would
to name it after the object file)also be huge, and there isn't a good way to name it.
The second approach will create mostly correct compile units for cpp
files, but it will still be wrong for headers. However, the biggest
drawback here seemed to be the fact that this can cause a compile unit
to change mid-function (for example when a function from another file is
inlined or another file is #included into a function). While I don't
know of any specific thing that would break in this case, it does sound
like a thing that we should avoid.
So,In the end, we chose the third option, as it didn't seem to have any
major disadvantages, though it was not ideal either. in the endOne disadvantage
here is that this generates a large number of compile units, I chose the first approach,and there
is still a question on how to name it. because it results inWe chose to simply name it after
simpler code,the first line record in that function. and having one compile unit doesn't seem so bad,This should be correct 99.99% of
particularly as the second approach wouldn'tthe time, though it can produce somewhat strange result in correct compiles if the very
units either.first line record comes from an #included file.