On Tue, May 24, 2022 at 5:45 PM Gaius Mulley <gaiusm...@gmail.com> wrote: > > Richard Biener <richard.guent...@gmail.com> writes: > > > On Sat, May 21, 2022 at 3:11 AM Gaius Mulley <gaiusm...@gmail.com> wrote: > >> > >> > >> Hi, > >> > >> Gaius wrote: > >> > >> > the changes do raise questions. The reason for the changes here are to > >> > allow easy linking for modula-2 users. > >> > >> > $ gm2 hello.mod > >> > >> > for example will compile and link with all dependent modules (dependants > >> > are generated by analysing module source imports). The gm2 driver will > >> > add objects and libraries to the link. > >> > >> in more detail the gm2 driver does the following: > >> > >> $ gm2 -v hello.mod > >> > >> full output below, but to summarise and annotate: > >> > >> cc1gm2 generates an assembler file from hello.mod > >> as --64 /tmp/cc8BoL3d.s -o hello.o > >> > >> # gm2l generates a list of all dependent modules from parsing all imports > >> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/gm2l -v \ > >> -I/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim -o \ > >> /tmp/ccSMojUb.l hello.mod > >> > >> # gm2lorder reorders the critical runtime modules > >> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/gm2lorder \ > >> /tmp/ccSMojUb.l -o /tmp/ccHDRdde.lst > >> > >> # gm2lgen generates a C++ scaffold from the reordered module list > >> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/gm2lgen -fcpp \ > >> /tmp/ccHDRdde.lst -o a-hello_m2.cpp > >> > >> # cc1plus compiles the scaffold > >> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/cc1plus -v \ > >> -mtune=generic -march=x86-64 \ > >> -I/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim \ > >> -quiet a-hello_m2.cpp -o a-hello_m2.s > >> as --64 a-hello_m2.s -o a-hello_m2.o > >> > >> # gm2lcc creates an archive from the list of modules and the scaffold > >> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/gm2lcc \ > >> -L/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim \ > >> -ftarget-ar=/usr/bin/ar -ftarget-ranlib=/usr/bin/ranlib \ > >> -fobject-path=/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim \ > >> --exec --startup a-hello_m2.o --ar -o /tmp/ccNJ60fa.a --mainobject \ > >> a-hello_m2.o /tmp/ccHDRdde.lst > >> > >> /usr/bin/ar rc /tmp/ccNJ60fa.a hello.o a-hello_m2.o > >> /usr/bin/ranlib /tmp/ccNJ60fa.a
So is there a reason to have the 'scaffold' separate from the object of hello.mod? Is there more than a 1:1 relation between a .mod and the 'scaffold'? Why are multiple tools involved here - can the m2 frontend not parse imports, reorder runtime modules and generate the 'scaffold' as GENERIC IL as part of the translation unit of the .mod file? Indirection through emitting C++ source code makes the process a bit awkward IMHO. Unfortunately I have no m2 installation around to look at how complex the 'scaffold' is. > >> # finally collect2 performs the link from the archive and any default > >> libraries > >> > >> hope this helps > > > > Yes, it does. So historically when there was complex massaging required > > like this it was offloaded to a "helper driver". With -flto there's > > lto-wrapper > > (but here invoked by the linker), with ada there's gnatmake and others > > and with certain targets collect2 does extra processing producing global > > CTORs (or for C++ with -frepo even invoked additional compilations). > > Hi Richard, > > interesting thank you for the information about different languages (yes > I recall years ago the lang-specs used to be much more complex). global > CTORs would work might be helpful, although I wonder if they are overly > complex for modula-2? (As we still need to control order). I guess > there would be pros/cons for multi-lingual projects. > > I wonder whether it could be resolved in the modula-2 front end by > placing the scaffold generation inside cc1gm2 (which is generated when a > program module is seen - and/or perhaps forced by a switch if a user > really wanted to link an implementation module as the application, > say by -fm2-scaffold). So by default the proposal would be that > > $ gm2 -c programmodule.mod > > generates programmodule.o (which contains main and a scaffold to > construct/deconstruct every module as well as the user level code). > There could be a switch to emit the scaffold in C or C++ should users > want to interfere. > > Overall much of the modula-2 code inside /gm2tools would go into cc1gm2 > and many 100s of C lines of code would disappear from the 'gm2' driver > and the code base would clean up :-). In the process it would become > more like the other GCC language drivers. > > Some of the gm2 link options could be passed into cc1gm2 (those forcing > the order of module initialization and user specified scaffold list > override). The make dependencies could also be emitted if required > as cc1gm2 now has knowledge of all imports. > > > I do think that this might all belong into the main driver code but then > > maybe all the different language compilation models will just make that > > very hard to maintain. > > indeed I can see it could become problematic making the above quite > attractive, maybe? > > > As for modula-2, does > > > > $ gm2 -c hello.mod > > $ ~/opt/bin/gm2 -c hello.mod > > > $ gm2 hello.o > > $ ~/opt/bin/gm2 hello.o > /usr/bin/ld: /lib/x86_64-linux-gnu/crt1.o: in function `_start': > (.text+0x20): undefined reference to `main' > collect2: error: ld returned 1 exit status > > alas no as there is no scaffold inside hello.o > > > "work"? And what intermediate files are build systems expecting to > > prevail? Like for C/C++ code and GNU make there's the preprocessor > > driven dependence generation, but otherwise a single TU usually > > produces a single object file. OTOH for GFortran a single TU might > > produce multiple .mod files for example. > > currently in gm2 there is the single .o file and possibly a .i swig file > if -fswig is present. (There is a gm2m tool which is not currently > deployed - this could be pruned and integrated into cc1gm2 - to generate > make dependencies). > > > Btw, does > > > > $ gcc -c hello.mod > > yes, well to a degree: > > $ ~/opt/bin/gcc -c hello.mod > <built-in>: error: the file containing the definition module ‘SYSTEM’ > cannot be found > > but if we supply the include path then all is ok (maybe the default path > should be embedded into cc1gm2). > > $ ~/opt/bin/gcc -c > -I/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim hello.mod > $ > > > "work" (or with -x m2 if the extension isn't auto detected)? > > sure yes (all handled via the lang-specs.h) > > regards, > Gaius
