[Lldb-commits] [PATCH] D12757: Fix prologue end handling when code compiled by gcc

[Tamas Berghammer via lldb-commits]

tberghammer added a comment.

In http://reviews.llvm.org/D12757#246497, @clayborg wrote:

> Maybe we can try still removing duplicates, but remembering the first index where we had a duplicate line entry. If we don't get a prologue end, then we got back to the index we remembered for the first duplicate and if it is valid, modify that entry to say "prologue_end = true"?


Remembering to the first duplicate entry isn't really possible because a line table covers several functions and we need the prologe_end marker for each functions. If we want to go in this direction then we have to couple the line table with the function ranges (including the function ranges for inline functions) what I am pretty sure we want to avoid. It would cause significant performance hit because it would require a full dwarf parsing.

> One other questions for clarification: Is GCC emitting prologue_end, but only emitting it on the first line entry? And then we overrwrite it with the second and remove the prologue_end, or does GCC just plain not emit prologue_end? If so, what happens when we have a line table that doesn't have two entries for the prologue with the same address? Do we just not have a prologue_end in a sequence in that case?


I never seen GCC emitting prologue_end marker in any architecture I tested and based on some online threads I am pretty sure it is the case for all architecture. It emits 1 line entry for the first address of the function and then an other line entry for the first non prologue instruction of the function.


http://reviews.llvm.org/D12757