From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id E59543858D28 for ; Fri, 8 Apr 2022 13:02:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E59543858D28 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 44691280BD5; Fri, 8 Apr 2022 15:02:30 +0200 (CEST) Date: Fri, 8 Apr 2022 15:02:30 +0200 From: Jan Hubicka To: Ankur Saini Cc: gcc@gcc.gnu.org Subject: Re: [GSoC]Bypass assembler when generating LTO object files Message-ID: References: <7B167841-0CDA-4084-A160-62C625B85486@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7B167841-0CDA-4084-A160-62C625B85486@gmail.com> X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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: Fri, 08 Apr 2022 13:02:33 -0000 Ankur, > I was browsing the list of submitted GSoC projects this year and the > project regarding bypassing assembler when generating LTO object files > caught my eye. I apologize for late reply. I would be very happy to mentor this project. > > 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 or 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 file directly from GCC rather than going through gas. The experimental prototype sort of worked but it was lacking few things. First is the production of proper object file hearder (it encodes things like architeture ELF is produced for), production of symbol table that is necessary to mark the LTO object file and also we now need a way to stream debug info (DWARF) directly to the object from dwarf2out. So I think first step would be to produce object files w/o debug info which can be consumed by unmodified linkers and then look into DWARF bytecode streaming. Honza > > I am Ankur Saini, a B.Tech CSE 3rd year student at USICT, GGSIPU india > and a former GSoC contributor at gcc ( worked on expanding gcc static > analyzer's C++ support in GSoC 2021 > [https://gist.github.com/Arsenic-ATG/8f4ac194f460dd9b2c78cf51af39afef]) > > Thanks > - Ankur