A "newbies" guide to hacking on GCC (and plugins)

A "newbies" guide to hacking on GCC (and plugins)

[David Malcolm]

I'm a relative newcomer to GCC [1], so I thought it would be a good
idea to try to capture some of the "gotchas" and similar information on
hacking on GCC in the form of a short guide for new contributors,
whilst the experience of learning it is still fresh in my mind.

The guide can be read here:
https://dmalcolm.fedorapeople.org/gcc/newbies-guide/index.html

I've mostly tried to cover specific things I ran into that caused me
difficulty, so it may be eclectic.

(All opinions are my own)

I hope that this is useful.

Dave


[1] did we miss GCC's 30th anniversary?  
https://gcc.gnu.org/wiki/History  says the first release was 1987-03
-22.   As for myself, Thursday appears to be the 6th anniversary of me
starting the gcc-python-plugin and hence on poking at GCC's internals -
I'm not sure if 6 years means I still count as a newcomer, but 30 years
is geological epochs in software terms :)

Re: A "newbies" guide to hacking on GCC (and plugins)

[Trevor Saunders]

On Tue, Mar 28, 2017 at 04:41:29PM -0400, David Malcolm wrote:
> I'm a relative newcomer to GCC [1], so I thought it would be a good
> idea to try to capture some of the "gotchas" and similar information on
> hacking on GCC in the form of a short guide for new contributors,
> whilst the experience of learning it is still fresh in my mind.

This seems useful, though I generally think spreading docs around leads
to many out of date docs, and further that its much better to make
something self explanatory rather than documenting it.

> The guide can be read here:
> https://dmalcolm.fedorapeople.org/gcc/newbies-guide/index.html
> 
> I've mostly tried to cover specific things I ran into that caused me
> difficulty, so it may be eclectic.

I think one thing its useful for is seeing what people have trouble with
so we can try and fix them.  Here's a list of things I'm comming up with
from your docs.

ggc

I think we already knew this caused grief ;-) I'm very tempted to rip
out pch at the start of stage 1 in the hope the C++-modules branch will
get merged and we can use that as a PCH replacement.  There are probably
other things we can do to make ggc more pleasent too.

debugging with the driver, I'm not sure we can really do much there, but
if you are on x86 and can use rr it hardly matters and the other work
arounds are fine.

non ggc memory management I think we can make a lot safer with C++ and
so make valgrind use much less necessary.

option flag "globals" we should probably do something about? but I don't
know what at the moment.

running the test suite, imho the runtest UI as exposed through make is
terrible and unhelpful in error cases.  I'm not sure what the full
"right" solution is, but this should be improvable with work.

Trev

> 
> (All opinions are my own)
> 
> I hope that this is useful.
> 
> Dave
> 
> 
> [1] did we miss GCC's 30th anniversary?  
> https://gcc.gnu.org/wiki/History  says the first release was 1987-03
> -22.   As for myself, Thursday appears to be the 6th anniversary of me
> starting the gcc-python-plugin and hence on poking at GCC's internals -
> I'm not sure if 6 years means I still count as a newcomer, but 30 years
> is geological epochs in software terms :)

Re: A "newbies" guide to hacking on GCC (and plugins)

[Jonathan Wakely]

On 28 March 2017 at 21:41, David Malcolm wrote:
> [1] did we miss GCC's 30th anniversary?
> https://gcc.gnu.org/wiki/History  says the first release was 1987-03
> -22.   As for myself, Thursday appears to be the 6th anniversary of me
> starting the gcc-python-plugin and hence on poking at GCC's internals -
> I'm not sure if 6 years means I still count as a newcomer, but 30 years
> is geological epochs in software terms :)

I think Jakub mentioned GCC's anniversary on IRC the day before, but I
still forgot to send it a card.