4 Commits

Author SHA1 Message Date
Pavel Labath
51b74bb9f6 Reapply "[lldb] Use the function block as a source for function ranges (#117996)"
This reverts commit 2526d5b1689389da9b194b5ec2878cfb2f4aca93, reapplying
ba14dac481564000339ba22ab867617590184f4c after fixing the conflict with
 #117532. The change is that Function::GetAddressRanges now recomputes
the returned value instead of returning the member. This means it now
returns a value instead of a reference type.
2024-12-03 11:58:36 +01:00
Pavel Labath
2526d5b168 Revert "[lldb] Use the function block as a source for function ranges (#117996)"
This reverts commit ba14dac481564000339ba22ab867617590184f4c. I guess
"has no conflicts" doesn't mean "it will build".
2024-12-03 10:27:31 +01:00
Pavel Labath
ba14dac481
[lldb] Use the function block as a source for function ranges (#117996)
This is a follow-up/reimplementation of #115730. While working on that
patch, I did not realize that the correct (discontinuous) set of ranges
is already stored in the block representing the whole function. The
catch -- ranges for this block are only set later, when parsing all of
the blocks of the function.

This patch changes that by populating the function block ranges eagerly
-- from within the Function constructor. This also necessitates a
corresponding change in all of the symbol files -- so that they stop
populating the ranges of that block. This allows us to avoid some
unnecessary work (not parsing the function DW_AT_ranges twice) and also
results in some simplification of the parsing code.
2024-12-03 10:21:04 +01:00
Pavel Labath
2a3c08f620
[lldb] (Begin to) support discontinuous lldb_private::Functions (#115730)
This is the beginning of a different, more fundamental approach to
handling. This PR tries to tries to minimize functional changes. It only
makes sure that we store the true set of ranges inside the function
object, so that subsequent patches can make use of it.
2024-11-12 09:34:53 +01:00