fix(debuginfo): Skip eliminated functions in linked objects #216
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes an issue that indirectly lead to "inline parent offset too large for symcache file format" errors by reintroducing checks for functions with a
DW_AT_low_pc
of0
.In regular shared objects or executables, such functions have been eliminated by the linker. As the primary use case of this library is to symbolicate stack traces, yielding such functions from the function iterator is not desirable. Also, the virtual address of the functions is no longer valid and implicitly overlaps with other eliminated functions. At least in the default behavior, they should not be included.
Removing the checks introduced a 10% performance regression on large ELF symbols. I did not notice this on my initial tests, since I missed the fact that this case is only triggered by the GNU linker. If it weren't for the symcache bug, the performance hit alone would be bearable.
Now, for relocatable objects it may make sense to include the functions. This means, there are two options:
DwarfFunctionIterator
that allows to override the check. This has the disadvantage that it would not be exposed on the trait or onObjectFunctionIterator
. A possible interface could be:Relocatable
, and include the function by default and hide them otherwise. This would mean that the iterator magically does the right thing. Also, this comes closest to the original intention of the previously removed code comment.Since I am gravitating to option 2, this is what is implemented in this patch.
Partially reverts #173
cc @nnethercote