Changing the C/C++ compiler for gdb testsuite runs

Changing the C/C++ compiler for gdb testsuite runs

[Richard Earnshaw]

I'm not a dejagnu expert, so the answer to this may be obvious.  

Is there a way of forcing the GDB testsuite to use a particular compiler 
that hasn't yet been installed (I have a gcc-3 compiler from a build tree 
that I'd like to use to run the tests, but I don't particularly want to 
have to install it first).  I've tried running

	make check 

with both CC_FOR_TARGET and CC set to point to the compiler, but neither 
seems to work.  There doesn't appear to be anything on this in the gdb 
internals manual either.

R.

Re: Changing the C/C++ compiler for gdb testsuite runs

[Michael Snyder]

Richard Earnshaw wrote:
> 
> I'm not a dejagnu expert, so the answer to this may be obvious.
> 
> Is there a way of forcing the GDB testsuite to use a particular compiler
> that hasn't yet been installed (I have a gcc-3 compiler from a build tree
> that I'd like to use to run the tests, but I don't particularly want to
> have to install it first).  I've tried running
> 
>         make check
> 
> with both CC_FOR_TARGET and CC set to point to the compiler, but neither
> seems to work.  There doesn't appear to be anything on this in the gdb
> internals manual either.

If you build both gcc and gdb in the same build tree, 
the tests will use the gcc from the build tree.

Re: Changing the C/C++ compiler for gdb testsuite runs

[Richard Earnshaw]

> > Is there a way of forcing the GDB testsuite to use a particular compiler
> > that hasn't yet been installed (I have a gcc-3 compiler from a build tree
> > that I'd like to use to run the tests, but I don't particularly want to
> > have to install it first).  I've tried running
> > 
> >         make check
> > 
> > with both CC_FOR_TARGET and CC set to point to the compiler, but neither
> > seems to work.  There doesn't appear to be anything on this in the gdb
> > internals manual either.
> 
> If you build both gcc and gdb in the same build tree, 
> the tests will use the gcc from the build tree.

But since they don't come from the same CVS tree, I can't see how to do 
that cleanly without dicking around with the common code directories such 
as libiberty and include -- experience has shown that with the public CVS 
repositories that is fraught with problems.  I have done it in the past, 
but it breaks the principal that the sources you are testing are the 
sources you are committing, so it isn't really a viable option.

R.

Re: Changing the C/C++ compiler for gdb testsuite runs

[Andrew Cagney]

> But since they don't come from the same CVS tree, I can't see how to do 
> that cleanly without dicking around with the common code directories such 
> as libiberty and include -- experience has shown that with the public CVS 
> repositories that is fraught with problems.  I have done it in the past, 
> but it breaks the principal that the sources you are testing are the 
> sources you are committing, so it isn't really a viable option.


Is the experience recent?  At present mechanical processes help to 
ensure that liberty and include are kept very much in sync (typically 
only hours separate commits).

Andrew

Re: Changing the C/C++ compiler for gdb testsuite runs

[Richard Earnshaw]

> 
> > But since they don't come from the same CVS tree, I can't see how to do 
> > that cleanly without dicking around with the common code directories such 
> > as libiberty and include -- experience has shown that with the public CVS 
> > repositories that is fraught with problems.  I have done it in the past, 
> > but it breaks the principal that the sources you are testing are the 
> > sources you are committing, so it isn't really a viable option.
> 
> 
> Is the experience recent?  At present mechanical processes help to 
> ensure that liberty and include are kept very much in sync (typically 
> only hours separate commits).
> 
> Andrew
> 

Well it can happen at any time when one product is coming off a branch and 
the other of the trunk (or a different branch).  When gcc forks (or gdb 
forks) there is bound to be divergence (for obvious reasons).

R.

Re: Changing the C/C++ compiler for gdb testsuite runs

[Andrew Cagney]

> Is the experience recent?  At present mechanical processes help to 
>> ensure that liberty and include are kept very much in sync (typically 
>> only hours separate commits).
>> 
>> Andrew
>> 
> 
> 
> Well it can happen at any time when one product is coming off a branch and 
> the other of the trunk (or a different branch).  When gcc forks (or gdb 
> forks) there is bound to be divergence (for obvious reasons).


Hmm, for that senario, testing GDB against an installed GCC is always best.

Andrew

Re: Changing the C/C++ compiler for gdb testsuite runs

[Michael Elizabeth Chastain]

Richard Earnshaw writes:
> Is there a way of forcing the GDB testsuite to use a particular compiler 
> that hasn't yet been installed (I have a gcc-3 compiler from a build tree 
> that I'd like to use to run the tests, but I don't particularly want to 
> have to install it first).

I build my compilers with "prefix=/blah/blah/2002-01-10/blah ...."
and then I go ahead and install the compiler.  When I run the gdb test
suite, I set $PATH to the place where the compiler-under-test lives.

You may need to set $LD_LIBRARY_PATH as well if you build gcc with shared
libraries (libgcc and libstdc++).

If you build gcc and gdb in a unified build tree then dejagnu will find
and use the uninstalled compiler in the unified build tree, even in
preference to $PATH.  That behaviour actually got in my way so I stopped
using unified trees.

