Re: hacking gcc - avoiding bootstrap?

Re: hacking gcc - avoiding bootstrap?

[Robert Dewar]

<<I hardly ever bootstraped (or installed) as a developer
>>

That seems a bit odd to me, though I am certainly am not very familiar
with working procedures. I would have thought that it was routine to
do a bootstra[p to test any modification that is made. Certainly in
the GNAT world, we do both a bootstrap and our full regression run
for even the simplest change.

Re: hacking gcc - avoiding bootstrap?

[Geoff Keating]

Mike Stump <mrs@windriver.com> writes:

> Also, given an infrastructure that runs beside you that does a
> full bootstrap and a full test, there is really little need...  It's
> not that it wasn't done, it just that I usually didn't do them.
> Better to let cron waste his time, more efficient for me.

I hope by 'cron' you mean something you designed that checks your
patch before you commit it, not anything that runs on the public tree.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: hacking gcc - avoiding bootstrap?

[Mike Stump]

> To: brent@rcfile.org, gcc@gcc.gnu.org, mrs@windriver.com
> Date: Sat, 30 Sep 2000 08:24:51 -0400 (EDT)
> From: dewar@gnat.com (Robert Dewar)

> I would have thought that it was routine to do a bootstrap to test
> any modification that is made. Certainly in the GNAT world, we do
> both a bootstrap and our full regression run for even the simplest
> change.

That's because your frontend is written in the language of the
frontend.  By compiling it, you run a testcase, selfcompile.
If mine were in C++, it might make more sense.

If I had a sparc, and I was working on the sparc.md file, a full clean
botstrap would be good, as again, it is a good testcase.

Very few changes to the C++ frontend can show a difference between a
bootstrapped compiler and a non-bootstrapped.  Also, given an
infrastructure that runs beside you that does a full bootstrap and a
full test, there is really little need...  It's not that it wasn't
done, it just that I usually didn't do them.  Better to let cron waste
his time, more efficient for me.

Re: hacking gcc - avoiding bootstrap?

[brent]

On 29 Sep 2000 at 21:20 (-0400), Phil Edwards wrote:
| On Fri, Sep 29, 2000 at 05:07:20PM -0400, brent@rcfile.org wrote:
| > On 29 Sep 2000 at 16:38 (-0400), Phil Edwards wrote:
| >
| > | 'make all' at the top level (or in the gcc subdir) will build everything just
| > | once.  If you know you have a completely working C compiler installed already
| > | to do the build, then that's usually good enough for most sub-projects
| > | (like C++-related things).  For stuff that affects the core C compiler,
| > | you should always do a full bootstrap for the additional testing.
| >
| > has the 'make all' worked as desired/expected for you?
|
| Absolutely.  It picks up any compiler changes from others, and eventually
| descends to build libstdc++-v3, which is what I'm usually messing with.

cool. that's three affirmations that bootstrap is not needed
to test frontend modifications. that equates to about 20 times as
many experiments I can make over the course my vacation. hopefully
I can fix a buglet and learn (a bit about) how this magic compiler
works, if not I can atleast slap together the beginnings of a
"Hacking gcc for dumm*es" guide :)

thanks.
  brent

-- 
All opinions expressed are My own, unless otherwise attributed. In
presenting facts, I expressly reserve the right to be Wrong. Portions
of this message authored by Me are subject to the Free Thought License.

Re: hacking gcc - avoiding bootstrap?

[brent]

On 29 Sep 2000 at 14:27 (-0700), Mike Stump wrote:
| 
| Run gdb in emacs, M-x gdb.  Set a breakpoint on expand_expr,
| make_insn_raw, emit_insn and friends, and your off and running.  :-)
| Neat variables are things like lineno, cur_insn_uid, INSN_UID (note),
| current_function_decl.  Interesting things to call include,

well, the above recommendations are good once I realized I needed to
figure out how to get gdb into cc1plus. I'm doing:

