-
Notifications
You must be signed in to change notification settings - Fork 13.8k
[lldb] Use the first address range as the function address #122440
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -428,7 +428,7 @@ class Function : public UserID, public SymbolContextScope { | |
/// The section offset based address for this function. | ||
Function(CompileUnit *comp_unit, lldb::user_id_t func_uid, | ||
lldb::user_id_t func_type_uid, const Mangled &mangled, | ||
Type *func_type, AddressRanges ranges); | ||
Type *func_type, Address address, AddressRanges ranges); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we want to call this There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Personally, I don't think that adds anything. "function base address" isn't an established concept. "function address" is (at least if you're coming from C/C++), and that is exactly what this argument should contain. It's true that this address is also used as a base for computing the addresses of blocks and variables, but I think that's a secondary function (technically, the two don't even have to be the same, but I don't think separating the two would help). There is also a comment on the getter function (line 455) which should help resolving any ambiguity. |
||
|
||
/// Destructor. | ||
~Function() override; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2393,10 +2393,29 @@ Function *DWARFASTParserClang::ParseFunctionFromDWARF( | |
assert(func_type == nullptr || func_type != DIE_IS_BEING_PARSED); | ||
|
||
const user_id_t func_user_id = die.GetID(); | ||
|
||
// The base address of the scope for any of the debugging information | ||
// entries listed above is given by either the DW_AT_low_pc attribute or the | ||
// first address in the first range entry in the list of ranges given by the | ||
// DW_AT_ranges attribute. | ||
// -- DWARFv5, Section 2.17 Code Addresses, Ranges and Base Addresses | ||
// | ||
// If no DW_AT_entry_pc attribute is present, then the entry address is | ||
// assumed to be the same as the base address of the containing scope. | ||
// -- DWARFv5, Section 2.18 Entry Address | ||
// | ||
// We currently don't support Debug Info Entries with | ||
// DW_AT_low_pc/DW_AT_entry_pc and DW_AT_ranges attributes (the latter | ||
// attributes are ignored even though they should be used for the address of | ||
// the function), but compilers also don't emit that kind of information. If | ||
// this becomes a problem we need to plumb these attributes separately. | ||
Address func_addr = func_ranges[0].GetBaseAddress(); | ||
|
||
func_sp = std::make_shared<Function>( | ||
&comp_unit, | ||
func_user_id, // UserID is the DIE offset | ||
func_user_id, func_name, func_type, std::move(func_ranges)); | ||
func_user_id, func_name, func_type, std::move(func_addr), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've added by default -- as a signal that I am done with this object. It turns out that in this case, the move doesn't help, because the Address class does not have a move constructor (due to the -- unnecessary -- explicit definition of a copy constructor), but it doesn't hurt either. And if the object grows a move constructor (by removing the explicit copy definition), then this will automatically use it (which will then avoid a copy of the weak_ptr inside the address -- not particularly expensive but still requires atomic reference count updates). |
||
std::move(func_ranges)); | ||
|
||
if (func_sp.get() != nullptr) { | ||
if (frame_base.IsValid()) | ||
|
Uh oh!
There was an error while loading. Please reload this page.