Anyone using alpha-freebsd target in gdb-current?

Anyone using alpha-freebsd target in gdb-current?

[Jason R Thorpe]

Is anyone actually using the alpha-freebsd target in gdb-current?
   
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.

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).

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.

Thanks.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

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

[Mark Kettenis]

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

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

[Jason R Thorpe]

On Thu, Jan 10, 2002 at 09:55:44AM +0100, Mark Kettenis wrote:

 > 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.

Should it also work with GCC 2.95.3?

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

The lossage I'm seeing seems totally irrelavent to debugging symbols,
unfortunately.

 > 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.

Yes, it's ELF, and it uses solib-svr4.c.  I'm referring to
bkpt_names[] in solib-svr4.c:

#define BKPT_AT_SYMBOL 1
   
#if defined (BKPT_AT_SYMBOL)
static char *bkpt_names[] =
{
#ifdef SOLIB_BKPT_NAME
  SOLIB_BKPT_NAME,              /* Prefer configured name if it exists. */
#endif
  "_start",
  "main",
  NULL
};
#endif

_start is the executable entry point on FreeBSD/alpha.  It's __start on
NetBSD/alpha, and thus my alpha/tm-nbsd.h defines:

#define SOLIB_BKPT_NAME "__start"

As I understand the use of bkpt_names[], it's used to create a solib
event when all of the default shared libraries are loaded for a program.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

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

[Jason R Thorpe]

On Thu, Jan 10, 2002 at 09:55:44AM +0100, Mark Kettenis wrote:

 > > 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!

Okay, well, here is something I would appreciate a sanity-check on.

Breakpoints are definitely having a problem on the alpha target.  For the
following simple program:

GNU gdb 2002-01-12-cvs
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "alpha-unknown-netbsd"...
(gdb) list main
1       int
2       main(int argc, char *argv[])
3       {
4               int a, b, c, d;
5       
6               a = 1;
7               b = 2;
8               c = 3;
9               d = 4;
10              printf("a = %d, b = %d, c = %d, d = %d\n", a, b, c, d);
(gdb) break 9
Breakpoint 1 at 0x120000dbc: file foo.c, line 9.
(gdb) run
Starting program: /var/tmp/a.Breakpoint 1, main (argc=1, argv=0x1fffff4d0) at foo.c:9
9               d = 4;
(gdb) print a
$1 = 1
(gdb) print b
$2 = 2
(gdb) print c
$3 = 3
(gdb) cont
Continuing.
a = 1, b = 2, c = 3, d = 0

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) 

If I do not set that breakpoint, then "d" is set properly.  (Yah,
I haven't figured out why it segv's on exit yet, that's pretty cute,
too.)

Now, if you look at what happens during a software single-step:

(gdb) break main
Breakpoint 1 at 0x120000d98: file foo.c, line 3.
(gdb) run
Starting program: /var/tmp/a.out 
*** FOUND .interp SECTION

Breakpoint 1, main (argc=-32, argv=0x1) at foo.c:3
3       {
(gdb) stepi
0x120000da0     3       {
(gdb) 
0x120000da8     6               a = 1;
(gdb) 
0x120000db0     7               b = 2;
(gdb) 

Note the PC value is incrementing by 8 each time -- this is wrong, it should
be incrementing by 4.  This, combined with my failure above, leads me to
believe that the PC is not being adjusted properly when the breakpoint is
tripped.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

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

[Jason R Thorpe]

On Thu, Jan 10, 2002 at 09:55:44AM +0100, Mark Kettenis wrote:

 > > 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.

FWIW, I found the problem -- there was a slight bug in my software
single-step implementation, and it now all works fine.  I'll submit
the NetBSD/alpha changes for approval shortly.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>