dust$ gdb cc1plus
(gdb) break expand_expr
(gdb) run x.ii

is this the only way to get cc1plus into gdb? (ok, I know, this topic
is more appropriate for some other list..) I tried the emacs M-x 
suggestion, but it still only loaded symbols for g++, so I went the
plain ol' gdb route and followed that through to pexecute() and into 
the forked cpp0 which reulted in:
  
  g++: Internal error: Trace/breakpoint trap (program cpp0)
  Please submit a full bug report.
  See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.

i've observed the following progs involved with compiling c++ files

  g++
  cpp0
  cc1plus
  as
  ld

did I missing any step?

thanks again,
  brent (off to gdb land)

-- 
All opinions expressed are My own, unless otherwise attributed. In
presenting facts, I expressly reserve the right to be Wrong. Portions
of this message authored by Me are subject to the Free Thought License.

Re: hacking gcc - avoiding bootstrap?

[Phil Edwards]

On Fri, Sep 29, 2000 at 05:07:20PM -0400, brent@rcfile.org wrote:
> On 29 Sep 2000 at 16:38 (-0400), Phil Edwards wrote:
> 
> | 'make all' at the top level (or in the gcc subdir) will build everything just
> | once.  If you know you have a completely working C compiler installed already
> | to do the build, then that's usually good enough for most sub-projects
> | (like C++-related things).  For stuff that affects the core C compiler,
> | you should always do a full bootstrap for the additional testing.
> 
> has the 'make all' worked as desired/expected for you?

Absolutely.  It picks up any compiler changes from others, and eventually
descends to build libstdc++-v3, which is what I'm usually messing with.

From the top level, there are a bunch of targets you can use for make, of
the form {configure,all,check,install}-[target-]{subproject}.  Excuse the
fugly regexp there.

Inside particular directories, make works like it always does, e.g.,
'make gcc.o' to rebuild just one file correctly.


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: hacking gcc - avoiding bootstrap?

[brent]

On 29 Sep 2000 at 14:27 (-0700), Mike Stump wrote:
| 
| > maybe just a list of tools that the pros use to get around the code,
| 
| The human brain (memory), emacs, grep, TAGS (M-.) and gdb account of 90% of
| the way I get around.

[excellent examples snipped]

| You wanna do up some documentation?  Start it, and others may tell you
| even more useful and more interesting tricks of the trade.  The above
| is a 5 second overview.

sure, I'll put together a page containing any info that gets sent my
way. I think this would be great (at least from my viewpoint) to have
available for anyone wandering into the gcc tree :)

thanks much!
  brent

-- 
All opinions expressed are My own, unless otherwise attributed. In 
presenting facts, I expressly reserve the right to be Wrong. Portions 
of this message authored by Me are subject to the Free Thought License.

Re: hacking gcc - avoiding bootstrap?

[Geoff Keating]

brent@rcfile.org writes:

> I hope _the word_ is that it is sane to do the 'make all' when only
> modifying frontend files.

You don't need to do a full bootstrap, but you _do_ need to check that
libstdc++ and libio and libgcc still build with your new compiler.

(There've been a number of incidences when someone changed the C++
frontend and suddenly libstdc++ won't build.)

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: hacking gcc - avoiding bootstrap?

[Mike Stump]

> From: brent@rcfile.org
> Date: Fri, 29 Sep 2000 17:07:20 -0400
> To: Phil Edwards <pedwards@disaster.jaj.com>
> Cc: gcc@gcc.gnu.org

> maybe just a list of tools that the pros use to get around the code,

The human brain (memory), emacs, grep, TAGS (M-.) and gdb account of 90% of
the way I get around.

> a document on how to use gdb to debug a compiler (admitting my lack
> of knowledge of gdb), or is the (apparent) lack of help significant
> of the lack of demand for this sort of info?

Run gdb in emacs, M-x gdb.  Set a breakpoint on expand_expr,
make_insn_raw, emit_insn and friends, and your off and running.  :-)
Neat variables are things like lineno, cur_insn_uid, INSN_UID (note),
current_function_decl.  Interesting things to call include,
p decl
pt
p x
pr
p insn
pr
call debug_rtx_list(insn, -50)
call debug_rtx_list(insn, 50)

