[GSOC] Looking for small patch/project to work on
Hi everyone, My name is Rishi Raj, and I am a third-year undergraduate studying Computer Science and Engineering at the Indian Institute of Technology Kharagpur in India. I wish to participate in this year's GSOC with GCC. My progress so far: 1. Successfully built the GCC from source using the installing gcc guide. (I will run the test suite today.) 2. Read about different configuration options during installations and also went through the gcc-newbies-guide, which was an exciting read and provided an overview of how to proceed in gcc-contribution. I want to extend my appreciation to David for this. After reading about the suggested projects described on GCC's GSOC page, I found "Bypass assembler when generating LTO object files" and "C++: Implement compiler built-in traits for the standard library traits" interesting. Currently, I am examining the preliminary patch https://gcc.gnu.org/ml/gcc/2014-09/msg00340.html for the first project. I can work on a small project/patch after this in a day or two. I would greatly appreciate your suggestions for the same. I have taken compiler theory and laboratory courses as a part of my institute curriculum. In the laboratory, we designed a tiny-c compiler (a subset of GCC). In theory, I learned about different phases of compilations, various optimization techniques, etc. Please find my course website link for a detailed overview: https://cse.iitkgp.ac.in/~bivasm/compiler2022.html#Lecture This course was the starting point of my interest in compiler development, and I want to take it further by making meaningful contributions to GCC. I hope to make some significant contributions to GCC this summer and in the future. I would appreciate any suggestions on taking on a small patch/project or delving deeper into the projects I am interested in pursuing. Best regards, Rishi Raj
Re: Gcc Digest, Vol 37, Issue 8
Thanks, David and Martin, for the heads up, and I am sorry for the late reply due to health issues. Anyways I could emit the warning "hello world, I am function foo.". After that, I tried debugging using the` ../gcc -wrapper gdb test.c`(gcc binary is in parent folder) but I am getting this error "gdb: unrecognized option '-dumpdir' Use `gdb --help' for a complete list of options.". I googled it and got this on Bugzilla (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53195), but it has already been fixed. These are the gdb configurations during the build: Using built-in specs. COLLECT_GCC=../gcc COLLECT_LTO_WRAPPER=gcc-dir/libexec/gcc/x86_64-pc-linux-gnu/12.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../project/configure --prefix=gcc-dir --enable-languages=c,c++ --disable-bootstrap Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.1 20230302 [OG12] (GCC) COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-' Can anyone point out how to resolve this or if I am missing something during build? Thanks and regards Rishi Raj On Tue, 7 Mar 2023 at 17:30, wrote: > Send Gcc mailing list submissions to > gcc@gcc.gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://gcc.gnu.org/mailman/listinfo/gcc > or, via email, send a message with subject or body 'help' to > gcc-requ...@gcc.gnu.org > > You can reach the person managing the list at > gcc-ow...@gcc.gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gcc digest..." > Today's Topics: > >1. Re: [GSOC] Looking for small patch/project to work on > (David Malcolm) >2. Re: Request for participation in GSoC (David Malcolm) >3. Re: [GSoC] Introduction and query on LTO object emmission > project (David Malcolm) >4. Clarification on newlib version for building AMDGCN > offloading backend (Wileam Yonatan Phan) > > > > -- Forwarded message -- > From: David Malcolm > To: Rishi Raj , gcc@gcc.gnu.org > Cc: > Bcc: > Date: Mon, 06 Mar 2023 11:25:16 -0500 > Subject: Re: [GSOC] Looking for small patch/project to work on > On Sat, 2023-03-04 at 08:11 +0530, Rishi Raj via Gcc wrote: > > Hi everyone, > > Hi, and welcome! > > > > > My name is Rishi Raj, and I am a third-year undergraduate studying > > Computer > > Science and Engineering at the Indian Institute of Technology > > Kharagpur in > > India. I wish to participate in this year's GSOC with GCC. > > > > My progress so far: > > > >1. Successfully built the GCC from source using the installing gcc > >guide. (I will run the test suite today.) > >2. Read about different configuration options during installations > > and > >also went through the gcc-newbies-guide, which was an exciting > > read and > >provided an overview of how to proceed in gcc-contribution. I want > > to > >extend my appreciation to David for this. > > Thanks. You've already built GCC from source, which is a great start. > A good thing to try next (if you haven't already) would be to try > hacking in a warning that emits: > "hello world, I'm compiling function 'foo'" > for each function being compiled, and compile something with that... > and then do it again in the debugger, with a breakpoint on that, and > step through some of the code, as per: > > https://gcc-newbies-guide.readthedocs.io/en/latest/getting-started.html#hello-world-from-the-compiler > > The point here is to get you and your development environment to the > point where you can comfortably make a simple change to GCC's source, > rebuild it and quickly see the results of your edits (without having to > wait ages), and for you to get comfortable stepping through it in the > debugger. > > Let me know if you run into issues (which could suggest improvements to > the guide). > > > > > After reading about the suggested projects described on GCC's GSOC > > page, I > > found "Bypass assembler when generating LTO object files" and "C++: > > Implement compiler built-in traits for the standard library traits" > > interesting. Currently, I am examining the preliminary patch > > https://gcc.gnu.org/ml/gcc/2014-09/msg00340.html for the first > > project. > > FWIW I'm not particularly expert at the specific areas of GCC relating > to the two projects you mentioned, so hopefully others on this list can > give advice/mentoring with those. >
[GSOC] getting "gdb: unrecognized option '-dumpdir'' while trying to debug gcc using gdb
I am sorry for the previous messed-up reply :(. I was trying to reply back to my previous mail thread but mistakenly replied to the entire digest::((. Thanks, David and Martin, for the heads up, and I am sorry for the late reply due to health issues. Anyways I could emit the warning "hello world, I am function foo.". After that, I tried debugging using the` ../gcc -wrapper gdb test.c`(gcc binary is in parent folder) but I am getting this error "gdb: unrecognized option '-dumpdir' Use `gdb --help' for a complete list of options.". I googled it and got this on Bugzilla (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53195), but it has already been fixed. These are the gdb configurations during the build: Using built-in specs. COLLECT_GCC=../gcc COLLECT_LTO_WRAPPER=gcc-dir/libexec/gcc/x86_64-pc-linux-gnu/12.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../project/configure --prefix=gcc-dir --enable-languages=c,c++ --disable-bootstrap Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.1 20230302 [OG12] (GCC) COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-' Can anyone point out how to resolve this or if I am missing something during build? Thanks and regards Rishi Raj
[GSOC] few question about Bypass assembler when generating LTO object files
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
Re: [GSOC] few question about Bypass assembler when generating LTO object files
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. 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 .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? Thanks & Regards Rishi Raj On Sun, 2 Apr 2023 at 03:05, Rishi Raj 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 > > > >
Re: [GSOC] few question about Bypass assembler when generating LTO object files
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 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 > > .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 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 > > > > > > > > > > > > >
Fwd: [GSOC] few question about Bypass assembler when generating LTO object files
-- Forwarded message - From: Rishi Raj Date: Tue, 4 Apr 2023 at 05:57 Subject: Re: [GSOC] Submission of draft proposal. To: Jan Hubicka Cc: , oops, I forgot to change the subject in previous email :( 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 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 > > .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 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 > > > > > > > > > > > > >
[GSOC] Submission of draft proposal for Bypass assembler when generating LTO object files
Sorry, I messed subject in my previous two emails :( so I am sending it again. I have completed a draft proposal for this project. I will appreciate Jan, Martin, 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
Re: [GSOC] few question about Bypass assembler when generating LTO object files
Thanks to Martin, Honza, and Théo for your feedback. I have incorporated almost all of it, updated my proposal accordingly, and submitted it. Regarding grammar errors, I have fixed many, but there may still be some left (I could be better at grammar, to be honest :( ). On Tue, 4 Apr 2023 at 15:55, Jan Hubicka wrote: > Hello, > > 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 > > Here are few comments on the proposal: > > > The current Implementation of GCC first write the IL representation > along with other section in an assembly file and then the assembler is used > to convert it into LTO object files. Sections containing different IL > representation is created and data is appended in lto-streamer-out.cc.I > > The .o generated withh -flto file contains the IL (in different > sections), debug info, symbol table, etc. > "along with other section" sounds odd to me. Perhaps sections. > > Second sentence seems bit odd too. Perhaps "Streaming of individual > sections is implemented in lto-streamer-out.cc which can either be used > to produce assembly code containing the section data (dumped > hexadecimally) or simple-object API provided by libiberty to produce > object files directly" > > > In the slim object file (Default when using -flto, fat lto can be > obtained using -ffat-lto-object) some section contains the IL and other > contains the info related to architecture, command line options, symbol > table, etc. > > Technically the architecture is part of ELF header and not section > itself (I think). > > There are some other grammar errors, but I am not too good on fixing > these, so perhaps Martin can help. > > The timeline looks reasonable. It certianly makes sense to look into > non-ELF object files to understand what API we need, but implementation > wise I would suggest implementing ELF path first to get a working > implementation. Adding support for other object formats can be done > incrementally. > > Honza > > > > On Tue, 4 Apr 2023 at 04:35, Jan Hubicka 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 > > > > .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 > 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) > > > > > > > > > > "O
About addition of .symtab and .strtab sections in simple-object-elf.c
Hi Everyone, I am working on the GSOC project "Bypass Assembler when generating LTO object files." My mentors and I have decided to work on the ELF files first, so I will add .symtab along with the symbol __gnu_lto_slim to the ELF file as a first step. When I was going through the simple-object-elf.c: simple_object_elf_write_to_file() I found out that it writes the following: /* Write out a complete ELF file. Ehdr initial dummy Shdr user-created Shdrs .shstrtab Shdr user-created section data .shstrtab data */ and .symtab is missing here. To add the missing symtab I have thought of these two possible implementations. 1) Add it in simple-object-elf.c (based on -fbypass-asm flag). 2) We can add .symtab section in lto-object.cc along with other LTO sections. I am a bit skeptical about the second one as .symtab with other lto sections might be confusing. Any comments regarding which one should I proceed with will be helpful. -- Thanks & Regards Rishi Raj
Patch regarding addition of .symtab while generating object file from libiberty [WIP]
Hi,
I am working on the GSOC project "Bypass Assembler when generating LTO
object files." So as a first step, I am adding .symtab along with
__gnu_lto_slim symbol into it so that at a later stage, it can be
recognized that this object file has been produced using -flto enabled.
This patch is regarding the same. Although I am still testing this patch, I
want general feedback on my code and design choice.
I have extended simple_object_wrtie_struct to hold a list of symbols (
similar to sections ). A function in simple-object.c to add symbols. I am
calling this function in lto-object.cc to add __gnu_lto_v1.
Right now, as we are only working on ELF support first, I am adding .symtab
in elf object files only.
Note:- I have added this patch on top of Jan's updated patch (
https://gcc.gnu.org/pipermail/gcc/2022-May/238670.html). I am pushing all
these changes to my GitHub repo:
https://github.com/rsh-raj/gcc/tree/patch-devel, so you can also view them
from there.
-Rishi
---
>From 5760ccce2f4ae8930a07e3d0d4e0d029737a44d8 Mon Sep 17 00:00:00 2001
From: rsh-raj
Date: Mon, 19 Jun 2023 19:42:50 +0530
Subject: [PATCH] Added .symtab support
---
gcc/lto-object.cc| 4 +-
include/simple-object.h | 10 +++
libiberty/simple-object-common.h | 18 +
libiberty/simple-object-elf.c| 130 +--
libiberty/simple-object.c| 32
5 files changed, 187 insertions(+), 7 deletions(-)
diff --git a/gcc/lto-object.cc b/gcc/lto-object.cc
index cb1c3a6cfb3..680977cb327 100644
--- a/gcc/lto-object.cc
+++ b/gcc/lto-object.cc
@@ -187,7 +187,9 @@ lto_obj_file_close (lto_file *file)
int err;
gcc_assert (lo->base.offset == 0);
-
+ /*Add __gnu_lto_slim symbol*/
+ if(flag_bypass_asm)
+simple_object_write_add_symbol (lo->sobj_w, "__gnu_lto_slim",1,1);
errmsg = simple_object_write_to_file (lo->sobj_w, lo->fd, &err);
if (errmsg != NULL)
{
diff --git a/include/simple-object.h b/include/simple-object.h
index 01f8a26f979..3a14184b12c 100644
--- a/include/simple-object.h
+++ b/include/simple-object.h
@@ -156,6 +156,11 @@ simple_object_start_write (simple_object_attributes
*attrs,
typedef struct simple_object_write_section_struct
simple_object_write_section;
+/* The type simple_object_symbol is a handle for a symbol
+ which is being written. */
+
+typedef struct simple_object_symbol_struct simple_object_symbol;
+
/* Add a section to SIMPLE_OBJECT. NAME is the name of the new
section. ALIGN is the required alignment expressed as the number
of required low-order 0 bits (e.g., 2 for alignment to a 32-bit
@@ -190,6 +195,11 @@ simple_object_write_add_data (simple_object_write
*simple_object,
extern const char *
simple_object_write_to_file (simple_object_write *simple_object,
int descriptor, int *err);
+/*Add a symbol to sobj struct which will be written to common in simple_
+object_write_to_file function*/
+extern void
+simple_object_write_add_symbol(simple_object_write *sobj, const char *name,
+size_t size, unsigned int align);
/* Release all resources associated with SIMPLE_OBJECT, including any
simple_object_write_section's that may have been created. */
diff --git a/libiberty/simple-object-common.h
b/libiberty/simple-object-common.h
index b9d10550d88..df99c9d85ac 100644
--- a/libiberty/simple-object-common.h
+++ b/libiberty/simple-object-common.h
@@ -58,6 +58,24 @@ struct simple_object_write_struct
simple_object_write_section *last_section;
/* Private data for the object file format. */
void *data;
+ /*The start of the list of symbols.*/
+ simple_object_symbol *symbols;
+ /*The last entry in the list of symbols*/
+ simple_object_symbol *last_symbol;
+};
+
+/*A symbol in object file being created*/
+struct simple_object_symbol_struct
+{
+ /*Next in the list of symbols attached to an
+ simple_object_write*/
+ simple_object_symbol *next;
+ /*The name of this symbol. */
+ char *name;
+ /* Symbol value */
+ unsigned int align;
+ /* Symbol size */
+ size_t size;
};
/* A section in an object file being created. */
diff --git a/libiberty/simple-object-elf.c b/libiberty/simple-object-elf.c
index eee07039984..cbba88186bd 100644
--- a/libiberty/simple-object-elf.c
+++ b/libiberty/simple-object-elf.c
@@ -787,9 +787,9 @@ simple_object_elf_write_ehdr (simple_object_write
*sobj, int descriptor,
++shnum;
if (shnum > 0)
{
- /* Add a section header for the dummy section and one for
- .shstrtab. */
- shnum += 2;
+ /* Add a section header for the dummy section,
+ .shstrtab, .symtab and .strtab. */
+ shnum += 4;
}
ehdr_size = (cl == ELFCLASS32
@@ -882,6 +882,51 @@ simple_object_elf_write_shdr (simple_object_write
*sobj, int descriptor,
errmsg, err);
}
+/* Write out an ELF Symbol*/
+
+static int
+simple_object_elf_write_symbol(simple_object_write *sobj, int descriptor,
+off_t offset, unsi
Re: Patch regarding addition of .symtab while generating object file from libiberty [WIP]
On Sun, 25 Jun 2023 at 04:18, Jan Hubicka wrote:
> > Hi,
> Hi,
> I am sorry for late reaction.
>
No problem!
> > I am working on the GSOC project "Bypass Assembler when generating LTO
> > object files." So as a first step, I am adding .symtab along with
> > __gnu_lto_slim symbol into it so that at a later stage, it can be
> > recognized that this object file has been produced using -flto enabled.
> > This patch is regarding the same. Although I am still testing this
> patch, I
> > want general feedback on my code and design choice.
> > I have extended simple_object_wrtie_struct to hold a list of symbols (
> > similar to sections ). A function in simple-object.c to add symbols. I am
> > calling this function in lto-object.cc to add __gnu_lto_v1.
> > Right now, as we are only working on ELF support first, I am adding
> .symtab
> > in elf object files only.
> >
> > ---
> > gcc/lto-object.cc| 4 +-
> > include/simple-object.h | 10 +++
> > libiberty/simple-object-common.h | 18 +
> > libiberty/simple-object-elf.c| 130 +--
> > libiberty/simple-object.c| 32
> > 5 files changed, 187 insertions(+), 7 deletions(-)
> >
> > diff --git a/gcc/lto-object.cc b/gcc/lto-object.cc
> > index cb1c3a6cfb3..680977cb327 100644
> > --- a/gcc/lto-object.cc
> > +++ b/gcc/lto-object.cc
> > @@ -187,7 +187,9 @@ lto_obj_file_close (lto_file *file)
> >int err;
> >
> >gcc_assert (lo->base.offset == 0);
> > -
> > + /*Add __gnu_lto_slim symbol*/
> > + if(flag_bypass_asm)
> > +simple_object_write_add_symbol (lo->sobj_w,
> "__gnu_lto_slim",1,1);
>
> You can probably do this unconditionally. The ltrans files we produce
> are kind of wrong by missing the symbol table currently.
>
I see.
> > +simple_object_write_add_symbol(simple_object_write *sobj, const char
> *name,
> > +size_t size, unsigned int align);
>
> Symbols has much more properties in addition to sizes and alignments.
> We will eventually need to get dwarf writting, so we will need to
> support them. However right now we only do these fake lto object
> symbols, so perhaps for start we could kep things simple and assume that
> size is always 0 and align always 1 or so.
>
> Overall this looks like really good start to me (both API and
> imllementation looks reasonable to me and it is good that you follow the
> coding convention). I guess you can create a branch (see git info on
> the gcc homepage) and put the patch there?
>
I can, but I don't have write access to git. Also, for the next part, I am
thinking of properly configuring the driver
to directly produce an executable or adding debug info. What do you think?
--
Regards
Rishi
>
> I am also adding Ian to CC as he is maintainer of the simple-object and
> he may have some ideas.
>
> Honza
> >
> > /* Release all resources associated with SIMPLE_OBJECT, including any
> > simple_object_write_section's that may have been created. */
> > diff --git a/libiberty/simple-object-common.h
> > b/libiberty/simple-object-common.h
> > index b9d10550d88..df99c9d85ac 100644
> > --- a/libiberty/simple-object-common.h
> > +++ b/libiberty/simple-object-common.h
> > @@ -58,6 +58,24 @@ struct simple_object_write_struct
> >simple_object_write_section *last_section;
> >/* Private data for the object file format. */
> >void *data;
> > + /*The start of the list of symbols.*/
> > + simple_object_symbol *symbols;
> > + /*The last entry in the list of symbols*/
> > + simple_object_symbol *last_symbol;
> > +};
> > +
> > +/*A symbol in object file being created*/
> > +struct simple_object_symbol_struct
> > +{
> > + /*Next in the list of symbols attached to an
> > + simple_object_write*/
> > + simple_object_symbol *next;
> > + /*The name of this symbol. */
> > + char *name;
> > + /* Symbol value */
> > + unsigned int align;
> > + /* Symbol size */
> > + size_t size;
> > };
> >
> > /* A section in an object file being created. */
> > diff --git a/libiberty/simple-object-elf.c
> b/libiberty/simple-object-elf.c
> > index eee07039984..cbba88186bd 100644
> > --- a/libiberty/simple-object-elf.c
> > +++ b/libiberty/simple-object-elf.c
> > @@ -787,9 +787,9 @@ simple_object_elf_write_ehdr (simple_object_write
> > *sobj, int descriptor,
> > ++shnum;
> >if (shnum > 0)
> > {
> > - /* Add a section header for the dummy section and one for
> > - .shstrtab. */
> > - shnum += 2;
> > + /* Add a section header for the dummy section,
> > + .shstrtab, .symtab and .strtab. */
> > + shnum += 4;
> > }
> >
> >ehdr_size = (cl == ELFCLASS32
> > @@ -882,6 +882,51 @@ simple_object_elf_write_shdr (simple_object_write
> > *sobj, int descriptor,
> > errmsg, err);
> > }
> >
> > +/* Write out an ELF Symbol*/
> > +
> > +static int
> > +simple_object_elf_write_symbol(simple_object_write *sobj, int
> descriptor,
> > +off_t offset, unsigned int st_na
Re: Patch regarding addition of .symtab while generating object file from libiberty [WIP]
On Mon, 26 Jun 2023 at 23:24, Jan Hubicka wrote:
> > > > +simple_object_write_add_symbol(simple_object_write *sobj, const char
> > > *name,
> > > > +size_t size, unsigned int align);
> > >
> > > Symbols has much more properties in addition to sizes and alignments.
> > > We will eventually need to get dwarf writting, so we will need to
> > > support them. However right now we only do these fake lto object
> > > symbols, so perhaps for start we could kep things simple and assume
> that
> > > size is always 0 and align always 1 or so.
> > >
> > > Overall this looks like really good start to me (both API and
> > > imllementation looks reasonable to me and it is good that you follow
> the
> > > coding convention). I guess you can create a branch (see git info on
> > > the gcc homepage) and put the patch there?
> > >
> > I can, but I don't have write access to git. Also, for the next part, I
> am
> This is easy to fix. Follow instructions here
> https://gcc.gnu.org/gitwrite.html
> and add me as sponsor. There are also instructions how to produce a
> branch on git correctly.
>
Ok.
> > thinking of properly configuring the driver
> > to directly produce an executable or adding debug info. What do you
> think?
>
> I think we should try to aim to something that can be tested. If we add
> symbol table and get the ELF header right, linker should accept the
> object files and properly recognize them as LTO.
>
I have done some testing, readelf can read the symbol table and display it
correctly ( using your updated patch to produce object files:
https://gcc.gnu.org/pipermail/gcc/2022-May/238670.html).
Apart from this, I also ran GCC LTO's test suite, and all test cases passed
as expected.
I am also able to produce an executable and run it. The only thing I might
be missing is producing the ELF header directly instead of reading it from
crtbegin.o.
I am thinking about it but can't think where to find architecture and
header's field details without crtbegin.o.
What exactly you mean by configuring the driver?
>
I was talking about right now in the patch, to produce an executable, we
have to stop before the assembly step(-S flag) and then invoke the linker.
I am thinking of fixing it.
--
Regards
Rishi
>
> Honza
> > --
> > Regards
> > Rishi
> >
> > >
> > > I am also adding Ian to CC as he is maintainer of the simple-object and
> > > he may have some ideas.
> > >
> > > Honza
> > > >
> > > > /* Release all resources associated with SIMPLE_OBJECT, including
> any
> > > > simple_object_write_section's that may have been created. */
> > > > diff --git a/libiberty/simple-object-common.h
> > > > b/libiberty/simple-object-common.h
> > > > index b9d10550d88..df99c9d85ac 100644
> > > > --- a/libiberty/simple-object-common.h
> > > > +++ b/libiberty/simple-object-common.h
> > > > @@ -58,6 +58,24 @@ struct simple_object_write_struct
> > > >simple_object_write_section *last_section;
> > > >/* Private data for the object file format. */
> > > >void *data;
> > > > + /*The start of the list of symbols.*/
> > > > + simple_object_symbol *symbols;
> > > > + /*The last entry in the list of symbols*/
> > > > + simple_object_symbol *last_symbol;
> > > > +};
> > > > +
> > > > +/*A symbol in object file being created*/
> > > > +struct simple_object_symbol_struct
> > > > +{
> > > > + /*Next in the list of symbols attached to an
> > > > + simple_object_write*/
> > > > + simple_object_symbol *next;
> > > > + /*The name of this symbol. */
> > > > + char *name;
> > > > + /* Symbol value */
> > > > + unsigned int align;
> > > > + /* Symbol size */
> > > > + size_t size;
> > > > };
> > > >
> > > > /* A section in an object file being created. */
> > > > diff --git a/libiberty/simple-object-elf.c
> > > b/libiberty/simple-object-elf.c
> > > > index eee07039984..cbba88186bd 100644
> > > > --- a/libiberty/simple-object-elf.c
> > > > +++ b/libiberty/simple-object-elf.c
> > > > @@ -787,9 +787,9 @@ simple_object_elf_write_ehdr (simple_object_write
> > > > *sobj, int descriptor,
> > > > ++shnum;
> > > >if (shnum > 0)
> > > > {
> > > > - /* Add a section header for the dummy section and one for
> > > > - .shstrtab. */
> > > > - shnum += 2;
> > > > + /* Add a section header for the dummy section,
> > > > + .shstrtab, .symtab and .strtab. */
> > > > + shnum += 4;
> > > > }
> > > >
> > > >ehdr_size = (cl == ELFCLASS32
> > > > @@ -882,6 +882,51 @@ simple_object_elf_write_shdr
> (simple_object_write
> > > > *sobj, int descriptor,
> > > > errmsg, err);
> > > > }
> > > >
> > > > +/* Write out an ELF Symbol*/
> > > > +
> > > > +static int
> > > > +simple_object_elf_write_symbol(simple_object_write *sobj, int
> > > descriptor,
> > > > +off_t offset, unsigned int st_name, unsigned int
> st_value,
> > > > size_t st_size,
> > > > +unsigned char st_info, unsigned char st_other, unsigned
> int
> > > > st_shndx,
> > > > +const
Regarding bypass-asm patch and help in an error during bootstrapped build
Hi, I have added the patch ( https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623379.html ) on the devel/bypass-asm branch. Although I am able to build using the --disable-bootstrap option but while doing a bootstrapped build, I am getting these errors ( as warnings while doing the non-bootstrapped build.) In file included from ../../gcc/gcc/lto-object.cc:23:0: ../../gcc/gcc/is-a.h:196:22: error: inline function ‘static bool is_a_helper::test(U*) [with U = symtab_node; T = cgraph_node*]’ used but never defined [enabled by default] static inline bool test (U *p); ^ ../../gcc/gcc/is-a.h:196:22: error: inline function ‘static bool is_a_helper::test(U*) [with U = symtab_node; T = varpool_node*]’ used but never defined [enabled by default] In file included from ../../gcc/gcc/coretypes.h:489:0, from ../../gcc/gcc/lto/lto-lang.cc:23: ../../gcc/gcc/is-a.h:196:22: error inline function ‘static bool is_a_helper::test(U*) [with U = symtab_node; T = cgraph_node*]’ used but never defined [enabled by default] static inline bool test (U *p); ^ ../../gcc/gcc/is-a.h:196:22: error inline function ‘static bool is_a_helper::test(U*) [with U = symtab_node; T = varpool_node*]’ used but never defined [enabled by default] I have tested the .symtab and dummy symbols addition on the non-bootstrapped build, and they are working fine. I also ran the lto test suite, and it passed as expected. I am looking into the error produced during bootstrapped build currently. I would appreciate any help/guidance regarding this. -- Regards Rishi
Re: Regarding bypass-asm patch and help in an error during bootstrapped build
Yup, I somehow missed it. Thanks, it is fixed now. Now we can test the addition of.symtab and symbols in both builds. Now I am moving toward the second part of the project, adding debugging information. Right now, I am going through the documentation. Will you recommend any other resources? -- Rishi On Thu, 6 Jul 2023 at 20:40, Jan Hubicka wrote: > > Hi, > > > > I have added the patch ( > > https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623379.html ) on the > > devel/bypass-asm branch. > > Although I am able to build using the --disable-bootstrap option but > while > > doing a bootstrapped build, I am getting these errors ( as warnings while > > doing the non-bootstrapped build.) > > > > In file included from ../../gcc/gcc/lto-object.cc:23:0: > > ../../gcc/gcc/is-a.h:196:22: error: inline function ‘static bool > > is_a_helper::test(U*) [with U = symtab_node; T = cgraph_node*]’ used > but > > never defined [enabled by default] > >static inline bool test (U *p); > > > > ^ > > ../../gcc/gcc/is-a.h:196:22: error: inline function ‘static bool > > is_a_helper::test(U*) [with U = symtab_node; T = varpool_node*]’ used > > but never defined [enabled by default] > > > > > > In file included from ../../gcc/gcc/coretypes.h:489:0, > > from ../../gcc/gcc/lto/lto-lang.cc:23: > > ../../gcc/gcc/is-a.h:196:22: error inline function ‘static bool > > is_a_helper::test(U*) [with U = symtab_node; T = cgraph_node*]’ used > but > > never defined [enabled by default] > >static inline bool test (U *p); > > ^ > > ../../gcc/gcc/is-a.h:196:22: error inline function ‘static bool > > is_a_helper::test(U*) [with U = symtab_node; T = varpool_node*]’ used > > but never defined [enabled by default] > > > > I have tested the .symtab and dummy symbols addition on the > > non-bootstrapped build, and they are working fine. I also ran the lto > test > > suite, and it passed as expected. I am looking into the error produced > > during bootstrapped build currently. I would appreciate any help/guidance > > regarding this. > This is because you miss some #inline or you do these in wrong order > (at some point it was decided to drop most #inlines inside header files, > so one needs to always do the transitive closure by hand which is quite > anoying). > > This is a conversion helper from cgraph_node to symtab_node, so pehraps > you need to include cgraph.h? > > Honza > > > > -- > > Regards > > Rishi >
Help regarding architecture and related info needed for ELF header
Hi, As mentioned earlier in previous thread, I am working on a project to bypass the assembler. I have already finished addition of .symtab section. While I am currently working to emit the debugging symbols directly from compiler, one thing which I missed was directly outputting the various info like architecture, machine type and OS ABI in ELF header rather than reading it from crtbegin.o. I tried my hand at it but couldn't find anything substantial. Any suggestion regarding the same will be helpful! Also a question to Jan and Martin, right now should I focus on debugging part or get this done before moving to it? -- Rishi
Clarification regarding various classes DIE's attribute value class
Hello,
I am working on a project to produce the LTO object file from the compiler
directly. So far, we have
correctly outputted .symtab along with various .debug sections. The only
thing remaining is to
correctly output attribute values and their corresponding values in the
.debug_info section. This is done by the output_die function in
dwarf2out.cc based on the value's class. However, the same
function is used in dwarf2out_finish as well as dwarf2out_early_finish, so
I suspect that not every value class is being used in dwarfout_early_finish
(mainly I am interested in -flto mode). As there is little documentation on
the same, I experimented by commenting out the various cases of value class
in output die. I found that the classes such as dw_val_class_addr,
dw_val_class_high_pc, and dw_val_class_vms_delta aren't being used during
the early_finish of LTO mode. I might be wrong, as my observation is based
on commenting out and testing a few pieces of code that might need to be
completed. So, can anyone please tell out of these 30 classes that are
relevant to dwarf2out_early_finish in LTO mode or at least point out some
documentation if it exists?
enum dw_val_class
{
dw_val_class_none,
dw_val_class_addr,
dw_val_class_offset,
dw_val_class_loc,
dw_val_class_loc_list,
dw_val_class_range_list,
dw_val_class_const,
dw_val_class_unsigned_const,
dw_val_class_const_double,
dw_val_class_wide_int,
dw_val_class_vec,
dw_val_class_flag,
dw_val_class_die_ref,
dw_val_class_fde_ref,
dw_val_class_lbl_id,
dw_val_class_lineptr,
dw_val_class_str,
dw_val_class_macptr,
dw_val_class_loclistsptr,
dw_val_class_file,
dw_val_class_data8,
dw_val_class_decl_ref,
dw_val_class_vms_delta,
dw_val_class_high_pc,
dw_val_class_discr_value,
dw_val_class_discr_list,
dw_val_class_const_implicit,
dw_val_class_unsigned_const_implicit,
dw_val_class_file_implicit,
dw_val_class_view_list,
dw_val_class_symview
};
--
Rishi
Help needed in output relocations
Hello, I have almost completed the output of relocation entries. The only thing that remains is to output the corresponding symbols in .symtab. In my current design, I store the info about relocation entry and the symbol name. However, the problem I am facing with this approach is that many relocation entries will have the same name, so we will need a hash table with the key as symbol name and value as symbol index in symtab. It would be really helpful if you could point out the relevant docs or help me figure out how to use the hash table in GCC. Another approach is, as we have only 4-5 unique relocation symbol names. We can output just those and store their .symtab index somewhere. -- Rishi
