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

Rework SymbolTableCache::str2sym member #938

Merged
merged 1 commit into from
Dec 21, 2024
Merged

Conversation

d-e-s-o
Copy link
Collaborator

@d-e-s-o d-e-s-o commented Dec 20, 2024

So far our symbol name to symbol index inside the SymbolTableCache type was just referencing memory mapped strings directly. That works well, but it breaks once we introduce the option of not using a memory mapping but reading sections from a file using "regular" file I/O -- which is something that we require as a "fallback" with upcoming changes. Basically, if SymbolTableCache::strs is heap allocated then str2sym can't easily reference data from it, as that would be self-referential. To work around this issue, instead of storing references inside the str2sym table, we work with indexes.
As a perhaps positive side effect of making this change, we also opted for pushing the string validation further out to the point where we actually need the Unicode string. This could, conceivably, help in cases where, say, a symbol table contains corrupt or otherwise garbled symbol names.

So far our symbol name to symbol index inside the SymbolTableCache type
was just referencing memory mapped strings directly. That works well,
but it breaks once we introduce the option of not using a memory mapping
but reading sections from a file using "regular" file I/O -- which is
something that we require as a "fallback" with upcoming changes.
Basically, if SymbolTableCache::strs is heap allocated then str2sym
can't easily reference data from it, as that would be self-referential.
To work around this issue, instead of storing references inside the
str2sym table, we work with indexes.
As a perhaps positive side effect of making this change, we also opted
for pushing the string validation further out to the point where we
actually need the Unicode string. This could, conceivably, help in cases
where, say, a symbol table contains corrupt or otherwise garbled symbol
names.

Signed-off-by: Daniel Müller <[email protected]>
Copy link

codecov bot commented Dec 20, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.44%. Comparing base (314cfcc) to head (0a585b0).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #938      +/-   ##
==========================================
- Coverage   94.46%   94.44%   -0.02%     
==========================================
  Files          57       57              
  Lines       10510    10531      +21     
==========================================
+ Hits         9928     9946      +18     
- Misses        582      585       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@d-e-s-o d-e-s-o merged commit 9a39222 into libbpf:main Dec 21, 2024
41 checks passed
@d-e-s-o d-e-s-o deleted the topic/str2sym branch December 21, 2024 01:07
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.

1 participant