Re: [PATCH] CRX port contribution

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Mon, 25 Apr 2005, Paul Woegerer wrote:

> I've already sent my port two weeks ago but did not get feedback so far.

I see nobody commented on the bit below, so I'll conveniently
let this reply also serve as a PING for the port submission.

> Target   | HMSLQNFICBD lqrcpfgmbdates
> ---------+---------------------------
> crx      |  M    F         p g b    s

"s" is for:

s       <arch> is the correct target to use with the simulator
        in /cvs/src.

If you have no simulator in /cvs/src (thus also having an "S"),
then you can't have "s".  So, the "s" is wrong there.

> I will also provide a simulator binary to allow testing with dejagnu.
> Please let me know who needs to get it.

Maybe it's just my reading, but it seems like the point was
missed a little bit.

Background: some people (*cough*) prefer to test their general
code-changing GCC patches on a wide range of architectures. See
<URL:http://gcc.gnu.org/contribute.html#testing>.  Assuming "S"
and "s" above and a proper makefile (just a makefile calling
contrib/regression/btest-gcc.sh) all it takes to include your
target would be to add "crx", to a list before running "make
regtest".  Refer to <URL:http://gcc.gnu.org/simtest-howto.html>,
which has grew a few bugs and apparently doesn't work as is, but
hopefully you get the idea.

This means there has to be a dejagnu board description file "in
the right place" as well.  (If it's not in the dejagnu release
supposedly installed in /usr/share/dejagnu/baseboards (or
/usr/local/share... or the dejagnu module in simtest-howto.html)
then you can point to a directory with the file in your
"~/.dejagnurc".  See the DejaGNU documentation.)

However, if the simulator has to be fetched from somewhere else,
the threshold of including your target is suddenly a lot higher,
and one likely settles for the half-a-dozen existing simulator
architectures with S and s.  This threshold raises to the height
of Mt. Everest (again for some people, myself included) if
there's only a *binary* to be downloaded from somewhere else.

Therefore I urge you (and other port contributors) to take the
time to submit a simulator for GDB (thus "in /cvs/src"), a
newlib port that works with the simulator, and a dejagnu
baseboard file.  (Yes, source code for the simulator, not
binaries.  And a binutils port, but you already have that in
place.)

Doing this will enable people to easily test *their* generic
changes on *your GCC port* and thus avoid introducing bugs that
break your GCC port, but works for others.

Now what's in it for you and your company:
Debugging such bugs is often very time-consuming, and you or
someone from your company would more often be the one debugging
them, lacking a simulator with low threshold for its use as
outlined above.  It doesn't take many such bugs for the effort
to pay off.

(In theory you should then be able to "simply" binary-search for
the patch that caused the bug, and ask the person who introduced
the bug to fix it, but I'm not sure we're there.  But it does
simplify bug-fixing by others [and avoiding it!] for the benefit
of the health of your port.)

I hope this made sense to you.

brgds, H-P