Skip to content
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

"Location/range lists for this CU" is not a thing #581

Open
sevaa opened this issue Nov 24, 2024 · 0 comments
Open

"Location/range lists for this CU" is not a thing #581

sevaa opened this issue Nov 24, 2024 · 0 comments

Comments

@sevaa
Copy link
Contributor

sevaa commented Nov 24, 2024

See this: #580

The way pyelftools handles location lists and rangelists, there is no way to properly support this kind of mixed bitness file structure. How loclist access normally goes, one constructs a LocationListParser around a LocationLists object, which comes from calling location_lists() on a DWARFInfo, which constructs a LocationLists with a copy of file level structs. No way to pass the structs of a specific CU there. Similar story with rangelists.

One can sort make this work by swapping the structs member on the LocationLists/RangeLists object before individual loclist/rangelist access, substituting the structs from the CU that holds the loclist/rangelist reference, but that's on the very edge of proper usage.

There is an optional DIE/CU parameter on get_location_list_at_offset() and similar; we could modify that to swap the structs to the current CU's structs if provided. This way the API surface would be intact (modulo the rather exotic method get_range_list_at_offset_ex(), and adding an extra optional argument is hardly a breaking change).

Alternatively, we could allow for explicitly constructing a loclist/rangelist parser for a specific CU. The former saves for memory but adds an extra check/set for every loclist access, the latter gives marginally better performance but can lead to proliferation of parser objects.

@sevaa sevaa changed the title "Location/range lists" for this CU is not a thing "Location/range lists for this CU" is not a thing Nov 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant