From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id EBE343858D28 for ; Tue, 12 Apr 2022 13:42:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EBE343858D28 Received: by mail-ej1-x62e.google.com with SMTP id i27so37429368ejd.9 for ; Tue, 12 Apr 2022 06:42:05 -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=X1Cb1glv/VMIQp5Lo/5Qc7SjbtgQnpAElJGRTKGXxQk=; b=hVf9WuLCsYnCQAB3RKXQm+Sx/Bn8wY3OaPglt+/YY4qwvXSLXpP4BcfkrJxGOFqye3 iQPIU67SXKqHnoOIcb6rFYdBL6i1IJnm85AUNDOGz2DBT7kKx/ZZROKgJL2ZDSiTRK94 lDrtYhM1+phLF2P3AKDb7FsxyB4UL7W8YBFjSTJEMGWyqiueW59ypKAszAwgc69KCpyg edWwB0AqKZpq5eq7rJ0LyCEBEOZDSiF7v9K4SzfNV9b8bOpmrOzR30g2QyUzKSvEyRlu AmUAu6oB3GIqGg4Ee3nHTm3VkqK+A/140n6XoB95nYA1qbAlHZkqWqdnTkm0VM7vATlX zHQA== X-Gm-Message-State: AOAM532ClX82Dkvs7T1HFcWDdbuc7UTnqPFsRpwpmWTklff6CIE0nZ9z dd1vt2o1ZJIwJMc3LGJMQihfgJv3m0zsreL9XSE= X-Google-Smtp-Source: ABdhPJwsBa2V5IxrFqABE15Ma8lIS8J/ZDa5f+HLFEh9/bEcThOPNvb90d6aQaPcaW7dGGolEDSYDs+LjfKBFd/N+7M= X-Received: by 2002:a17:907:8a14:b0:6e8:9691:62f7 with SMTP id sc20-20020a1709078a1400b006e8969162f7mr8175659ejc.497.1649770924527; Tue, 12 Apr 2022 06:42:04 -0700 (PDT) MIME-Version: 1.0 References: <7B167841-0CDA-4084-A160-62C625B85486@gmail.com> <57c21fe6-4992-f54d-3f90-b1c4c9fa7b98@suse.cz> <858304E4-5B02-4164-8E5B-16C2385A30E7@googlemail.com> In-Reply-To: <858304E4-5B02-4164-8E5B-16C2385A30E7@googlemail.com> From: Richard Biener Date: Tue, 12 Apr 2022 15:41:53 +0200 Message-ID: Subject: Re: [GSoC]Bypass assembler when generating LTO object files To: Iain Sandoe Cc: Martin Liska , Jan Hubicka , GCC Development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 13:42:08 -0000 On Tue, Apr 12, 2022 at 2:53 PM Iain Sandoe wrote= : > > > > > On 12 Apr 2022, at 13:31, Martin Li=C5=A1ka wrote: > > > > On 4/12/22 11:58, Richard Biener wrote: > >> On Tue, Apr 12, 2022 at 11:20 AM Jan Hubicka via Gcc = wrote: > >>> > >>> Hi, > >>>> > >>>> > >>>>> On 08-Apr-2022, at 6:32 PM, Jan Hubicka w= rote: > >>>>> > >>>>> Ankur, > >>>>>> I was browsing the list of submitted GSoC projects this year and t= he > >>>>>> project regarding bypassing assembler when generating LTO object f= iles > >>>>>> caught my eye. > >>>>> I apologize for late reply. I would be very happy to mentor this > >>>>> project. > >>>> > >>>> Thanks for the reply, but unfortunately, due to some reasons, I woul= d not > >>>> be able to take part in GSoC this year. > >>>> But the project seems interesting and would be amazing opportunity t= o > >>>> learn a lot more things for me, so would it be okay if I try to give= it a > >>>> go outside GSoC if no-one else picks it as their GSoC project this y= ear ? > >>> > >>> I would be still very happy to help with that! However it would be al= so > >>> pity to not take part of GSoC, so if there is something I can help wi= th > >>> on that let me know. > >>>> > >>>>>> > >>>>>> I already have a gcc built from source (sync-ed with trunk/master)= and > >>>>>> launched the test-suite on it. > >>>>>> > >>>>>> I am currently in process of understanding the primilary patch > >>>>>> (https://gcc.gnu.org/legacy-ml/gcc/2014-09/msg00340.html), and > >>>>>> experimenting with it. > >>>>>> > >>>>>> are there any other things I should be aware of (useful Doc/blog o= r a > >>>>>> bug tracking the project) before proceeding further ? > >>>>> > >>>>> I think it is pretty much all that exists. Basically we will need = to > >>>>> implement everything that is necessary to stream out valid object f= ile > >>>>> directly from GCC rather than going through gas. The experimental > >>>>> prototype sort of worked but it was lacking few things. > >>>> > >>>> When I try to apply that patch on my local branch ( branched from tr= unk ), > >>>> it seem to be incompatible with the current working tree. Is there a > >>>> specific branch that I have to apply it to ? or is it due to the rec= ent > >>>> file rename patch ( changing extensions from .c to .cc ) ? > >>>> > >>>> ``` > >>>> $ git apply --check bypass_asm_patch > >>>> > >>>> error: patch failed: Makefile.in:1300 > >>>> error: Makefile.in: patch does not apply > >>>> error: common.opt: No such file or directory > >>>> error: langhooks.c: No such file or directory > >>>> error: lto/Make-lang.in: No such file or directory > >>>> error: lto/lto-object.c: No such file or directory > >>>> error: lto/lto.c: No such file or directory > >>>> error: lto/lto.h: No such file or directory > >>>> error: lto-streamer.h: No such file or directory > >>>> error: toplev.c: No such file or directory > >>>> ``` > >>> > >>> I can try to update the patch, or it probably should apply to trunk > >>> checked out around the date I sent the patch. Indeed we need to chan= ge > >>> c to cc but there are likely more changes since then - most importnat= ly > >>> the early debug info. > >>> At I will see how easy/hard is to make the patch build with current > >>> trunk. > >> We do have ideas for the early debug with the asm-out abstraction to > >> also solve a different issue (missing simple-object support for mingw/= darwin). > > > > Note the debug info will be stored to a different .s file, then the fil= e > > will be converted .o by GAS and then the bytecode will be stored to an = ELF > > section of a compiled object. I've got also binutils patch when we'll > > be able to directly use the embedded section with compile.o@offset. > > Which will not work, as written, for Darwin since that is neither ELF nor= does it > use GAS - but hopefully, we can find some equivalent mechanism (there is = already > some support in the Darwin backend for switching asm context for LTO outp= ut). I think using compile.o@offset will be optional and the fallback is to extract the "file" back to a regular object file just containing debug info like we do currently but with the difference that we do not need to understand the object format since it is created "correctly" by the assembler during compile-time (and we just= use the compile-object as a container to not confuse build systems). > >> Namely assemble the early debug in a different file and include the re= sulting > >> native object in binary form in the compile output - not needing to wr= ite > >> assembly .data for that would be a good way to make this more viable. > > > > Btw. do you have any estimation how slow is GAS when we speak about deb= ug info? > > How much time can we save since the latest speed-up achieved by GAS? > > > >> You might want to talk to Martin Liska for this who I think had some > >> prototype on this? > > > > I can provide a prototype if needed. > > I=E2=80=99d like to be in to loop from the Darwin PoV.. > thanks > Iain > > > > > Cheers, > > Martin > > > >> Richard. > >>> Honza > >>>> > >>>> Thanks > >>>> - Ankur >