arne_v wrote: ↑Thu Oct 31, 2024 9:16 pm
$ LINK/CRTL=(XXX,YYY,NOZZZ,NOWWW) ...
?
(the linker would generate a LIB$INITIALIZE that did what was specified and link it in)
If enough people like it then we just need to convince the VSI LINK person to implement it.
Whoever the VSI person/employee is, what if this "LINK person" doesn't like to generate code? "generate a LIB$INITIALIZE" is very generic. Image initialization requires code and a LIB$INITIALIZE PSECT, provided by an object module. (It also requires the linker to include a LIB$INITIALIZE module from STARLET.OLB. The x86 linker does this if it sees a LIB$INITIALIZE PSECT in an (user) object module.) So "generate a LIB$INITIALIZE" translates to generate code and generate a PSECT containing the address of the generated code - and I just ignore that there should be unwind information for the generated code as well. It's probably doable, but from my point of view not worth the effort. There should be a simpler, easier solution.
jreagan wrote: ↑Fri Nov 01, 2024 9:28 am
Maybe a tool to help write that awkward LIB$INITIALIZE contribution?
The compiler, as in
Code: Select all
__attribute__((section(".init_array"))) void (*pfoo)(void) = &foo;
? OK, I know what works on x86 and what not.
But It should be possible to find all the features and with the help of Perl to write the required 20 lines per source module. Or to provide a template(s?) and use sed or any other stream editor to convert that to the wanted source code.
jonesd wrote: ↑Sun Nov 03, 2024 5:53 pm
$ link/vector=(C$FEATURE_INIT,symbol1,symbol2,...)
I don't understand what this means and how this is supposed to work. You may want to add some more explanations/details.
Some questions and comments come to mind. Symbol1, symbol2,... are names. What should the linker write to the C$FEATURE_INIT PSECT? Their values? What are these values, addresses of data? Where are these symbols defined? In object modules that the linker includes when producing the image? Why should the linker create this PSECT rather than the compiler on behalf of the developer from the source code? I don't see why the linker should do this. The only advantage I see is, that the linker can terminate the list and it doesn't need to pull in a module with PSECT wrappers.
If the symbol value is an address, then the data will probably be a list of feature strings like "DECC$ARGV_PARSE_STYLE=TRUE" (or equivalent data). Regardless of what the data is and how the PSECT with the address data is generated, how would DECC$MAIN find the data? At run time of the image, there are no symbols. If you need the symbol to get its value, then you need to lib$fis the image. But this is/was designed only for shareable images. At run-time there are no PSECTs. From what I understand, the main image needs to pass at least one address to the CRTL, that DECC$MAIN can pick up. And that needs to happen before DECC$MAIN is called. Then we are back at image initialization code. But, as I said, I do not (yet) understand all the details of what is suggested.