Generate global variable accesses and function calls to go via the custom GOT #9
Conversation
src/codegen.rs
Outdated
| } | ||
|
|
||
| let s = | ||
| read_to_string(location).map_err(|_| Diagnostic::new("GOT layout could not be read from file"))?; |
There was a problem hiding this comment.
I think it is clearer to keep the module when calling free-standing public functions like this one, so I would rather see this:
| read_to_string(location).map_err(|_| Diagnostic::new("GOT layout could not be read from file"))?; | |
| fs::read_to_string(location).map_err(|_| Diagnostic::new("GOT layout could not be read from file"))?; |
and remove the import for fs::{read_to_string, write} in favor of an import of fs. this is definitely a nit so feel free to ignore, just easier for me to read the code
src/codegen.rs
Outdated
| PouIndexEntry::Function { name, linkage: LinkageType::Internal, is_generated: false, .. } | ||
| | PouIndexEntry::Function { name, linkage: LinkageType::Internal, .. } => Some(name.as_ref()), |
There was a problem hiding this comment.
maybe I'm not thinking hard enough but isn't that or-pattern redundant? if we are filtering on all PouIndexEntry::Functions that have internal linkage and which have is_generated set to false, but also on all the PouIndexEntry::Functions where that last condition isn't necessarily upheld (and is by thus true), then I feel like the first part of the pattern isn't necessary?
| PouIndexEntry::Function { name, linkage: LinkageType::Internal, is_generated: false, .. } | |
| | PouIndexEntry::Function { name, linkage: LinkageType::Internal, .. } => Some(name.as_ref()), | |
| PouIndexEntry::Function { name, linkage: LinkageType::Internal, .. } => Some(name.as_ref()), |
There was a problem hiding this comment.
Ah good catch the second line should be PouIndexEntry::FunctionBlock
| .context | ||
| .i64_type() | ||
| .const_int(0xdeadbeef00000000, false) | ||
| .const_to_pointer(llvm_type.ptr_type(0.into()).ptr_type(0.into())); |
There was a problem hiding this comment.
| .const_to_pointer(llvm_type.ptr_type(0.into()).ptr_type(0.into())); | |
| .const_to_pointer(llvm_type.ptr_type(AddressSpace::default()) | |
| .ptr_type(AddressSpace::default())); |
nit, but maybe clearer?
This commit introduces the association of GOT indices to the LLVM index, which then allows us to utilise that when generating references to variables to check if a given variable has an entry in the GOT. If so, we obtain its index, and generate the necessary LLVM IR to access the address contained within the GOT rather than accessing the variable directly.
lewis-revill
force-pushed
the
ljr-custom-got-globals
branch
from
d706b10
to
e80995a
Compare
| .context | ||
| .i64_type() | ||
| .const_int(0xdeadbeef00000000, false) | ||
| .const_to_pointer(llvm_type |
There was a problem hiding this comment.
| .const_to_pointer(llvm_type | |
| .const_to_pointer(function_type |
typo?
src/codegen.rs
Outdated
| fs::write(location, s).map_err(|_| Diagnostic::new("GOT layout could not be written to file"))?; | ||
| Ok(()) |
There was a problem hiding this comment.
| fs::write(location, s).map_err(|_| Diagnostic::new("GOT layout could not be written to file"))?; | |
| Ok(()) | |
| fs::write(location, s).map_err(|_| Diagnostic::new("GOT layout could not be written to file")) |
this can be simplified a little bit since you map the error properly already
This change involves moving the generation of the GOT from variable_generator.rs to codegen.rs, in order to also cover not only global variables but also functions and 'programs' too. Once these have been given an associated index in the GOT we can use that to replace normal direct function calls with indirect calls to a function pointer stored in the GOT. We don't do this for calls with external linkage since these won't be subject to online change.
lewis-revill
force-pushed
the
ljr-custom-got-globals
branch
from
e80995a
to
c9a08a9
Compare
These patches contain changes to replace normal global variable accesses and direct function calls with an additional level of indirection through the custom GOT. Until load time this custom GOT must just be represented as a magic constant.
We may not cover all the possible paths that generate global accesses, and there is slight duplication of code between
generate_got_accessandgenerate_got_call. We also will want to use a crate to provide us with the definition of the magic constant rather than hardcoding it.