-
Notifications
You must be signed in to change notification settings - Fork 47
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
aarch64: vdso symbols #1292
aarch64: vdso symbols #1292
Conversation
|
I am aware, please note this is not the final version:
|
47179e1
to
607d20d
Compare
qlib/kernel/loader/vdso.rs
Outdated
|
||
#[cfg(target_arch = "x86_64")] | ||
impl VdsoArchSymbols { | ||
pub fn set_symbols_page_offset(&mut self, elf_file: &ElfFile, symbol_table: &[Entry64]) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code is assuming that vdso is one single page right? Perhaps add a memory limit in the linker script to make sure of that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ping. could you also do this? perhaps in another PR.
if the vdso object goes beyond (not likely but not impossible) one page, the parser code may go wrong.
|
||
pub fn set_symbols_page_offset(&mut self, elf_file: &ElfFile, symbol_table: &[Entry64]) { | ||
let mut found_symbols = 0; | ||
for sym in 0..Self::TOTAL_SYMBOLS { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
qkernel already uses the hashbrown
, a KV store would make life easier here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, too much underling complexity for such a minimal case...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the complexity of using a hashmap, when the alternative is a nested for loop with strcmp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it is done only once, for an unnoticeable small number of elements, with unnoticeable short names as keys and very simple logic for to mess it up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: not just once. Every time a signal happens the kernel for loop through the list and strcmp up to 4 times to find the sigreturn symbol. Not a big difference with only 4 elements though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: not just once.
Sorry, I didn't specify that I meant storing.
up to 4 times to find the sigreturn symbol.
As we are (for now) only concerned with sigreturn,
it could be placed at [0].
... but again:
Not a big difference with only 4 elements though.
P.S. I just learned what 'nit' means :)
607d20d
to
2e823f1
Compare
* Definition for vdso symbol * New struct for aarch64 * Dummy struct for x86_64
2e823f1
to
ee6f075
Compare
clear warnings for x86_64 build
ee6f075
to
836f7c2
Compare
let mut _vdso_symbols: VdsoArchSymbols = Default::default(); | ||
_vdso_symbols.set_symbols_page_offset(&elf_file, symbols); | ||
self.vdso_symbols = Some(_vdso_symbols); | ||
} else if cfg!(target_arch = "aarch64") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is cfg!
macro compile time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, and it was not meant so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from a distance perhaps some commits could be squashed, otherwise looks fine to me.
@chl337 what's the current status for the PR and could we merge this? |
Just for sanity, please test it on your machine first. Then it can be merged. |
@chl337 it is tested in my side. No issue. Can you merge it or I can do? |
Then please proceed. |
TODO:
replace hard-coded vdso-symbol value with queryrefactorrebasetest on x86 machine for sanity