From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yuval Hager To: gdb@sourceware.cygnus.com Subject: gdb with solaris CC Date: Fri, 20 Aug 1999 03:26:00 -0000 Message-id: X-SW-Source: 1999-q3/msg00212.html 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 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 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 , 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 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 http://andromeda.cup.hp.com/ (inside HP's firewall only) http://www.geocities.com/SiliconValley/Monitor/7464/