froydnj opened Issue #1283:
While trying to update lucet to the most recent cranelift, I ran into some issues that stemmed from bytecodealliance/cranelift#1209 changing the semantics of what zero-initialized data did. Previously, zero-initialized data was essentially just like normal data, except that cranelift-module took care of generating the initial vector of zeros to modify. After that PR, zero-initialized data now had special semantics of not actually existing in the generated object, but living in
.bss
(or similar) and being zero-initialized by the runtime loader.This was an excellent change! However,
lucetc
depended on the old behavior, in particular the application of relocations to the declared data. I thinklucetc
's behavior is wrong, and I intend to write up a PR for that.I don't think relocations (
declare_func_in_data
, etc.) should actually apply to zero-initialized data...but cranelift-module happily lets you declare zero-initialized data and also declare that there should be various relocations applied to said data, which I don't think is going to translate well. (If it is supposed to translate well, faerie, at least, currently has bugs in that area.)Is that line of thinking correct, i.e. there should be some additional checks around:
regarding zero-initialized data prior to handing things off to the backend?
fitzgen labeled Issue #1283:
While trying to update lucet to the most recent cranelift, I ran into some issues that stemmed from bytecodealliance/cranelift#1209 changing the semantics of what zero-initialized data did. Previously, zero-initialized data was essentially just like normal data, except that cranelift-module took care of generating the initial vector of zeros to modify. After that PR, zero-initialized data now had special semantics of not actually existing in the generated object, but living in
.bss
(or similar) and being zero-initialized by the runtime loader.This was an excellent change! However,
lucetc
depended on the old behavior, in particular the application of relocations to the declared data. I thinklucetc
's behavior is wrong, and I intend to write up a PR for that.I don't think relocations (
declare_func_in_data
, etc.) should actually apply to zero-initialized data...but cranelift-module happily lets you declare zero-initialized data and also declare that there should be various relocations applied to said data, which I don't think is going to translate well. (If it is supposed to translate well, faerie, at least, currently has bugs in that area.)Is that line of thinking correct, i.e. there should be some additional checks around:
regarding zero-initialized data prior to handing things off to the backend?
philipc commented on Issue #1283:
Yeah,
cranelift-object
won't handle this correctly either. If it had to, the best it could do is choose which section based on the number of relocs (similiar to what read only data does). But I don't see a problem with disallowing these relocations incranelift-module
.
Last updated: Dec 23 2024 at 12:05 UTC