The SPARC target

The SPARC target

[Mark Kettenis]

Folks,

The SPARC target has been unmaintained for quite some time now[1]
(since november 2001) and it shows.  It doesn't compile on FreeBSD,
and running the testsuite on FreeBSD/sparc64 (after fixing it),
Solaris 2.8 and NetBSD/sparc results in hundreds of unexpected
failures with quite a few unresolved testcases.  I think the target is
bordering on (un)usability.

It's obvious what's wrong: the code is in a very bad shape.  It's
deprecation and obsoletion everywhere.  It's gotten to a point where
*I* can't make any sense out of it anymore.  Instead of fixing the old
broken code, I started implementing a FreeBSD/sparc64 target from
scratch.  Even though my work isn't finished yet, it already does a
better job than the existing SPARC target.  Of course it uses the new
unwinder framework.  I hope to be able to finish it in the coming
weeks, and check it in alongide the old code.  The new target is
64-bit only (which is fine for FreeBSD/sparc64), but I have
anticipated on writing the 32-bit bits.  When those are ready I intend
to convert all "active" SPARC targets to use the new code, replacing
the old 32-bit code with the new 32-bit code.  Unfortunately, I won't
be able to test all SPARC targets.  As a result we'll probably end up
with a number of broken SPARC targets.  Consider this message as a
HEADS UP.

Mark

[1] Maintenance only since november 2001 according to the CVS hostory
of the MAINTAINERS file.

Re: The SPARC target

[Daniel Jacobowitz]

On Sun, Aug 17, 2003 at 10:48:47PM +0200, Mark Kettenis wrote:
> Folks,
> 
> The SPARC target has been unmaintained for quite some time now[1]
> (since november 2001) and it shows.  It doesn't compile on FreeBSD,
> and running the testsuite on FreeBSD/sparc64 (after fixing it),
> Solaris 2.8 and NetBSD/sparc results in hundreds of unexpected
> failures with quite a few unresolved testcases.  I think the target is
> bordering on (un)usability.
> 
> It's obvious what's wrong: the code is in a very bad shape.  It's
> deprecation and obsoletion everywhere.  It's gotten to a point where
> *I* can't make any sense out of it anymore.  Instead of fixing the old
> broken code, I started implementing a FreeBSD/sparc64 target from
> scratch.  Even though my work isn't finished yet, it already does a
> better job than the existing SPARC target.  Of course it uses the new
> unwinder framework.  I hope to be able to finish it in the coming
> weeks, and check it in alongide the old code.  The new target is
> 64-bit only (which is fine for FreeBSD/sparc64), but I have
> anticipated on writing the 32-bit bits.  When those are ready I intend
> to convert all "active" SPARC targets to use the new code, replacing
> the old 32-bit code with the new 32-bit code.  Unfortunately, I won't
> be able to test all SPARC targets.  As a result we'll probably end up
> with a number of broken SPARC targets.  Consider this message as a
> HEADS UP.

This is wonderful news.  If you need any testing on sparc-linux please
let me know.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: The SPARC target

[Jiri Gaisler]

Mark Kettenis wrote:

> Folks,
> 
> The SPARC target has been unmaintained for quite some time now[1]
> (since november 2001) and it shows.  It doesn't compile on FreeBSD,
> and running the testsuite on FreeBSD/sparc64 (after fixing it),
> Solaris 2.8 and NetBSD/sparc results in hundreds of unexpected
> failures with quite a few unresolved testcases.  I think the target is
> bordering on (un)usability.


I would like to point out that the sparc port works quite well
for embedded (o/s unaware) 32-bit targets, at least up to gdb-5.3 .
There are some (minor) quirks with stack unwinding to form the
function backtrace, but overall it makes a good job. If you make
a new (64-bit) backend, could the old 32-bit backend remain, at
least the O/S independent parts?

Thanks, Jiri Gaisler.
-- 
-------------------------------------------------------------------------
Gaisler Research, Stora Nygatan 13, 41108 Goteborg, Sweden, +46-31802405
fax: +46-31802407 email: info@gaisler.com, home page: www.gaisler.com
-------------------------------------------------------------------------

Re: The SPARC target

[Mark Kettenis]

Jiri Gaisler <jiri@gaisler.com> writes:

> Mark Kettenis wrote:
> 
> > Folks,
> > 
> > The SPARC target has been unmaintained for quite some time now[1]
> > (since november 2001) and it shows.  It doesn't compile on FreeBSD,
> > and running the testsuite on FreeBSD/sparc64 (after fixing it),
> > Solaris 2.8 and NetBSD/sparc results in hundreds of unexpected
> > failures with quite a few unresolved testcases.  I think the target is
> > bordering on (un)usability.
> 
> 
> I would like to point out that the sparc port works quite well
> for embedded (o/s unaware) 32-bit targets, at least up to gdb-5.3 .
> There are some (minor) quirks with stack unwinding to form the
> function backtrace, but overall it makes a good job. If you make
> a new (64-bit) backend, could the old 32-bit backend remain, at
> least the O/S independent parts?

Well, most of the bitrot seems to have taken place after the 5.3
release.  So I'm not at all confident that it still works to your
satisfaction.  I'm working on the 32-bit SPARC target now, and I'm
pretty confident that I can get it in a shape where it works better
than GDB 5.3.  It's not until then that I'll replace the old code with
my new implementation.

Just out of curiosity.  What's the --target you use to configure the
GDB you're using to debug your embedded system?

Mark

Re: The SPARC target

[Jiri Gaisler]

Mark Kettenis wrote:

> Well, most of the bitrot seems to have taken place after the 5.3
> release.  So I'm not at all confident that it still works to your
> satisfaction.  I'm working on the 32-bit SPARC target now, and I'm
> pretty confident that I can get it in a shape where it works better
> than GDB 5.3.  It's not until then that I'll replace the old code with
> my new implementation.
> 
> Just out of curiosity.  What's the --target you use to configure the
> GDB you're using to debug your embedded system?

I have added my own target configuration (sparc-tsim-elf), which
is based on the sparc-elf target with some extra defines to
enable stack backtrace and support for hardware watchpoints.

Jiri.

-- 
-------------------------------------------------------------------------
Gaisler Research, Stora Nygatan 13, 41108 Goteborg, Sweden, +46-31802405
fax: +46-31802407 email: info@gaisler.com, home page: www.gaisler.com
-------------------------------------------------------------------------