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

Introduce a symbols API #38

Merged
merged 1 commit into from
Sep 19, 2024
Merged

Introduce a symbols API #38

merged 1 commit into from
Sep 19, 2024

Conversation

0152la
Copy link
Contributor

@0152la 0152la commented Sep 17, 2024

Rework how we store and search symbols for relocation, abstracting away most of the detail, in order to be able to use various underlying data types. As relocation seems to take most of the runtime based on initial observations, this is a first step in order to compare against various backend data types, rather than using an ad-hoc implementation.

@0152la 0152la requested a review from ltratt September 17, 2024 14:03
= find_lib_dep_sym_in_comp(curr_rela_map->rela_name,
new_comp, i, curr_rela_map->rela_sym_type, true);
// TODO Hack to suppress weak `libc` relocations
if (strcmp(new_comp->libs[i]->lib_name, "libc.so.7"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we make this a bit more abstract e.g. at least "if name starts with libc.so" (i.e. without the ".7")?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would've liked to expand this into providing a list of libraries to suppress, or parameterise it, but maybe that's too much at this point, but at least I did the prefix check for libc.so in be0d58b.

@ltratt
Copy link
Contributor

ltratt commented Sep 19, 2024

Please squash.

Rework how we store and search symbols for relocation, abstracting away
most of the detail, in order to be able to use various underlying
data types. As relocation seems to take most of the runtime based on
initial observations, this is a first step in order to compare against
various backend data types, rather than using an ad-hoc implementation.
@0152la
Copy link
Contributor Author

0152la commented Sep 19, 2024

Squashed.

@ltratt ltratt added this pull request to the merge queue Sep 19, 2024
Merged via the queue into capablevms:master with commit e9fccef Sep 19, 2024
2 checks passed
@0152la 0152la deleted the opt_relas branch September 19, 2024 14:21
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

Successfully merging this pull request may close these issues.

2 participants