Re: [PATCH] Modula-2: merge proposal/review: 1/9 01.patch-set-01

[Richard Biener <richard.guenther@gmail.com>]

On Tue, May 24, 2022 at 5:45 PM Gaius Mulley <gaiusmod2@gmail.com> wrote:
>
> Richard Biener <richard.guenther@gmail.com> writes:
>
> > On Sat, May 21, 2022 at 3:11 AM Gaius Mulley <gaiusmod2@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