gdb with solaris CC

gdb with solaris CC

[Yuval Hager]

Hi,

Has anyone tried to debug code compiled with sun solaris CC ?

I have gdb-4.16 (with a patch for shared libraries) and CC 4.2 
on a solaris-2.6-x86 machine.

The best thing I got is seeing the stack (with mangled names - but
I can use `dem' to see the names), but in no way I could
get the current line.
The gdb claims that all the functions in the stack are in 
`../include/some_file.hxx:243' (all on the same file+line)

Why is that ?
Is there anyway to get over it ?

Is there anyway to get the current line ? might be even a complicated 
way, but I just need to know the line of the SEGV and from there I can
continue in my head :-)

Thanks,

Yuval Hager
yuvalh@iname.com

PS - sorry if this was discussed before, but I couldn't find it in the
     archives.
From jtc@redback.com Fri Aug 20 07:38:00 1999
From: jtc@redback.com (J.T. Conklin)
To: msnyder@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Code in can_use_hardware_watchpoint()
Date: Fri, 20 Aug 1999 07:38:00 -0000
Message-id: <5mr9kyo6u8.fsf@jtc.redbacknetworks.com>
References: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com> <37BCE7F2.7BB8@cygnus.com>
X-SW-Source: 1999-q3/msg00213.html
Content-length: 1262

>>>>> "Michael" == Michael Snyder <msnyder@cygnus.com> writes:
>> But I'm wondering if instead the v->modifiable == 0 should be == 1
>> instead.

Michael> Could you elaborate on that thought?  I'm not sure I
Michael> understand why the function should give a negative return if
Michael> a subexpression is not_lval and !modifiable.  Is it trying to
Michael> detect constants?  Or what?

I not sure what 'v->lval != not_lval && v->modifiable == 0' is trying
to catch.  I put a breakpoint at can_use_hardware_watchpoint(), tried
every sort of watch expression I could expect, and only found nodes
with v->lval == lval_memory, v->lval == lval_register, and v->lval ==
not_lval && v->modifiable == 0.  Because I didn't see anything that
tripped that expression, I thought that it might contain a bug.  If
not, it's in desparate need of a comment...

When I suggested changing the expression to 'v->lval != not_lval &&
v->modifiable == 1', I was thinking that anything that's modifiable
that isn't in memory should be rejected.

I thought that a catch all expression might be better in case new
value types are added.  In fact, it looks like lval_reg_frame_relative
types should be rejected one way or the other now.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From tich@ma.ikos.com Fri Aug 20 07:42:00 1999
From: Richard Cownie <tich@ma.ikos.com>
To: freebsd-current@freebsd.org.gdb@sourceware.cygnus.com
Cc: tich@par28.ma.ikos.com
Subject: gdb-4.17 in FreeBSD 4.0-CURRENT
Date: Fri, 20 Aug 1999 07:42:00 -0000
Message-id: <99082010412803.11889@par28.ma.ikos.com>
X-SW-Source: 1999-q3/msg00214.html
Content-length: 927

I managed to build gdb-4.17 in FreeBSD 4.0, here's how to do it:

1) gdb-4.17/configure --host=i386-unknown-freebsdelf4.0
    Have to specify the host explicitly, otherwise it doesn't realize
    it needs to use ELF.

2) in gdb-4.17/Makefile, add "-DSVR4_SHARED_LIBS" to definition of CFLAGS

3) in gdb-4.17/gdb/solib.c, add #include "elf/common.h" 
    (after #include "elf/external.h")

4) in gdb-4.17/gdb/infptrace.c, add #define U_REGS_OFFSET 0x1fa8
    I figured out this number the hard way by searching all the valid PT_READ_U
    addresses and comparing the results with PT_GETREGS - found locations
    where eip and esp values matched up.  Doubtless there's a better way to
    get the right value.

Then it should all build (and perhaps work).  The same hacks probably apply
to gdb-4.18 and gdb-current (but so far gdb-4.17 is the most useful version
I've seen for debugging C++).

Richard Cownie (tich@ma.ikos.com)
From ovidiu@cup.hp.com Fri Aug 20 10:22:00 1999
From: ovidiu@cup.hp.com
To: ovidiu@cup.hp.com
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb@sourceware.cygnus.com, insight@sourceware.cygnus.com
Subject: Re: Proposal: --with-gdb-interpreter=... --interpreter=... 
Date: Fri, 20 Aug 1999 10:22:00 -0000
Message-id: <199908201721.KAA07605@hercules.cup.hp.com>
References: <199908200605.XAA02169@hercules.cup.hp.com>
X-SW-Source: 1999-q3/msg00215.html
Content-length: 868

On Thu, 19 Aug 1999 23:05:13 -0700, ovidiu@cup.hp.com wrote:

> On Thu, 19 Aug 1999 10:38:33 +1000, Andrew Cagney <ac131313@cygnus.com> wrote:
> 
> > [...]
> >
> > 	o	a new option ``--interpreter=...'' that can be used
> > 		to specify the interpreter to use during startup.
> 
> I propose the flag to be simply called -perl, -python, -tcl, -guile etc. In
> addition to this the flag should take an additional argument which should
> represent the name of a script in that language. This would allow the user to
> write full scripts to work with gdb.

I forgot to say it, but this allows one to write things like:

#! /bin/gdb -perl

# insert your favorite Perl code here to manipulate gdb's internals


Greetings,
--
Ovidiu Predescu <ovidiu@cup.hp.com>
http://andromeda.cup.hp.com/  (inside HP's firewall only)
http://www.geocities.com/SiliconValley/Monitor/7464/