Wasmtime GitHub notifications bot (May 01 2020 at 05:23): Wasmtime GitHub notifications bot (May 01 2020 at 05:23):carlokok opened Issue #1640:
Currently data always goes into the readonly or writeable data section. However COFF, ELF and Mach-O all support custom named sections.
Feature
Essentially allow specifying the name of the section when defining data.
Benefit
This will have multiple benefits:
- On OSX this allows one to emit objc classes (Objc classes are required to be defined in special sections, which the objc runtime finds)
On other platforms (Linux, Windows, even WASM with LLVM) this allows one to find the begin and end of a list of data which at compile time isn't defined yet(linux sample):
extern void* __start_mysec;
extern void* __stop_mysec;__section("mysec") void* item1 = &somedatastructure;
__section("mysec") void* item2 = &somedatastructure;The default linkers will hook up __start and __stop to the first and last entry in the final executable.
Implementation
This could simply be accomplished by an additional parameter on define_data that has a default. The backends could use this to specify the section this will go in.
Wasmtime GitHub notifications bot (May 11 2020 at 17:52):pchickey commented on Issue #1640:
This is a reasonable need. I'm not sure what the best way to design it is, though.
Currently, the backend does a lot of calculation based on the properties of data (is it zeroed or initialized, is it tls, read-only, contains relocations, etc) to determine what section it lands in. It determines the names of those sections based on the binary format. I worry about exposing a generic escape hatch to that functionality, which will complicate backends and break a bunch of encapsulation where users of cranelift-module don't have to know any details about the binary format.
We went down the path of breaking that encapsulation by exposing relocation escape hatches in Faerie and it made a real mess. I'd like to avoid it if possible.
Rather than expose that escape hatch, is there a smaller set of requirements we can build on? Do you have a specific use case for section start and stop symbols? Those could probably be accommodated with a mechanism that doesn't break encapsulation and works for every binary format. (I don't know anything about how Objc classes work, so I can't guess whether there's some more general mechanism that would work for those, obviously that is a Mach-O specific convention)
Wasmtime GitHub notifications bot (May 11 2020 at 18:10):carlokok commented on Issue #1640:
Fair enough. And I understand not all backends support this or should support this. But using section naming isn't all that uncommon. I use it my self to store and find the list of know rtti types.
My compiler (RemObjects elements) has rrti in read-only data as normal. But one of the fields refers to a pointer in the special elrrti section, and that pointer refers back to the rtti. This seems pointless but on Mac and windows I can get a section by name and the get the list of types linked in at runtime without actually creating hard dependencies. On Linux I use start en stop symbols to get the same effect.
I realize there might be workarounds for some stuff, but this has tons of usecases. (For example, some metadata like tls on windows is required to be in special sections).
That said it seems overkill to break the api for this feature few will need directly. But maybe something that could attach a preferred section to a DataId? Then backends that support it, like object could use that as a preference? (Just an idea)
Wasmtime GitHub notifications bot (May 11 2020 at 18:13):bjorn3 commented on Issue #1640:
(For example, some metadata like tls on windows is required to be in special sections).
There is already a tls flag. It isn't implemented for windows right now though.
Wasmtime GitHub notifications bot (May 11 2020 at 18:18):carlokok commented on Issue #1640:
@bjorn3 if you want to link without a depency on msvcrt or other runtime there are extra sections needed to get a working exe ttps://github.com/remobjects/IslandRTL/blob/master/Source/WindowsHelpers.pas#L586
See the vars with [section attributes (sorry, Pascal). But that was just on of many examples this can be used for.
Wasmtime GitHub notifications bot (May 11 2020 at 18:18):carlokok edited a comment on Issue #1640:
@bjorn3 if you want to link without a depency on msvcrt or other runtime there are extra sections needed to get a working exe https://github.com/remobjects/IslandRTL/blob/master/Source/WindowsHelpers.pas#L586
See the vars with [section attributes (sorry, Pascal). But that was just on of many examples this can be used for.
Wasmtime GitHub notifications bot (May 11 2020 at 18:21):carlokok edited a comment on Issue #1640:
@bjorn3 if you want to link without a depency on msvcrt or other runtime there are extra sections needed to get a working exe https://github.com/remobjects/IslandRTL/blob/master/Source/WindowsHelpers.pas#L586
See the vars with [sectionname attributes (sorry, Pascal). But that was just on of many examples this can be used for.
Wasmtime GitHub notifications bot (May 19 2020 at 18:29):pchickey commented on Issue #1640:
Sorry, I never got back to this. I think adding an optional section name to a DataDescription that is set with a DataContext method is the most reasonable way forward with this. Since you'll probably be the only one using the feature, I'll ask that you create that PR and implement it in at least the cranelift-object backend.
I don't think there are any active users of cranelift-faerie anymore, it has been supplanted by object, but we are keeping it in tree for now just in case theres some object bug that we need to workaround briefly by reverting back to faerie.
Wasmtime GitHub notifications bot (May 19 2020 at 18:29):pchickey edited a comment on Issue #1640:
Sorry, I never got back to this. I think adding an optional section name to a DataDescription that is set with a DataContext method is the most reasonable way forward with this. Since you'll probably be the only one using the feature, I'll ask that you create that PR and implement it in at least the cranelift-object backend. Mark me as a reviewer and I promise to get to it sooner than I got back to this conversation :)
I don't think there are any active users of cranelift-faerie anymore, it has been supplanted by object, but we are keeping it in tree for now just in case theres some object bug that we need to workaround briefly by reverting back to faerie.
Wasmtime GitHub notifications bot (May 20 2020 at 05:13):carlokok commented on Issue #1640:
Perfect; I'm not sure when I can get to it, but I'll start working on this as soon as I can.
Wasmtime GitHub notifications bot (May 20 2020 at 09:17):bjorn3 commented on Issue #1640:
Since you'll probably be the only one using the feature
It would be useful for cg_clif too.
Wasmtime GitHub notifications bot (Jun 17 2020 at 17:49):pchickey closed Issue #1640:
Currently data always goes into the readonly or writeable data section. However COFF, ELF and Mach-O all support custom named sections.
Feature
Essentially allow specifying the name of the section when defining data.
Benefit
This will have multiple benefits:
- On OSX this allows one to emit objc classes (Objc classes are required to be defined in special sections, which the objc runtime finds)
On other platforms (Linux, Windows, even WASM with LLVM) this allows one to find the begin and end of a list of data which at compile time isn't defined yet(linux sample):
extern void* __start_mysec;
extern void* __stop_mysec;__section("mysec") void* item1 = &somedatastructure;
__section("mysec") void* item2 = &somedatastructure;The default linkers will hook up __start and __stop to the first and last entry in the final executable.
Implementation
This could simply be accomplished by an additional parameter on define_data that has a default. The backends could use this to specify the section this will go in.
Last updated: Dec 23 2024 at 13:07 UTC