Re: Anyone using alpha-freebsd target in gdb-current?

[Mark Kettenis <kettenis at science dot uva dot nl>]

Jason R Thorpe <thorpej@wasabisystems.com> writes:

> Is anyone actually using the alpha-freebsd target in gdb-current?

I guess it's not really actively used.

I did the port to alpha-freebsd-5.0 (a.k.a. freebsd-current).  I still
work on it from time to time, and it should work reasonably with a
recent gcc.

The system compiler for freebsd-current generates unusable debug
output, both for stabs and dwarf2.  Gcc 3.0 and above should do much better.

> I'm working on alpha-netbsd support, and it uses the pre-existing
> alphabsd-nat.c.
> 
> ...but I'm having some serious problems.  They seem to be related
> to breakpoints -- If I skip the implicit breakpoint at __start
> (_start on a FreeBSD/alpha system) a test program behaves "more
> correctly" (there are still some problems), but completely loses
> if I leave that breakpoint there.

Isn't NetBSD/alpha using ELF?  In that case it shouldn't set any
implicit breakpoints at __start.  If NetBSD/alpha doesn't use ELF,
then you might need to work on getting the old SunOS/a.out shared
library support working on NetBSD/alpha.

I recently had some problems on FreeBSD/alpha with backtraces.  GDB
just fell off the stack, because it couldn't determine the top of the
stack.  This was caused by not having debug info for crt*.o.  I fixed
it by choosing another way to determine the top of the stack, based on
the filename.

> Also, NetBSD/alpha requires software single-stepping in gdb (which
> I have implemented), which uses breakpoints ... the software single
> stepping also gives unexpected results (the PC value when the breakpoint
> trips is not what I expect).

I'm afraid I cannot help you here.

> But, anyway, I'd really like to just know if anyone is successfully using
> the alpha bsd native support successfully right now.  That would help
> eliminate some variables for me.

Feel free to ask!

Mark