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

[Gaius Mulley <gaiusmod2@gmail.com>]

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
>>
>> # 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