bjorn3 commented on Issue #1184:
Since #1389
define_function
gets aTrapSink
argument.
froydnj closed Issue #1184:
Feature
lucetc
needs some way of accessing the trap sites for every function it compiles:In the above snippet, the trap site access happens after
Module::finish
has been called, so we're working withfaerie
interfaces.We are trying to port
lucetc
to useobject
instead offaerie
underneath, mostly solucetc
can start generating PE/COFF objects with ease. It would reduce risk somewhat to be able to usecranelift-module
as a high-level interface, swap betweencranelift-object
andcranelift-faerie
with as few lines of code as possible, and deal withobject
andfaerie
themselves as little as possible (probably just to write out the .o file). Therefore, it would be convenient if this information about traps associated with each function were accessible throughcranelift-module
interfaces, rather than through lower-level interfaces.Benefit
Trap information would be more easily accessible prior to module finalization. Though I don't know of anybody else who needs this kind of information about besides
lucetc
at this point.Implementation
This is the tricky bit, because the three in-tree implementations differ substantially in their approach to trap collection:
cranelift-faerie
collects essentially(string-name, Vec<TrapSite>)
pairs.cranelift-object
collects a mapping ofFuncId
toVec<TrapSite>
.cranelift-simplejit
ignores traps entirely.I don't think there is a single method that all three interfaces could easily implement to iterate over
(string-name, &Vec<TrapSite>)
pairs. To implement such an interface,cranelift-object
would need to have a way to map fromFuncId
tostring-name
, and that's awkward to do, given thatobject
itself doesn't deal with symbol names as strings, but asVec<u8>
.The alternative, iterating over
(FuncId, &Vec<TrapSite>)
pairs, would require some kind of modification tocranelift-faerie
. We could changecranelift-faerie
to map fromstring-name
toFuncId
:cranelift-faerie
could grow a separate table for storing that mapping, butcranelift-module
is already storing that mapping, and requiringcranelift-faerie
to store it seems like wasted effort. Alternatively, the waycranelift-faerie
stores its traps could be modified to look more likecranelift-object
.But then maybe the right thing to do is just moving trap collection into
cranelift-module
itself?Module::new
would then grow a flag for indicating whether trap collection should be done.Module
itself would probably contain aFuncId
toVec<TrapSite>
mapping similar tocranelift-object
, and thenBackend::define_function
would receiveOption<&mut Vec<TrapSite>>
for potentially accumulating traps.Since
cranelift-simplejit
doesn't collect traps, it doesn't matter too much what interface gets decided on.I think I prefer moving trap collection into
cranelift-module
itself, but modifyingcranelift-faerie
to make it more likecranelift-object
and the implementing some sort of common iterator interface works, too.Alternatives
The alternative is to keep the status quo, and
lucetc
would need to write two sets of code for defining certain pieces of information: one that defines those pieces withfaerie
and another that defines them withobject
.
Last updated: Dec 23 2024 at 12:05 UTC