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

EhHdrTable::lookup doesn't return the address that corresponds to the found FDE #613

Open
mstange opened this issue Jan 22, 2022 · 4 comments

Comments

@mstange
Copy link
Contributor

mstange commented Jan 22, 2022

EhHdrTable::lookup takes an address and finds the entry in the table whose address is closest to the looked up address. Then it drops that entry's address on the floor and only returns the "FDE pointer" part of the entry.

I think it would be great if both parts of the entry were returned: The entry address and the entry FDE pointer.

I am interested in the address as an approximation for "the closest function start address". I could of course get that address by parsing the eh_frame section and looking up the FDE, but this seems like a waste if what I'm looking for is already in eh_frame_hdr.

@philipc
Copy link
Collaborator

philipc commented Jan 23, 2022

Are you sure don't want to also check the length in the FDE? This seems like useful information, even if you want to always return the address regardless of this check.

@mstange
Copy link
Contributor Author

mstange commented Jan 23, 2022

It's useful information, but I don't think I need it for my use case - I could treat addresses "between" functions differently, but I'm not sure what kind of treatment would be useful.

@philipc
Copy link
Collaborator

philipc commented Jan 23, 2022

For both this and #612, can you do it first without any gimli changes, and then measure whether the changes to support these issues make a noticeable performance difference? I'm reluctant to add support for things that aren't a normal use of the information, and that are already possible without any changes.

For this issue, we probably want to leave the signature of EhHdrTable::lookup unchanged, and add a new function instead.

@mstange
Copy link
Contributor Author

mstange commented Jan 23, 2022

Sounds good.

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

2 participants