Michael C

Re: Changing the C/C++ compiler for gdb testsuite runs

[Kevin Buettner]

On Jan 10, 10:58am, Michael Elizabeth Chastain wrote:

> If you build gcc and gdb in a unified build tree then dejagnu will find
> and use the uninstalled compiler in the unified build tree, even in
> preference to $PATH.  That behaviour actually got in my way so I stopped
> using unified trees.

Here's one way to use a different compiler in a unified tree...

    1) In gdb/testsuite (in your build directory), do

	    make site.exp

    2) Add lines similar to the following to the end of
       gdb/testsuite/site.exp:
       
	    set CC_FOR_TARGET "/some/other/path/to/gcc"
	    set CXX_FOR_TARGET "/some/other/path/to/g++"

If anyone knows of other (more elegant) tricks that can be used to
accomplish the same thing, I'd like to hear about them...

Kevin

Re: Changing the C/C++ compiler for gdb testsuite runs

[Daniel Jacobowitz]

On Thu, Jan 10, 2002 at 12:09:33PM -0700, Kevin Buettner wrote:
> On Jan 10, 10:58am, Michael Elizabeth Chastain wrote:
> 
> > If you build gcc and gdb in a unified build tree then dejagnu will find
> > and use the uninstalled compiler in the unified build tree, even in
> > preference to $PATH.  That behaviour actually got in my way so I stopped
> > using unified trees.
> 
> Here's one way to use a different compiler in a unified tree...
> 
>     1) In gdb/testsuite (in your build directory), do
> 
> 	    make site.exp
> 
>     2) Add lines similar to the following to the end of
>        gdb/testsuite/site.exp:
>        
> 	    set CC_FOR_TARGET "/some/other/path/to/gcc"
> 	    set CXX_FOR_TARGET "/some/other/path/to/g++"
> 
> If anyone knows of other (more elegant) tricks that can be used to
> accomplish the same thing, I'd like to hear about them...

I do this by different board files.

In dejagnu/baseboards, copy unix.exp.  Edit it.  It should originally
say:

set_board_info compiler  "[find_gcc]";


I have:
set_board_info compiler  "/opt/src/gcc/install-30/bin/gcc";
set_board_info c++compiler  "/opt/src/gcc/install-30/bin/g++";

There's matching variables for all the other compiler types (Java etc). 
I don't yet test those.

Then, to run:
../../../src/dejagnu/runtest --target_board "unix unix3" blah.exp

That will run tests for both the default GCC and the custom in
install-30.  You can also do:
  --target_board "unix/gdb:debug_flags=-gdwarf-2"
to test DWARF-2, or likewise for any other flag.  There's a pure
/dwarf2 option but don't use it; that's dwarf-1 level 2.  I've been
forgetting to file a DejaGNU bug report about this.

The results of this thread should go in the GDB manual somewhere!

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Changing the C/C++ compiler for gdb testsuite runs

[Daniel Jacobowitz]

On Thu, Jan 10, 2002 at 02:30:40PM -0500, Daniel Jacobowitz wrote:
> I do this by different board files.
> 
> In dejagnu/baseboards, copy unix.exp.  Edit it.  It should originally
> say:
> 
> set_board_info compiler  "[find_gcc]";
> 
> 
> I have:
> set_board_info compiler  "/opt/src/gcc/install-30/bin/gcc";
> set_board_info c++compiler  "/opt/src/gcc/install-30/bin/g++";
> 
> There's matching variables for all the other compiler types (Java etc). 
> I don't yet test those.
> 
> Then, to run:
> ../../../src/dejagnu/runtest --target_board "unix unix3" blah.exp
> 
> That will run tests for both the default GCC and the custom in
> install-30.  You can also do:
>   --target_board "unix/gdb:debug_flags=-gdwarf-2"
> to test DWARF-2, or likewise for any other flag.  There's a pure
> /dwarf2 option but don't use it; that's dwarf-1 level 2.  I've been
> forgetting to file a DejaGNU bug report about this.
> 
> The results of this thread should go in the GDB manual somewhere!

As a followup, note that you can _NOT_ test multiple debug formats the
way that GCC tests multilibs.

You need to run with unix/gdb:debug_flags=-gdwarf-2, not just
unix/-gdwarf-2.  If you do the latter, most tests will be compiled with
-g -gdwarf-2 (harmless), but nodebug.exp will be build with -gdwarf-2. 
Oops.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Changing the C/C++ compiler for gdb testsuite runs

[Andrew Cagney]

> The results of this thread should go in the GDB manual somewhere!


FYI, the internals section has a section on running the testsuite.

Andrew

Re: Changing the C/C++ compiler for gdb testsuite runs

[Michael Elizabeth Chastain]

I built unified trees about once per week last summer.

My experience:

  + they do solve Richard's original problem, which is:
    testing a gcc without installing it

  + once I sorted out my symlink script, I had no trouble
    with libiberty or include or other shared directories.
    And they are synced even tighter today.

  - it did bother me that I was not building the packages
    in the same way that they would be released.

  - I like to test with several different versions of gcc
    so it's better for me to build in separate trees anyways.

Michael C