Hello,
> Hi! I've been interested in compiler development for a while, and would love
> to
> work with any of you as part of GSoC, or even just as a side-project on my
> own.
>
> I'm an 18 year-old student going into university next year with a passion for
> all
> things open source and low level. I consider myself fluent in c, and
> proficient
> with c++, rust, and x86 assembly, but unfamiliar with practical compiler
> design.
> I have done some reading on the theoretical aspects of compilers, however.
>
> While I haven't worked with the GCC community before, I have worked with the
> linux
> community and have made several small patches there, so I am familiar with
> both
> email-based workflows and the principles of open-source development.
>
> This summer, I'm looking for more experience working on larger projects, as
> well
> as getting into real compilers.
>
> Of particular interest to me is the project idea labelled "Bypass assembler
> when
> generating LTO object files." I see that the project was taken last year, but
> I can find no sign of any changes committed to trunk
> (`git shortlog --after=2022-01-01 | grep -i -E "lto|assembl(er|y)"` shows
> nothing
> related to this project) and no sign of any needed change made in the code.
> Is this project still available?
yes, the project is available and Maritn Jambor and me
would be happy to mentor it. Please add me and Martin to CC of any
emails on the proejt.
I think it would be good to start by looking at the original work in
progress patch (linked from the task description, an updated version is
here https://gcc.gnu.org/pipermail/gcc/2022-May/238670.html). Overall
struture of the LTO optimization is described in paper
https://arxiv.org/abs/1010.2196
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. So I think getting familiar with simple-object.c and the
elf/mach/coff handlers of it would be a good initital step. It will be
necessary to add API to specify the architecture and symbols in the
symbol table so the resulting object files are recognized by linker.
Second part would be handling of output of dwarf debug information, so
it may make sense to also take a quick look on its documentation. The
on-disk representation is actually not too hard and it should be
possible to make a direct writer.
Jan
>
> I'm also willing to work on other projects, ideally in the middle/backend, but
> currently I have only been experimenting with the gcc/[lto,data]-streamer*
> files.
> If anyone has a small or medium sized project idea, please feel free to let
> me know.
>
>
> I look forward to working with all of you in the future,
>
> Peter Lafreniere
>
>
