Thanks, Jan for the Reply! I have completed a draft proposal for this project. I will appreciate your's, Martin's, or anybody else feedback on the same. Here is the link to my proposal https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs5U0sDpwFUtts/edit?usp=sharing
On Tue, 4 Apr 2023 at 04:35, Jan Hubicka <hubi...@ucw.cz> wrote: > Hello, > > While going through the patch and simple-object.c I understood that the > > file simple-object.c is used to handle the object file format. However, > > this file does not contain all the architecture information required for > > LTO object files, so the workaround used in the patch is to read the > > crtbegin.o file and merge the missing attributes. While this workaround > is > > functional, it is not optimal, and the ideal solution would be to extend > > simple-object.c to include the missing information. > > Yes, simple-object.c simply uses architecture settings it read earlier > which is problem since at compile time we do not read any object files, > just parse sources). In my original patch the architecture flags were > simply left blank. I am not sure if there is a version reading > crtbeing.o which would probably not a be that bad workaround, at least > for the start. Having a way to specify this from the machine descriptions > would be better. > > > Besides the architecture bits, for simple-object files to work we need > to add the symbol table. For practically useful information we also need > to stream the debug info. > > > > Regarding the phrase "Support in the driver to properly execute *1 > binary", > > it is not entirely clear what it refers to. My interpretation is that the > > compiler driver (the program that coordinates the compilation process) > > needs to be modified to correctly output LTO object files instead of > > assembler files (the current approach involves passing the -S and -o > > <obj_file_name>.o options) and also skip the assembler option while using > > -fbypass-asm option but I am not sure. Can Jan or Martin please shed some > > light on this? > Yes, compiler drivers decides what to do and it needs to know that with > -flto it does not need to produce assembly file and then invoke gas. If > we go the way of reading in crtbegin.o it will also need to pass correct > crtbegin to *1 binary. This is generally not that hard to do, just > needs to be done :) > Honza > > > > Thanks & Regards > > > > Rishi Raj > > > > On Sun, 2 Apr 2023 at 03:05, Rishi Raj <rishiraj45...@gmail.com> wrote: > > > > > Hii Everyone, > > > I had already expressed my interest in the " Bypass assembler when > > > generating LTO object files" project and making a proposal for the > same. I > > > know I should have done it earlier but I was admitted to the hospital > for > > > past few days :(. > > > I have a few doubts. > > > 1) > > > > > > "One problem is that the object files produced by > libiberty/simple-object.c > > > (which is the low-level API used by the LTO code) > > > are missing some information (such as the architecture info and symbol > > > table) and API of the simple object will need to be extended to handle > > > that" I found this in the previous mailing list discussion. So who > output this information currently in the object file, is it assembler? > > > > > > Also in the current patch for this project by Jan Hubica, from where > are we getting these information from? Is it from crtbegin.o? > > > > > > 2) > > > "Support in driver to properly execute *1 binary." I found this on Jan > original patch's email. what does it mean > > > > > > exactly? > > > > > > Regards > > > > > > Rishi Raj > > > > > > > > > > > > >