neat debugger commands include:
x/10i $pc
si
ni
up
down
p variable
C-x space in file.c
M-n in debugger

Fun emacs commands:
M-x grep
M-x gdb
M-. (and M-,)
C-` (M-x next-error)
M-x compile

You wanna do up some documentation?  Start it, and others may tell you
even more useful and more interesting tricks of the trade.  The above
is a 5 second overview.

Re: hacking gcc - avoiding bootstrap?

[Mike Stump]

> From: brent@rcfile.org
> Date: Fri, 29 Sep 2000 16:05:09 -0400
> To: gcc@gcc.gnu.org

>   if files (e.g., gcc/cp/decl.c) are modified, how can I avoid
>   bootstrapping to test any modifications?

I hardly ever bootstraped (or installed) as a developer.  If you have
installed a version that works that is close to the version your
using, you just rm cc1plus; make cc1plus and then make check-g++.

Ah, fond memories of the good old days.

Re: hacking gcc - avoiding bootstrap?

[brent]

On 29 Sep 2000 at 16:38 (-0400), Phil Edwards wrote:
| On Fri, Sep 29, 2000 at 04:05:09PM -0400, brent@rcfile.org wrote:
| > quick question:
| >   if files (e.g., gcc/cp/decl.c) are modified, how can I avoid
| >   bootstrapping to test any modifications?
| 
| Good question; I went through this same thing.

is there any 'hacking gcc' document that I've overlooked that might
shed more light on how to best tackle modifying a (gcc) compiler? -- 
maybe just a list of tools that the pros use to get around the code,
(I'm using cscope to _sort of_ get around the code), a document on how
to use gdb to debug a compiler (admitting my lack of knowledge of gdb),
or is the (apparent) lack of help significant of the lack of demand
for this sort of info?

| 'make all' at the top level (or in the gcc subdir) will build everything just
| once.  If you know you have a completely working C compiler installed already
| to do the build, then that's usually good enough for most sub-projects
| (like C++-related things).  For stuff that affects the core C compiler,
| you should always do a full bootstrap for the additional testing.

has the 'make all' worked as desired/expected for you?

| The people actually in charge will now correct any of my misconceptions.  :-)

I hope _the word_ is that it is sane to do the 'make all' when only
modifying frontend files.

thanks.
  brent

-- 
All opinions expressed are My own, unless otherwise attributed. In presenting 
facts, I expressly reserve the right to be Wrong. Portions of this message 
authored by Me are subject to the FTL ( http://rcfile.org/ftl/ )

Re: hacking gcc - avoiding bootstrap?

[Phil Edwards]

On Fri, Sep 29, 2000 at 04:05:09PM -0400, brent@rcfile.org wrote:
> quick question:
>   if files (e.g., gcc/cp/decl.c) are modified, how can I avoid
>   bootstrapping to test any modifications?

Good question; I went through this same thing.

'make all' at the top level (or in the gcc subdir) will build everything just
once.  If you know you have a completely working C compiler installed already
to do the build, then that's usually good enough for most sub-projects
(like C++-related things).  For stuff that affects the core C compiler,
you should always do a full bootstrap for the additional testing.

The people actually in charge will now correct any of my misconceptions.  :-)


-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

hacking gcc - avoiding bootstrap?

[brent]

Hi,

quick question:
  if files (e.g., gcc/cp/decl.c) are modified, how can I avoid
  bootstrapping to test any modifications?

thanks.
  brent

-- 
All opinions expressed are My own, unless otherwise attributed. In 
presenting facts, I expressly reserve the right to be Wrong. Portions
of this message authored by Me are subject to the Free Thought License