From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) by sourceware.org (Postfix) with ESMTPS id 082ED3857423 for ; Wed, 25 May 2022 09:10:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 082ED3857423 Received: by mail-qk1-x72c.google.com with SMTP id r84so5430948qke.10 for ; Wed, 25 May 2022 02:10:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7SPZYoeJdJ8twsYMsNRDd0D0Pd9gt9uCHe3suWou/QU=; b=DsaU6waUwl8C5dvdmiuMI+FTN/k3FhkvMAvEl+FshkggoNnrtdG4lv7janHtsfxxr5 n3b8EDjYxJpIiSaPXzetNNYC+g/8QIe6t/w4HBk/54tTh0uTmoojhnw7wbHxp1QOx2Wi EC7dF/K9IE0PRd3ka2qbaii9WJNGD2Sgm8UqkoBx6eKLuOp/bLz48+Cxk7fAyTU/nDot Pa2CUEPVhorAmmnfPc5wkYei88NsygMqiJR48mDjrxBc9UgIQPZMOtckT/CP/ZNC+RdP CjYfIRUEV0cTfk5rDsEzgYJ+LrLWkTZ8dfKnCI3U6e0T67sXObEgf8MyuGTqbT0RwlF2 BZaw== X-Gm-Message-State: AOAM532UKjNqDCWObwFMZCvR515JTDtQ1aZh7GjTbzCbad4hwOZ0v1ka 3YFviHPR0aOdh6j5MA6NBcEotiCHnUx1VL66Pno= X-Google-Smtp-Source: ABdhPJy8pP0j7oU8tt8pYFkY/hsGPkZLVRWFwaZMkXkJ46Xjuuq1M7uwIl2hwoyKwmgNtVP9oBG9wpwhcqCRA5yPosU= X-Received: by 2002:a05:620a:1907:b0:69f:363b:401f with SMTP id bj7-20020a05620a190700b0069f363b401fmr19575886qkb.627.1653469857319; Wed, 25 May 2022 02:10:57 -0700 (PDT) MIME-Version: 1.0 References: <871qwnvgej.fsf@debian> <87k0abgciu.fsf@debian> In-Reply-To: <87k0abgciu.fsf@debian> From: Richard Biener Date: Wed, 25 May 2022 11:10:45 +0200 Message-ID: Subject: Re: [PATCH] Modula-2: merge proposal/review: 1/9 01.patch-set-01 To: Gaius Mulley Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2022 09:11:00 -0000 On Tue, May 24, 2022 at 5:45 PM Gaius Mulley wrote: > > Richard Biener writes: > > > On Sat, May 21, 2022 at 3:11 AM Gaius Mulley wrot= e: > >> > >> > >> 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 (depend= ants > >> > are generated by analysing module source imports). The gm2 driver w= ill > >> > 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 imp= orts > >> /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=3Dgeneric -march=3Dx86-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=3D/usr/bin/ar -ftarget-ranlib=3D/usr/bin/ranlib \ > >> -fobject-path=3D/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 emit= ting 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 require= d > > like this it was offloaded to a "helper driver". With -flto there's lt= o-wrapper > > (but here invoked by the linker), with ada there's gnatmake and others > > and with certain targets collect2 does extra processing producing globa= l > > 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 the= n > > 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 > : error: the file containing the definition module =E2=80=98S= YSTEM=E2=80=99 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