| #
66a88f62 |
| 10-Jan-2025 |
Pavel Labath <pavel@labath.sk> |
[lldb] Add Function::GetAddress and redirect some uses (#115836)
Many calls to Function::GetAddressRange() were not interested in the range itself. Instead they wanted to find the address of the fun
[lldb] Add Function::GetAddress and redirect some uses (#115836)
Many calls to Function::GetAddressRange() were not interested in the range itself. Instead they wanted to find the address of the function (its entry point) or the base address for relocation of function-scoped entities (technically, the two don't need to be the same, but there's isn't good reason for them not to be). This PR creates a separate function for retrieving this, and changes the existing (non-controversial) uses to call that instead.
show more ...
|
| #
b852fb1e |
| 25-Oct-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Move ValueObject into its own library (NFC) (#113393)
ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-
[lldb] Move ValueObject into its own library (NFC) (#113393)
ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-time) circular
dependency between lldbCore and lldbValueObject, which is unfortunate
but probably unavoidable because so many things in LLDB rely on
ValueObject. We already have cycles and these libraries are never built
as dylibs so while this doesn't improve the situation, it also doesn't
make things worse.
The header includes were updated with the following command:
```
find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \;
```
show more ...
|