Re: GDB question [ at least at first... ]

[Alan Somers]

On Sun, Feb 19, 2017 at 1:33 AM, Jeffrey Bouquet
 wrote:
> I've a custom kernel r313487 without, and
> another with, debugging lines re-added.
> [ i386 ]
>
> With daily vmcore in /var/crash from the
> former, can the latter be used with GDB
> [ the larger kernel ] to evaluate the
> core file from the  non-debugging, thinner
> kernel?

No.  A debugging kernel isn't just a regular kernel with symbols.  It
also adds many more runtime assertions.  The symbols from one won't
match up with the core from another.

>
> And if so, better to learn GDB here or
> send it off as an attachment to an
> expert ??

There's never a bad time to learn GDB! It'll still work even on your
non-debug kernel.  You should try it out, and learn as much as you
can.  When you feel like you've gone as far as you can by yourself,
then go ahead and post your problem to a mailing list of Bugzilla.  Be
sure to post the full stack trace.  And search for it on Bugzilla
before you post it; you may not be the first person to experience this
bug.

-Alan

>
> The crashes almost uniformly
> [ 3/4 of them ] happen during
> seamonkey or links -g,  and also
> after the
> recent seamonkey upgrade
> VS before,  which almost
> wrecked the install... if it matters any.
> OR, the fixes I did to the almost-wrecked
> install made it unstable to run
> a browser within. OR, some sysctl
> is not tuned to the recent hardware...
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gdb problem

[Allan Jude]

On 2014-03-19 23:03, Nilton Jose Rizzo wrote:
 I have problem with debug some files compiled with clang, my gbd from system 
 is 6.1.1, like showed.
 
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 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 amd64-marcel-freebsd...Dwarf Error: wrong version
 in compilation unit header (is 4, should be 2) [in module
 /home2/rizzo/src/Doutorado/main]
 
 
 and when I try to debug a program (main) show this error mesage.
 
 What I do wrong?
 
 Thanks 
 
 P.S. the gdb of ports have a compile error, I send a mesage to mainteiner
 
 Rizzo
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 

The debug format changed, so the gdb in base isn't much use anymore. You
can try lldb or gdb from ports (when it is fixed). Did you try grabbing
the compiled package of gdb from pkgng?

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: gdb has outdated knowledge of signal trampolines

[Konstantin Belousov]

On Mon, Nov 25, 2013 at 07:35:27PM +0200, Konstantin Belousov wrote:
 Could you update your gdb patch to use the KERN_PROC_SIGTRAMP from
 the patch below ? If this works out, I will add initialization of
 sv_szsigcode for ABIs which do not use shared page.

Below is the complete patch.  With it applied, I get
(gdb) bt
#0  sighandler (signo=1, info=0x7fffd2b0, context=Unhandled dwarf 
expression opcode 0xf3
) at siginfo.c:34
#1  signal handler called
#2  0x00080088849a in sigsuspend () from /lib/libc.so.7
#3  0x0040093a in main (argc=Unhandled dwarf expression opcode 0xf3
) at siginfo.c:54

diff --git a/contrib/gdb/gdb/amd64fbsd-nat.c b/contrib/gdb/gdb/amd64fbsd-nat.c
index f083734..dacd4a3 100644
--- a/contrib/gdb/gdb/amd64fbsd-nat.c
+++ b/contrib/gdb/gdb/amd64fbsd-nat.c
@@ -29,6 +29,7 @@
 #include sys/types.h
 #include sys/ptrace.h
 #include sys/sysctl.h
+#include sys/user.h
 #include machine/reg.h
 
 #ifdef HAVE_SYS_PROCFS_H
@@ -212,24 +213,23 @@ Please report this to bug-...@gnu.org.,
 
   SC_RBP_OFFSET = offset;
 
-  /* FreeBSD provides a kern.ps_strings sysctl that we can use to
+  /* FreeBSD provides a kern.proc.sigtramp sysctl that we can use to
  locate the sigtramp.  That way we can still recognize a sigtramp
- if its location is changed in a new kernel.  Of course this is
- still based on the assumption that the sigtramp is placed
- directly under the location where the program arguments and
- environment can be found.  */
+ if its location is changed in a new kernel. */
   {
-int mib[2];
-long ps_strings;
+int mib[4];
+struct kinfo_sigtramp kst;
 size_t len;
 
 mib[0] = CTL_KERN;
-mib[1] = KERN_PS_STRINGS;
-len = sizeof (ps_strings);
-if (sysctl (mib, 2, ps_strings, len, NULL, 0) == 0)
+mib[1] = KERN_PROC;
+mib[2] = KERN_PROC_SIGTRAMP;
+mib[3] = getpid();
+len = sizeof (kst);
+if (sysctl (mib, sizeof(mib) / sizeof(mib[0]), kst, len, NULL, 0) == 0)
   {
-   amd64fbsd_sigtramp_start_addr = ps_strings - 32;
-   amd64fbsd_sigtramp_end_addr = ps_strings;
+   amd64fbsd_sigtramp_start_addr = kst.ksigtramp_start;
+   amd64fbsd_sigtramp_end_addr = kst.ksigtramp_end;
   }
   }
 }
diff --git a/sys/amd64/include/pcb.h b/sys/amd64/include/pcb.h
index c106edc..80aff86 100644
--- a/sys/amd64/include/pcb.h
+++ b/sys/amd64/include/pcb.h
@@ -43,6 +43,7 @@
 #include machine/fpu.h
 #include machine/segments.h
 
+#ifdef __amd64__
 struct pcb {
register_t  pcb_r15;
register_t  pcb_r14;
@@ -105,6 +106,7 @@ struct pcb {
 
uint64_tpcb_pad[3];
 };
+#endif
 
 #ifdef _KERNEL
 struct trapframe;
diff --git a/sys/amd64/include/segments.h b/sys/amd64/include/segments.h
index d9f4280..6bcadc7 100644
--- a/sys/amd64/include/segments.h
+++ b/sys/amd64/include/segments.h
@@ -82,8 +82,8 @@ structsoft_segment_descriptor {
  * region descriptors, used to load gdt/idt tables before segments yet exist.
  */
 struct region_descriptor {
-   unsigned long rd_limit:16;  /* segment extent */
-   unsigned long rd_base:64 __packed;  /* base address  */
+   uint64_t rd_limit:16;   /* segment extent */
+   uint64_t rd_base:64 __packed;   /* base address  */
 } __packed;
 
 #ifdef _KERNEL
diff --git a/sys/compat/freebsd32/freebsd32.h b/sys/compat/freebsd32/freebsd32.h
index 8376e95..94f886e 100644
--- a/sys/compat/freebsd32/freebsd32.h
+++ b/sys/compat/freebsd32/freebsd32.h
@@ -362,6 +362,12 @@ struct kinfo_proc32 {
int ki_tdflags;
 };
 
+struct kinfo_sigtramp32 {
+   uint32_t ksigtramp_start;
+   uint32_t ksigtramp_end;
+   uint32_t ksigtramp_spare[4];
+};
+
 struct kld32_file_stat_1 {
int version;/* set to sizeof(struct kld_file_stat_1) */
charname[MAXPATHLEN];
diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c
index 9968e76..2e6bc32 100644
--- a/sys/kern/kern_proc.c
+++ b/sys/kern/kern_proc.c
@@ -2632,6 +2632,60 @@ errout:
return (error);
 }
 
+static int
+sysctl_kern_proc_sigtramp(SYSCTL_HANDLER_ARGS)
+{
+   int *name = (int *)arg1;
+   u_int namelen = arg2;
+   struct proc *p;
+   struct kinfo_sigtramp kst;
+   const struct sysentvec *sv;
+   int error;
+#ifdef COMPAT_FREEBSD32
+   struct kinfo_sigtramp32 kst32;
+#endif
+
+   if (namelen != 1)
+   return (EINVAL);
+
+   error = pget((pid_t)name[0], PGET_CANDEBUG, p);
+   if (error != 0)
+   return (error);
+   sv = p-p_sysent;
+#ifdef COMPAT_FREEBSD32
+   if ((req-flags  SCTL_MASK32) != 0) {
+   bzero(kst32, sizeof(kst32));
+   if (SV_PROC_FLAG(p, SV_ILP32)) {
+   if (sv-sv_sigcode_base != 0) {
+   kst32.ksigtramp_start = sv-sv_sigcode_base;
+   kst32.ksigtramp_end = sv-sv_sigcode_base +
+   *sv-sv_szsigcode;
+   

Re: gdb has outdated knowledge of signal trampolines

[Konstantin Belousov]

On Mon, Nov 25, 2013 at 12:13:53PM +0200, Andriy Gapon wrote:
 
 It seems that placement of signal trampolines was changed a while ago.  
 Possibly
 with the introduction of the shared page, but I am not sure.
 Unfortunately, neither the gdb in base nor the ports gdb were updated to 
 account
 for the new location.
 
 And thus, for example:
 (kgdb) bt
 #0  thr_kill () at thr_kill.S:3
 #1  0x0008032c89a7 in nsProfileLock::FatalSignalHandler (signo=6,
 info=optimized out, context=0x7b197630)
 at
 /usr/obj/ports/usr/ports/www/firefox/work/mozilla-release/obj-x86_64-unknown-freebsd11.0/toolkit/profile/nsProfileLock.cpp:180
 #2  0x000800f90596 in handle_signal (actp=optimized out, sig=6,
 info=0x7b1979a0, ucp=0x7b197630) at 
 /usr/src/lib/libthr/thread/thr_sig.c:237
 #3  0x000800f9013f in thr_sighandler (sig=6, info=0x0, 
 _ucp=0x7b197630)
 at /usr/src/lib/libthr/thread/thr_sig.c:182
 #4  0x7003 in ?? ()
 #5  0x000800f90010 in ?? () at /usr/src/lib/libthr/thread/thr_sig.c:566 
 from
 /lib/libthr.so.3
 #6  0x in ?? ()
 
 Obviously, the gdb is confused after the frame that has 0x7003.
 
 I looked only at amd64 code, but I believe that other platforms (all of them?)
 are affected as well.
 
 The following proof of concept patch for the base gdb seems to fix the case of
 native debugging on amd64 (target case was not tested).
 
 diff --git a/contrib/gdb/gdb/amd64fbsd-nat.c b/contrib/gdb/gdb/amd64fbsd-nat.c
 index f083734..d49dc45 100644
 --- a/contrib/gdb/gdb/amd64fbsd-nat.c
 +++ b/contrib/gdb/gdb/amd64fbsd-nat.c
 @@ -212,24 +212,23 @@ Please report this to bug-...@gnu.org.,
 
SC_RBP_OFFSET = offset;
 
 -  /* FreeBSD provides a kern.ps_strings sysctl that we can use to
 +  /* FreeBSD provides a kern.usrstack sysctl that we can use to
   locate the sigtramp.  That way we can still recognize a sigtramp
   if its location is changed in a new kernel.  Of course this is
   still based on the assumption that the sigtramp is placed
 - directly under the location where the program arguments and
 - environment can be found.  */
 + directly at usrstack.  */
{
  int mib[2];
 -long ps_strings;
 +long usrstack;
  size_t len;
 
  mib[0] = CTL_KERN;
 -mib[1] = KERN_PS_STRINGS;
 -len = sizeof (ps_strings);
 -if (sysctl (mib, 2, ps_strings, len, NULL, 0) == 0)
 +mib[1] = KERN_USRSTACK;
 +len = sizeof (usrstack);
 +if (sysctl (mib, 2, usrstack, len, NULL, 0) == 0)
{
 - amd64fbsd_sigtramp_start_addr = ps_strings - 32;
 - amd64fbsd_sigtramp_end_addr = ps_strings;
 + amd64fbsd_sigtramp_start_addr = usrstack;
 + amd64fbsd_sigtramp_end_addr = usrstack + 0x20;
}
}
  }
 diff --git a/contrib/gdb/gdb/amd64fbsd-tdep.c 
 b/contrib/gdb/gdb/amd64fbsd-tdep.c
 index e4e02ab..87c1484 100644
 --- a/contrib/gdb/gdb/amd64fbsd-tdep.c
 +++ b/contrib/gdb/gdb/amd64fbsd-tdep.c
 @@ -86,8 +86,8 @@ static int amd64fbsd_r_reg_offset[] =
  };
 
  /* Location of the signal trampoline.  */
 -CORE_ADDR amd64fbsd_sigtramp_start_addr = 0x7fc0;
 -CORE_ADDR amd64fbsd_sigtramp_end_addr = 0x7fe0;
 +CORE_ADDR amd64fbsd_sigtramp_start_addr = 0x7000;
 +CORE_ADDR amd64fbsd_sigtramp_end_addr = 0x7020;
 
  /* From machine/signal.h.  */
  int amd64fbsd_sc_reg_offset[] =
 

Yes, your observation is correct, but the patch could be improved.
Specifically, the location of the signal trampoline code which you
hard-coded into the patch is not guaranteed to be stable, and in fact
somewhat depends on the order of ABI sysvecs registration.  The size
of the signal trampoline is not fixed as well.

Real solution is to start provide vdso for signal trampolines, which
is probably the only real reason to have vdso at all. But this is
labor-intensive and I am not convinced that the ABI changes are worth it
right now.

Instead, I propose the following sysctl helper which should provide the
same 'hackish' way to get the trampoline location, which would work
both for 64bit and 32bit, for later on i386 and amd64. For core files,
this is as bad as before since we cannot guarantee stability of the
trampoline location.

Could you update your gdb patch to use the KERN_PROC_SIGTRAMP from
the patch below ? If this works out, I will add initialization of
sv_szsigcode for ABIs which do not use shared page.

Thank you for looking into this.

 sys/compat/freebsd32/freebsd32.h |  6 +
 sys/kern/kern_proc.c | 58 
 sys/sys/sysctl.h |  1 +
 sys/sys/user.h   |  6 +
 4 files changed, 71 insertions(+)

diff --git a/sys/compat/freebsd32/freebsd32.h b/sys/compat/freebsd32/freebsd32.h
index 8376e95..94f886e 100644
--- a/sys/compat/freebsd32/freebsd32.h
+++ b/sys/compat/freebsd32/freebsd32.h
@@ -362,6 +362,12 @@ struct kinfo_proc32 {
int ki_tdflags;
 };
 
+struct kinfo_sigtramp32 {
+   uint32_t 

Re: GDB - do we dare?

[Mark Kettenis]

   Date: Sun, 13 Jul 2003 16:49:12 -0700
   From: David O'Brien [EMAIL PROTECTED]

   On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote:
   Date: Fri, 11 Jul 2003 15:50:02 -0700
   From: Marcel Moolenaar [EMAIL PROTECTED]

   Gang,

   With the gcc(1) dust not even settled yet, I like to get some feedback
   on gdb(1). AFAICT, this is the deal:

   o  Both ia64 and amd64 need gdb(1) support before they can become a
  tier 1 platform. I think this implies upgrading to 5.3 the least.

Upgrading to 5.3 for amd64 won't really help.  While 5.3 included
support for amd64, I'm told it is seriously broken.  Since then, I've
almost completely reworked GDB's amd64 target, to bring it in line
with the i386 target, and adapt it to some major architectural changes
in GDB.  Based on that work, I've finished a FreeBSD/amd64 port
yesterday.  I'll try to get it on GDB's 6.0 release branch.  However,
backporting it to 5.3 would be a major PITA and IMHO a tremendous
waste of effort.

   Not sure about that.  I wish you would touch base with SuSE.  AMD has had
   SuSE do quite a lot of work to make GDB 5.3 very usable on AMD64.  I know
   there are parts of the work SuSE has yet to send to the GDB lists.  I am
   worried that FreeBSD's AMD64 bits will be too different from the Linux
   ones and FreeBSD won't be able to leverage the work AMD is paying SuSE to
   do.

I'll ask Andreas about it.  Rest assured that FreeBSD will benefit
from all the work that's being done on AMD64 Linux.  I'm working
closely with both Andreas and Michal from SuSE to get their work
integrated as soon as possible although I've let some of the patches
they submitted slip through the cracks.

   However, FreeBSD/sparc64 isn't properly supported in FSF GDB either.
   When Jason Thorpe added NetBSD/sparc64 support he did it very NetBSD
   specific rather than do it in a more general BSD/sparc64 way that all the
   BSD's could leverage.  Generalizing his bits is needed in the FSF GDB
   bits.

I noticed, and have been working on this.  Following Jason's track
isn't too difficult, and things can be made more generic rather
easily.  I'll try to get my work integrated before the 6.0 release.

Unfortunately, GDB's sparc target has been unmaintained for quite some
time now.  Because of architectural changes in GDB the code has become
a big mess of deprecated interfaces, and is almost unmaintainable
right now.  I'll do my best to improve things but I can't guarantee
that all problems will be fixed before the 6.0 release.

I'm not really familliar with the support for debugging FreeBSD
kernels in GDB since that support is not in the FSF tree.  Is there
any chance that this code will be contributed back?

   Probably not, but I'd love it if you would take a look at it -- the
   times I've talked about to GDB guys hasn't been encouraging.  How can we
   work to get the bits in /usr/src/gnu/usr.bin/binutils/gdb made part of
   stock FSF GDB (along with our diffs from the FSF vendor branch in
   /usr/src/contrib/gdb)?

I've been snatching idea's from those places and incorporated them in
the FSF sources already.  For larger chunks of code the status of its
copyright cleared up.  Most of the code is definetly up to the
standards, and could be integrated without major changes.  I can do
that.

This would involve a copyright assignment, which could prove to be a
major obstacle.

   We (I) can work to address this issue.

Thanks.

A2 I'm volunteering to help out here.  As the i386 target maintainer
   and FreeBSD host/native maintainer, I seem to have sufficient
   background in GDB I guess ;-).  For almost two years now, I've been
   using FreeBSD/i386 as my primary (development) platform, and I hope
   at least some people have noticed that the upstream GDB works much
   better on FreeBSD/i386 and FreeBSD/Alpha now.  Now that I've got it
   working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot.

   Others may hate me for this, but getting stock GDB working on sparc64 is
   of higher priority as it is a Tier-1 platform and we have more sparc64
   users than ia64.  Or maybe, you can help back me on the gdb-patches
   mailing list and I can revive Jake's and my patches for sparc64.

I'll try to do that.  As I said above, I've already been doing some
work, and I think I've most of the FreeBSD-specific code fleshed out
now (sharing things common with NetBSD).  But if you find anything missing after I 
check things in, I'll try to back you, and approve patches myself if necessary.

   releases, I'm dedicated to FreeBSD, and I'm certainly willing to do
   work on integrating new versions of GDB into the FreeBSD tree.

   I'm more than willing to mentor you what it takes to do a GDB import into
   FreeBSD.

Thanks!

Mark
___
[EMAIL PROTECTED] mailing list

Re: GDB - do we dare?

[Mark Kettenis]

   Date: Sat, 12 Jul 2003 13:39:30 -0700
   From: Marcel Moolenaar [EMAIL PROTECTED]

   On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote:

   o  We still have the Alpha gdb -k bug moved over from the 5.1 todo
  list to the 5.2 todo list. I think this is just a bug fix.

I'm not really familliar with the support for debugging FreeBSD
kernels in GDB since that support is not in the FSF tree.  Is there
any chance that this code will be contributed back?  This would
involve a copyright assignment, which could prove to be a major
obstacle.

   The copyright of our kgdb support is already the FSF. See
   /usr/src/gnu/usr.bin/binutils/gdb/kvm-fbsd.c

I'll have to find out whether the paperwork is actually there.

The current support for debuggung libc_r-based threading is also not
present in the FSF tree.  So the question raised above applies here too.

   It looks to me that it can be contributed back.

That would be great.

I'm not really familiar with KSE, but AFAIK the kernel interfaces for
debugging KSE's aren't there yet.

   I think that's mostly due to a knowledge gap. We just need people who
   can bridge between gdb and FreeBSD. Someone like you :-)

   o  gdb(1) has created a 6.x branch, so it's likely that a new release
  is in the pipeline (within 6 months?). Upgrading to 5.3 may make
  a future upgrade easier due to smaller diffs and refreshed know-how.

GDB 6.0 will defenitely be released before the end of the year :-).
We're aiming at the end of August, but it will probably be somewhere
in September.

   Interesting. It may even be possible to make gdb 6.0 part of FreeBSD 5.2
   scheduling wise. Do we need a binutils update? We now have 2.13.2.

Probably, yes.  FSF GDB releases use a libbfd that's basically a
snapshot taken at the point where the release branch was cut.  You
folks seem to try to get away with using libbfd from binutils.  This
usually works as long as the GDB and binutils releases used are not
too far apart, so it's more likely that this works if binutils is
updated.

Actually, I think you'll need binutils 2.14 anyway for TLS.

A1 If having support for amd64 is a major reason for doing a new
   import of GDB, importing the upcoming GDB 6.0 would make more sense
   to me.

   No ia64 is the major reason :-)

Hmm.  I think I just crashed pluto1 trying to get it to run the GDB
testsuite on a not-yet-fully-functional GDB port.  Currently RSE is
giving me some headaches.

A2 I'm volunteering to help out here.

   Cool, thanks. Shall we just create a p4 branch and start hacking?

Oh dear, do I need to learn another version control system?

Anyway, this can probably wait.  I'll be on vacation from next tuesday
until August 10, and I still have to do some work on the upstream GDB
sources before I can start thinking about integrating things in the
FreeBSD source tree.  The GDB sparc target has suffered some bit rot,
up to the point where it is hardly usable.

   better on FreeBSD/i386 and FreeBSD/Alpha now.  Now that I've got it
   working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot.

   We probably need to talk then, because the ptrace interface needs
   to be fleshed out and I planned to do that while porting gdb.

Probably.  The current layout of `struct reg' and `struct fpreg' is a
bit ... messy.

Mark
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GDB - do we dare?

[Marcel Moolenaar]

On Sun, Jul 13, 2003 at 05:57:34PM +0200, Mark Kettenis wrote:
 
 A1 If having support for amd64 is a major reason for doing a new
import of GDB, importing the upcoming GDB 6.0 would make more sense
to me.
 
No ia64 is the major reason :-)
 
 Hmm.  I think I just crashed pluto1 trying to get it to run the GDB
 testsuite on a not-yet-fully-functional GDB port.  Currently RSE is
 giving me some headaches.

Yeah, this is known (both the crashes and the headache :-) I was
working on that (the crashes), but now need to make ia64 functional
again. The gcc import left us dead in the water. Our crt1.c is
broken.

 A2 I'm volunteering to help out here.
 
Cool, thanks. Shall we just create a p4 branch and start hacking?
 
 Oh dear, do I need to learn another version control system?

Yes, preferrably. Using a p4 branch allows us to track the gdb 6
branch while we prepare for the import. It's a convenient place
for people to grab the WIP.

better on FreeBSD/i386 and FreeBSD/Alpha now.  Now that I've got it
working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot.
 
We probably need to talk then, because the ptrace interface needs
to be fleshed out and I planned to do that while porting gdb.
 
 Probably.  The current layout of `struct reg' and `struct fpreg' is a
 bit ... messy.

It is not. It is actually pretty neat. Incomplete maybe, but neat.

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GDB - do we dare?

[Mark Linimon]

 FSF GDB releases use a libbfd that's basically a
 snapshot taken at the point where the release branch was cut.

Hmm, seems like a motivation for a libbfd port that tracks the
snapshot, for this very reason.

mcl

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GDB - do we dare?

[David O'Brien]

On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote:
Date: Fri, 11 Jul 2003 15:50:02 -0700
From: Marcel Moolenaar [EMAIL PROTECTED]
 
Gang,
 
With the gcc(1) dust not even settled yet, I like to get some feedback
on gdb(1). AFAICT, this is the deal:
 
o  Both ia64 and amd64 need gdb(1) support before they can become a
   tier 1 platform. I think this implies upgrading to 5.3 the least.
 
 Upgrading to 5.3 for amd64 won't really help.  While 5.3 included
 support for amd64, I'm told it is seriously broken.  Since then, I've
 almost completely reworked GDB's amd64 target, to bring it in line
 with the i386 target, and adapt it to some major architectural changes
 in GDB.  Based on that work, I've finished a FreeBSD/amd64 port
 yesterday.  I'll try to get it on GDB's 6.0 release branch.  However,
 backporting it to 5.3 would be a major PITA and IMHO a tremendous
 waste of effort.

Not sure about that.  I wish you would touch base with SuSE.  AMD has had
SuSE do quite a lot of work to make GDB 5.3 very usable on AMD64.  I know
there are parts of the work SuSE has yet to send to the GDB lists.  I am
worried that FreeBSD's AMD64 bits will be too different from the Linux
ones and FreeBSD won't be able to leverage the work AMD is paying SuSE to
do.

That said, giving the amount of work it takes to import a GDB
release(snapshot) and get it working in our tree -- we really should
import a 6.0 snapshot.

However, FreeBSD/sparc64 isn't properly supported in FSF GDB either.
When Jason Thorpe added NetBSD/sparc64 support he did it very NetBSD
specific rather than do it in a more general BSD/sparc64 way that all the
BSD's could leverage.  Generalizing his bits is needed in the FSF GDB
bits.


 I'm not really familliar with the support for debugging FreeBSD
 kernels in GDB since that support is not in the FSF tree.  Is there
 any chance that this code will be contributed back?

Probably not, but I'd love it if you would take a look at it -- the
times I've talked about to GDB guys hasn't been encouraging.  How can we
work to get the bits in /usr/src/gnu/usr.bin/binutils/gdb made part of
stock FSF GDB (along with our diffs from the FSF vendor branch in
/usr/src/contrib/gdb)?


 This would involve a copyright assignment, which could prove to be a
 major obstacle.

We (I) can work to address this issue.

 A2 I'm volunteering to help out here.  As the i386 target maintainer
and FreeBSD host/native maintainer, I seem to have sufficient
background in GDB I guess ;-).  For almost two years now, I've been
using FreeBSD/i386 as my primary (development) platform, and I hope
at least some people have noticed that the upstream GDB works much
better on FreeBSD/i386 and FreeBSD/Alpha now.  Now that I've got it
working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot.

Others may hate me for this, but getting stock GDB working on sparc64 is
of higher priority as it is a Tier-1 platform and we have more sparc64
users than ia64.  Or maybe, you can help back me on the gdb-patches
mailing list and I can revive Jake's and my patches for sparc64.

releases, I'm dedicated to FreeBSD, and I'm certainly willing to do
work on integrating new versions of GDB into the FreeBSD tree.

I'm more than willing to mentor you what it takes to do a GDB import into
FreeBSD.

Enjoy!
-- 
-- David  ([EMAIL PROTECTED])
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GDB - do we dare?

[David O'Brien]

On Sun, Jul 13, 2003 at 05:57:34PM +0200, Mark Kettenis wrote:
Date: Sat, 12 Jul 2003 13:39:30 -0700
From: Marcel Moolenaar [EMAIL PROTECTED]
 
On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote:
 
o  We still have the Alpha gdb -k bug moved over from the 5.1 todo
   list to the 5.2 todo list. I think this is just a bug fix.
 
 I'm not really familliar with the support for debugging FreeBSD
 kernels in GDB since that support is not in the FSF tree.  Is there
 any chance that this code will be contributed back?  This would
 involve a copyright assignment, which could prove to be a major
 obstacle.
 
The copyright of our kgdb support is already the FSF. See
/usr/src/gnu/usr.bin/binutils/gdb/kvm-fbsd.c
 
 I'll have to find out whether the paperwork is actually there.

As you know I do have paperwork on file, which covers some of the work.
The bigger question is will the fuctionality get resistance to being part
of the FSF GDB?  Can you evaluate the FreeBSD additions from that point
of view?


  Interesting. It may even be possible to make gdb 6.0 part of FreeBSD 5.2
  scheduling wise. Do we need a binutils update? We now have 2.13.2.

Please, don't even worry about that.  You'll get lost in a non-issue.
The real issue is getting a patch that would update our bits to
GDB 6.0 -- not the actual integration.

-- 
-- David  ([EMAIL PROTECTED])
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GDB - do we dare?

[David O'Brien]

On Sun, Jul 13, 2003 at 02:28:08PM -0500, Mark Linimon wrote:
  FSF GDB releases use a libbfd that's basically a
  snapshot taken at the point where the release branch was cut.
 
 Hmm, seems like a motivation for a libbfd port that tracks the
 snapshot, for this very reason.

NO!
 
-- 
-- David  ([EMAIL PROTECTED])
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GDB - do we dare?

[Terry Lambert]

Marcel Moolenaar wrote:
 I'd say: upgrade gdb(1) and add support for ia64 and amd64, as well
 as make sure we fix any known showstopper bugs we know of.
[ ... ]
 Thoughts?

Will remote source level kernel debugging continue to work?

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GDB - do we dare?

[Mark Kettenis]

   Date: Fri, 11 Jul 2003 15:50:02 -0700
   From: Marcel Moolenaar [EMAIL PROTECTED]

   Gang,

   With the gcc(1) dust not even settled yet, I like to get some feedback
   on gdb(1). AFAICT, this is the deal:

   o  Both ia64 and amd64 need gdb(1) support before they can become a
  tier 1 platform. I think this implies upgrading to 5.3 the least.

Upgrading to 5.3 for amd64 won't really help.  While 5.3 included
support for amd64, I'm told it is seriously broken.  Since then, I've
almost completely reworked GDB's amd64 target, to bring it in line
with the i386 target, and adapt it to some major architectural changes
in GDB.  Based on that work, I've finished a FreeBSD/amd64 port
yesterday.  I'll try to get it on GDB's 6.0 release branch.  However,
backporting it to 5.3 would be a major PITA and IMHO a tremendous
waste of effort.

   o  We still have the Alpha gdb -k bug moved over from the 5.1 todo
  list to the 5.2 todo list. I think this is just a bug fix.

I'm not really familliar with the support for debugging FreeBSD
kernels in GDB since that support is not in the FSF tree.  Is there
any chance that this code will be contributed back?  This would
involve a copyright assignment, which could prove to be a major
obstacle.

   o  With libkse and libthr in the tree, we probably want to keep close
  to the latest gdb(1) development to benefit from the threading
  work that's likely to be done and also make sure we add whatever we
  need to support our threading models.

The current support for debuggung libc_r-based threading is also not
present in the FSF tree.  So the question raised above applies here too.

Note that there isn't much development on thread-related GDB stuff.
The Linux folks are still chasing bugs, mainly because there are no
sane kernel interfaces for debugging threads and the kernel interfaces
keep changing.  I'm confident we can avoid that mess on FreeBSD ;-).

I'm not really familiar with KSE, but AFAIK the kernel interfaces for
debugging KSE's aren't there yet.

   o  The new gcc(1) also adds support for TLS, which, if time is with
  us may be supported by both libkse and libthr before R5.2 and may
  need some gdb(1) support as well. I don't know, but if it does,
  we probably want to add that to gdb 5.3 or later.

It's already working on Linux, so it should be easy to add support for
TLS for other platforms.

   o  gdb(1) has created a 6.x branch, so it's likely that a new release
  is in the pipeline (within 6 months?). Upgrading to 5.3 may make
  a future upgrade easier due to smaller diffs and refreshed know-how.

GDB 6.0 will defenitely be released before the end of the year :-).
We're aiming at the end of August, but it will probably be somewhere
in September.

I think the diffs between 5.2 and 5.3 are negligible compared to the
the diffs between 5.3 and 6.0, at least for i386/amd64 and Alpha.

   I'd say: upgrade gdb(1) and add support for ia64 and amd64, as well
   as make sure we fix any known showstopper bugs we know of.

   Q1 How does that sound in general?
   Q2 Do we have people with sufficient background and motivation who
  want to volunteer to make this happen?

   Since the answer to Q2 is likely no or indetermined, I would like
   to emphasize that I do not expect this to be a one-man show. We
   really need to treat this as a project.

   Thoughts?

A1 If having support for amd64 is a major reason for doing a new
   import of GDB, importing the upcoming GDB 6.0 would make more sense
   to me.

A2 I'm volunteering to help out here.  As the i386 target maintainer
   and FreeBSD host/native maintainer, I seem to have sufficient
   background in GDB I guess ;-).  For almost two years now, I've been
   using FreeBSD/i386 as my primary (development) platform, and I hope
   at least some people have noticed that the upstream GDB works much
   better on FreeBSD/i386 and FreeBSD/Alpha now.  Now that I've got it
   working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot.  Although
   my primary development will be focussed on the upstream FSF GDB
   releases, I'm dedicated to FreeBSD, and I'm certainly willing to do
   work on integrating new versions of GDB into the FreeBSD tree.

Mark
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GDB - do we dare?

[Marcel Moolenaar]

On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote:
 
o  We still have the Alpha gdb -k bug moved over from the 5.1 todo
   list to the 5.2 todo list. I think this is just a bug fix.
 
 I'm not really familliar with the support for debugging FreeBSD
 kernels in GDB since that support is not in the FSF tree.  Is there
 any chance that this code will be contributed back?  This would
 involve a copyright assignment, which could prove to be a major
 obstacle.

The copyright of our kgdb support is already the FSF. See
/usr/src/gnu/usr.bin/binutils/gdb/kvm-fbsd.c

 The current support for debuggung libc_r-based threading is also not
 present in the FSF tree.  So the question raised above applies here too.

It looks to me that it can be contributed back.

 I'm not really familiar with KSE, but AFAIK the kernel interfaces for
 debugging KSE's aren't there yet.

I think that's mostly due to a knowledge gap. We just need people who
can bridge between gdb and FreeBSD. Someone like you :-)

o  gdb(1) has created a 6.x branch, so it's likely that a new release
   is in the pipeline (within 6 months?). Upgrading to 5.3 may make
   a future upgrade easier due to smaller diffs and refreshed know-how.
 
 GDB 6.0 will defenitely be released before the end of the year :-).
 We're aiming at the end of August, but it will probably be somewhere
 in September.

Interesting. It may even be possible to make gdb 6.0 part of FreeBSD 5.2
scheduling wise. Do we need a binutils update? We now have 2.13.2.

 A1 If having support for amd64 is a major reason for doing a new
import of GDB, importing the upcoming GDB 6.0 would make more sense
to me.

No ia64 is the major reason :-)

 A2 I'm volunteering to help out here.

Cool, thanks. Shall we just create a p4 branch and start hacking?

better on FreeBSD/i386 and FreeBSD/Alpha now.  Now that I've got it
working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot.

We probably need to talk then, because the ptrace interface needs
to be fleshed out and I planned to do that while porting gdb.

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GDB kernel debug new command

[Jun Su]

On Monday 10 March 2003 17:28, Dag-Erling Smorgrav wrote:
 Jun Su [EMAIL PROTECTED] writes:
  To help myself more easily check the kernel dump, I added two new
  command. One is ps, the other is kldstat. I know we can print the kernel
  data manually to get the same information. I still think this is useful.
  This can help the newbies to get the information without many knowledge
  about the kernel. This also can help the experienced user to get the data
  more quickly.
 
  Here is the new file. Just put it in /usr/src/gnu/usr.bin/binutils/gdb.
  And add the file to Makefile. Please give me some comments if this is
  garbage. :)

 This is pointless as it won't work unless gdb is in synch with the
 kernel (since it depends on knowing the layout of struct proc and
 struct linker_file).  Both of these commands can be implemented as
 macros, which will not depend on gdb being in synch with the kernel.

 Greg Lehey wrote this ps macro:

 define ps
 set $nproc = nprocs
 set $aproc = allproc.lh_first
 set $proc = allproc.lh_first
 printf   pidprocaddr   uid  ppid  pgrp   flag stat comm   
  wchan\n while (--$nproc = 0)
 set $pptr = $proc.p_pptr
 if ($pptr == 0)
set $pptr = $proc
 end
 if ($proc.p_stat)
 printf %5d %08x %08x %4d %5d %5d  %06x  %d  %-10s   , \
$proc.p_pid, $aproc, \
$proc.p_addr, $proc.p_cred-p_ruid, $pptr-p_pid, \
$proc.p_pgrp-pg_id, $proc.p_flag, $proc.p_stat, \
$proc.p_comm[0]
 if ($proc.p_wchan)
 if ($proc.p_wmesg)
 printf %s , $proc.p_wmesg
 end
 printf %x, $proc.p_wchan
 end
 printf \n
 end
 set $aproc = $proc.p_list.le_next
 if ($aproc == 0  $nproc  0)
 set $aproc = zombproc
 end
 set $proc = $aproc
 end
 end

 document ps
 ps -- when kernel debugging, type out a ps-like listing of active
 processes. end

 and I've written two variants of kldstat myself, plus a kldload:

 end

 document kldstat
   Lists the modules that were loaded when the kernel crashed.
 end

 define kldstat-v
   set $kld = linker_files.tqh_first
   printf Id Refs AddressSize Name\n
   while ($kld != 0)
 printf %2d %4d 0x%08x %-8x %s\n, \
   $kld-id, $kld-refs, $kld-address, $kld-size, $kld-filename
 printf Contains modules:\n
 printf Id Name\n
 set $module = $kld-modules.tqh_first
 while ($module != 0)
   printf %2d %s\n, $module-id, $module-name
   set $module = $module-link.tqe_next
 end
 set $kld = $kld-link.tqe_next
   end
 end

 document kldstat-v
   Lists modules with full information.
 end

 define kldload
   set $kld = linker_files.tqh_first
   set $done = 0
   while ($kld != 0  $done == 0)
 if ($kld-filename == $arg0)
   set $done = 1
 else
   set $kld = $kld-link.tqe_next
 end
   end
   if ($done == 1)
 shell /usr/bin/objdump -h $arg0 | \
   awk '/ .text/ { print set \$offset = 0x $6 }'  .kgdb.temp
 source .kgdb.temp
 add-symbol-file $arg0 $kld-address + $offset
   end
 end

 document kldload
   Loads a module. Arguments are module name and offset of text section.
 end

 Note that for kldload to work, you need to know the offset of the text
 section for the module you wish to load (objdump -h will tell you)

 Note also that I haven't used any of these macros in a long time, so
 there may be some issues related to KSE or whatnot.

 DES

You are so cool. Your macro is better than my code. Thanks.

I think the kernel structure is not changed often. These type of macro can 
help most newbies such as me to enter the freebsd debug easily. It is worth 
to maintain a copy somewhere. (In source tree, it may be great.) I used 
windbg for a long time. it provides many commands to help developer debug. 
This is a good pratice I think. :)

Jun Su


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GDB kernel debug new command

[Dag-Erling Smorgrav]

Jun Su [EMAIL PROTECTED] writes:
 To help myself more easily check the kernel dump, I added two new command. One 
 is ps, the other is kldstat. I know we can print the kernel data manually to 
 get the same information. I still think this is useful. This can help the 
 newbies to get the information without many knowledge about the kernel. This 
 also can help the experienced user to get the data more quickly. 

 Here is the new file. Just put it in /usr/src/gnu/usr.bin/binutils/gdb. And 
 add the file to Makefile. Please give me some comments if this is garbage. :)

This is pointless as it won't work unless gdb is in synch with the
kernel (since it depends on knowing the layout of struct proc and
struct linker_file).  Both of these commands can be implemented as
macros, which will not depend on gdb being in synch with the kernel.

Greg Lehey wrote this ps macro:

define ps
set $nproc = nprocs
set $aproc = allproc.lh_first
set $proc = allproc.lh_first
printf   pidprocaddr   uid  ppid  pgrp   flag stat comm wchan\n
while (--$nproc = 0)
set $pptr = $proc.p_pptr
if ($pptr == 0)
   set $pptr = $proc
end
if ($proc.p_stat)
printf %5d %08x %08x %4d %5d %5d  %06x  %d  %-10s   , \
   $proc.p_pid, $aproc, \
   $proc.p_addr, $proc.p_cred-p_ruid, $pptr-p_pid, \
   $proc.p_pgrp-pg_id, $proc.p_flag, $proc.p_stat, \
   $proc.p_comm[0]
if ($proc.p_wchan)
if ($proc.p_wmesg)
printf %s , $proc.p_wmesg
end
printf %x, $proc.p_wchan
end
printf \n
end
set $aproc = $proc.p_list.le_next
if ($aproc == 0  $nproc  0)
set $aproc = zombproc
end
set $proc = $aproc
end
end

document ps
ps -- when kernel debugging, type out a ps-like listing of active processes.
end

and I've written two variants of kldstat myself, plus a kldload:

end

document kldstat
  Lists the modules that were loaded when the kernel crashed.
end

define kldstat-v
  set $kld = linker_files.tqh_first
  printf Id Refs AddressSize Name\n
  while ($kld != 0)
printf %2d %4d 0x%08x %-8x %s\n, \
  $kld-id, $kld-refs, $kld-address, $kld-size, $kld-filename
printf Contains modules:\n
printf Id Name\n
set $module = $kld-modules.tqh_first
while ($module != 0)
  printf %2d %s\n, $module-id, $module-name
  set $module = $module-link.tqe_next
end
set $kld = $kld-link.tqe_next
  end
end

document kldstat-v
  Lists modules with full information.
end

define kldload
  set $kld = linker_files.tqh_first
  set $done = 0
  while ($kld != 0  $done == 0)
if ($kld-filename == $arg0)
  set $done = 1
else
  set $kld = $kld-link.tqe_next
end
  end
  if ($done == 1)
shell /usr/bin/objdump -h $arg0 | \
  awk '/ .text/ { print set \$offset = 0x $6 }'  .kgdb.temp
source .kgdb.temp
add-symbol-file $arg0 $kld-address + $offset
  end
end

document kldload
  Loads a module. Arguments are module name and offset of text section.
end

Note that for kldload to work, you need to know the offset of the text
section for the module you wish to load (objdump -h will tell you)

Note also that I haven't used any of these macros in a long time, so
there may be some issues related to KSE or whatnot.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb: failed to set signal flags properly for ast()

[phk]

In message [EMAIL PROTECTED], Robe
rt Watson writes:

While debugging the recent pthreads problem, I've started running into
this:

pid 663 (test), uid 1000: exited on signal 10 (core dumped)
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()

I can't remember how I triggered this, but I have personally
run with this patch for some time:

(NB: CutPaste)

Index: kern/subr_trap.c
===
RCS file: /home/ncvs/src/sys/kern/subr_trap.c,v
retrieving revision 1.239
diff -u -r1.239 subr_trap.c
--- kern/subr_trap.c28 Dec 2002 01:23:07 -  1.239
+++ kern/subr_trap.c28 Dec 2002 09:05:22 -
@@ -74,6 +74,7 @@
 {
struct proc *p = td-td_proc;
struct kse *ke = td-td_kse; 
+   static int enough;
 
CTR3(KTR_SYSC, userret: thread %p (pid %d, %s), td, p-p_pid,
 p-p_comm);
@@ -84,7 +85,8 @@
mtx_lock_spin(sched_lock);
if (SIGPENDING(p)  ((p-p_sflag  PS_NEEDSIGCHK) == 0 ||
(td-td_kse-ke_flags  KEF_ASTPENDING) == 0))
-   printf(failed to set signal flags properly for ast()\n);
+   if (++enough  10)
+   printf(failed to set signal flags properly for ast()\n);
mtx_unlock_spin(sched_lock);
PROC_UNLOCK(p);
mtx_unlock(Giant);
-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GDB auto enter/detach patch

[Archie Cobbs]

Nate Lawson writes:
 I've put together a patch that enables a kernel on the target machine to
 detect a GDB packet and automatically enter GDB mode.  When the debugger
 detaches, it also continues execution.  This speeds up debugging,
 especially when the target is in a remote location.  The patch plus more
 explanation is at:
 
http://www.root.org/~nate/freebsd/

Neat. A couple of comments:

1. I think a better abstraction of the GDB packet protocol would
   be something like this:

 struct gdb_parse {
int state;  /* opaque state value */
u_int   len;/* current packet length */
u_int   maxlen; /* maximum packet length */
u_char  data[0];/* packet data */
 };

 extern void gdb_parse_init(struct gdb_parse *p);
 extern int  gdb_parse_byte(struct gdb_parse *p);

   That is, if you're doing the state machine, why not go ahead
   and decode the packet data as well?

2. You need to handle the escape mechanism for packets containing
   raw data.: '$', '#', and '~' are escaped with '~' characters
   in case the the 'X' command is used.

3. I think GDB_AUTO_DETACH should be mandatory, i.e., the current
   state of affairs is a bug IMHO.

4. Does FreeBSD use the 'O' command to send ordinary serial port output
   when GDB mode is active? Haven't looked but this would be nice to
   have if it's not already there.

5. Receipt of a '$' character should always reset the state, no?
   (modulo the '~' escape mechanism mentioned above).

-Archie

__
Archie Cobbs * Packet Design * http://www.packetdesign.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GDB auto enter/detach patch

[Nate Lawson]

On Tue, 5 Nov 2002, Archie Cobbs wrote:
 Nate Lawson writes:
  I've put together a patch that enables a kernel on the target machine to
  detect a GDB packet and automatically enter GDB mode.  When the debugger
  detaches, it also continues execution.  This speeds up debugging,
  especially when the target is in a remote location.  The patch plus more
  explanation is at:
  
 http://www.root.org/~nate/freebsd/
 
 Neat. A couple of comments:
 
 1. I think a better abstraction of the GDB packet protocol would
be something like this:
 
  struct gdb_parse {
   int state;  /* opaque state value */
   u_int   len;/* current packet length */
   u_int   maxlen; /* maximum packet length */
   u_char  data[0];/* packet data */
  };
 
  extern void gdb_parse_init(struct gdb_parse *p);
  extern int  gdb_parse_byte(struct gdb_parse *p);
 
That is, if you're doing the state machine, why not go ahead
and decode the packet data as well?

The first version of the patch collected the data in a small static buffer
with the idea that I'd send the command to the gdb stub once it was
assembled.  However, gdb on attach retries multiple times with different
commands before giving up so I just discard the first complete gdb frame
and let the retries hit gdb once I call breakpoint()
 
 2. You need to handle the escape mechanism for packets containing
raw data.: '$', '#', and '~' are escaped with '~' characters
in case the the 'X' command is used.

Escapes should be added but I haven't done that yet because all the
commands currently used to attach to the stub don't need them.

 3. I think GDB_AUTO_DETACH should be mandatory, i.e., the current
state of affairs is a bug IMHO.

I've always wondered why that wasn't the case.  I'd also like to catch the
$k command (kill) which is sent on typing quit into gdb while still
attached and do something useful.  Should that also restart the kernel
like an explicit detach?

 4. Does FreeBSD use the 'O' command to send ordinary serial port output
when GDB mode is active? Haven't looked but this would be nice to
have if it's not already there.

No, it uses gdb remote chat which prefixes commands with 

 5. Receipt of a '$' character should always reset the state, no?
(modulo the '~' escape mechanism mentioned above).

Yeah, I should add this.  Basically the state machine is a little lax at
the moment and it's possible (although unlikely) that data transferred
over the serial port could trigger a breakpoint().  It matches
 $ + up to 12 chars + # + [0-F] + [0-F]

If you're worried about this, just use the sysctl to turn off
debug.gdb_auto_enter while transferring binary data over the gdb port.  
Even when I implement stricter protocol matching, relying on inband
signalling is inherently unreliable.  If you need to debug a serial port
driver, you can use a 2nd serial port.

-Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb errors in world

[Mike Barcroft]

Erik Greenwald [EMAIL PROTECTED] writes:
 This may be a stupid question, but is gdbreplay currently broken? I just
 cvsup'd today (2002-07-08, 18:42 CST (GMT-6))

Yes (unless I missed the fix).  Just use NO_WERROR=true for now.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb errors in world

[David O'Brien]

On Mon, Jul 08, 2002 at 08:37:37PM -0500, Erik Greenwald wrote:
 
 This may be a stupid question, but is gdbreplay currently broken? I just
 cvsup'd today (2002-07-08, 18:42 CST (GMT-6))

*shrug*  I can't reproduce this.
 
 cc -O -pipe  -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/gdbreplay
...
 -DNO_MMALLOC   -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes
 ^^^

 /usr/src/contrib/gdb/gdb/gdbserver/gdbreplay.c:278: warning: implicit
 declaration of function `write'
 *** Error code 1

It isn't broken, rather it isn't WARNS/WFORMAT clean for you.  I'm not
sure why it is for me.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Jun Kuriyama]

At Mon, 27 May 2002 02:46:01 + (UTC),
David O'Brien wrote:
 Add it to COPTFLAGS.  Why are you adding it to DEBUG?
 ``grep DEBUG /sys/conf/*.mk /sys/conf/Makefile.*'' shows DEBUG is not
 used this way.

I added it to DEBUG because I think -gstabs+ will be used as
replacement of -g.  I added it to COPTFLAGS and tried again, but no
luck.

makeoptions COPTFLAGS=-gstabs+  #Build kernel with gdb(1) debug symbols

(gdb) core-file /var/crash/vmcore.6
/var/crash/vmcore.6 is not a core dump: File format not recognized

Sorry for my silly questions...


-- 
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[David O'Brien]

On Mon, May 27, 2002 at 04:08:44PM +0900, Jun Kuriyama wrote:
 At Mon, 27 May 2002 02:46:01 + (UTC),
 David O'Brien wrote:
  Add it to COPTFLAGS.  Why are you adding it to DEBUG?
  ``grep DEBUG /sys/conf/*.mk /sys/conf/Makefile.*'' shows DEBUG is not
  used this way.
 
 I added it to DEBUG because I think -gstabs+ will be used as
 replacement of -g.  I added it to COPTFLAGS and tried again, but no
 luck.
 
 makeoptions COPTFLAGS=-gstabs+  #Build kernel with gdb(1) debug symbols


Verify that your entire kernel is built with -g -gstabs+.  If you still
cannot use gdb on a core dump, maybe there is a core dump format change
GDB needs to catch up with.  Please use the various objdump, etc. tools
to verify what type of debugging is in kernel.debug.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Mark Peek]

At 10:54 AM -0700 5/27/02, David O'Brien wrote:
Verify that your entire kernel is built with -g -gstabs+.  If you still
cannot use gdb on a core dump, maybe there is a core dump format change
GDB needs to catch up with.  Please use the various objdump, etc. tools
to verify what type of debugging is in kernel.debug.

I merged some of the gdb src/ code into the devel/gdb52 port to allow 
it to debug i386 kernels (without the -gstabs+ compile option). The 
replacement port can be found here:

   http://people.FreeBSD.org/~mp/gdb52.tar.gz


I'd appreciate feedback prior to committing it.

Thanks,
Mark

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Jun Kuriyama]

At Wed, 22 May 2002 18:54:02 + (UTC),
David O'Brien wrote:
 -ggdb means to use the most expressive debugging format the compiler
 knows about.  You want -gstabs+ or -gstabs

I cannot debug a kernel with -gstabs+ option.  Any hints about this?

% cd sys/i386/compile/WATERBLUE
% grep gdb ../../conf/WATERBLUE
makeoptions DEBUG=-gstabs+  #Build kernel with gdb(1) debug symbols
% sudo gdb52
(gdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(gdb) exec-file kernel
(gdb) core-file /var/crash/vmcore.4
/var/crash/vmcore.4 is not a core dump: File format not recognized


-- 
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[David W. Chapman Jr.]

On Mon, May 27, 2002 at 11:12:47AM +0900, Jun Kuriyama wrote:
 At Wed, 22 May 2002 18:54:02 + (UTC),
 David O'Brien wrote:
  -ggdb means to use the most expressive debugging format the compiler
  knows about.  You want -gstabs+ or -gstabs
 
 I cannot debug a kernel with -gstabs+ option.  Any hints about this?
 
 % cd sys/i386/compile/WATERBLUE
 % grep gdb ../../conf/WATERBLUE
 makeoptions DEBUG=-gstabs+  #Build kernel with gdb(1) debug symbols
 % sudo gdb52
 (gdb) symbol-file kernel.debug
 Reading symbols from kernel.debug...done.
 (gdb) exec-file kernel
 (gdb) core-file /var/crash/vmcore.4
 /var/crash/vmcore.4 is not a core dump: File format not recognized
 
Last time I checked, gdb was broken in -current and people were 
encouraged to use gdb in the ports system, but this may be oudated.

-- 
David W. Chapman Jr.
[EMAIL PROTECTED]   Raintree Network Services, Inc. www.inethouston.net
[EMAIL PROTECTED]   FreeBSD Committer www.FreeBSD.org

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Jun Kuriyama]

At Sun, 26 May 2002 21:35:28 -0500,
David W. Chapman Jr. [EMAIL PROTECTED] wrote:
  % sudo gdb52

 Last time I checked, gdb was broken in -current and people were 
 encouraged to use gdb in the ports system, but this may be oudated.

Yes, I'm using gdb52 from ports/devel/gdb52.


-- 
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[David O'Brien]

On Mon, May 27, 2002 at 11:12:47AM +0900, Jun Kuriyama wrote:
 At Wed, 22 May 2002 18:54:02 + (UTC),
 David O'Brien wrote:
  -ggdb means to use the most expressive debugging format the compiler
  knows about.  You want -gstabs+ or -gstabs
 
 I cannot debug a kernel with -gstabs+ option.  Any hints about this?
 
 % cd sys/i386/compile/WATERBLUE
 % grep gdb ../../conf/WATERBLUE
 makeoptions DEBUG=-gstabs+  #Build kernel with gdb(1) debug symbols

Add it to COPTFLAGS.  Why are you adding it to DEBUG?
``grep DEBUG /sys/conf/*.mk /sys/conf/Makefile.*'' shows DEBUG is not
used this way.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Doug Rabson]

On Monday 20 May 2002 3:49 am, Terry Lambert wrote:
 Steve Kargl wrote:
   Use -ggdb instead, thus avoiding DWARF.
 
  BZZZT...  Thanks for play!

 Did Mark Peek's suggestion of using the gdb that matched
 the compiler (gdb 5.2 from ports) work instead?

GDB 5.2 works pretty well with -current - I've been using it recently. I plan 
to upgrade GDB in -current to 5.2 soon (as soon as David has enough time to 
sort out the CVS magic).

-- 
Doug Rabson Mail:  [EMAIL PROTECTED]
Phone: +44 20 8348 6160


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[David O'Brien]

On Wed, May 22, 2002 at 09:57:24AM +0100, Doug Rabson wrote:
 GDB 5.2 works pretty well with -current - I've been using it recently. I plan 
 to upgrade GDB in -current to 5.2 soon (as soon as David has enough time to 
 sort out the CVS magic).

I fail to see your patches to gdb 5.2 for the kernel bits.
It would be nice to get them in the public view before they are
committed.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Doug Rabson]

On Wednesday 22 May 2002 6:49 pm, David O'Brien wrote:
 On Wed, May 22, 2002 at 09:57:24AM +0100, Doug Rabson wrote:
  GDB 5.2 works pretty well with -current - I've been using it recently. I
  plan to upgrade GDB in -current to 5.2 soon (as soon as David has enough
  time to sort out the CVS magic).

 I fail to see your patches to gdb 5.2 for the kernel bits.
 It would be nice to get them in the public view before they are
 committed.

I'll certainly put them up for review when I've written them. I've been busy 
on other things since we last spoke on the subject.

-- 
Doug Rabson Mail:  [EMAIL PROTECTED]
Phone: +44 20 8348 6160


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[David O'Brien]

On Wed, May 22, 2002 at 09:57:24AM +0100, Doug Rabson wrote:
 On Monday 20 May 2002 3:49 am, Terry Lambert wrote:
  Steve Kargl wrote:
Use -ggdb instead, thus avoiding DWARF.
  
   BZZZT...  Thanks for play!

-ggdb means to use the most expressive debugging format the compiler
knows about.  You want -gstabs+ or -gstabs

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[David O'Brien]

On Sat, May 18, 2002 at 08:12:15PM -0700, Steve Kargl wrote:
  Warnings are treated as errors.  Since GCC 3.1 has brought a hell of a
  lot more warnings with us, you should use -DNO_WERROR until the dust
  of the GCC 3.1 import settles down.
 
 If everyone is using  -DNO_WERROR, then who would report build
 problems :-).

Because we are wanting for people to let the dust settle on the switch to
GCC 3.1.  It is best for people to juse use -DNO_WERROR for now.
Patience.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Matthew Dillon]

:  lot more warnings with us, you should use -DNO_WERROR until the dust
:  of the GCC 3.1 import settles down.
: 
: If everyone is using  -DNO_WERROR, then who would report build
: problems :-).
:
:Because we are wanting for people to let the dust settle on the switch to
:GCC 3.1.  It is best for people to juse use -DNO_WERROR for now.
:Patience.
:

Ahhh.. so *that's* why everything broke when I did a full update.

You know, every time I update my -current sources it's winding up
taking me an entire day to get things to build again.  This is the third
time that's happened.  I have spent at least 5 hours building the world
and the kernel over and over again to try to produce a bootable system.
The annoyance factor is quite high.

It would be more considerate of comitters if they would adjust the
defaults for these things so at the very least one can buildworld or
buildkernel without having to do something special.  It may be best
for *you* not to spend the time, but look at the huge amount of other
people's time that is being wasted by these little snafus!  I do 
appreciate all the compiler tools work, I know it isn't easy.  I'm just
asking that a little more care be taken in regards to the other
developers trying to work with -current (which is more and more these
days).  Don't expose breakage to the whole development community on
purpose!

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Terry Lambert]

David O'Brien wrote:
   Warnings are treated as errors.  Since GCC 3.1 has brought a hell of a
   lot more warnings with us, you should use -DNO_WERROR until the dust
   of the GCC 3.1 import settles down.
 
  If everyone is using  -DNO_WERROR, then who would report build
  problems :-).
 
 Because we are wanting for people to let the dust settle on the switch to
 GCC 3.1.  It is best for people to juse use -DNO_WERROR for now.
 Patience.


Both Twins: Wonder Twin powers, Activate!
Jayna:  Take the form of ... patches!
Zan:Take the form of ... a complaining email!
Gleek the code monkey:  Gleek!  Gleek!  Gleek!

[ ... meanwhile, in the cartoon viewers' cave ... ]

Bob:That second Wonder Twin really has an incredibly
 lame power!
Tom:Pass the potato chips!

[ ... http://www.seanbaby.com/superfriends/wondertwins.htm ; hit the
  back circle for the rest of the Super Friends.  8-) ... ]


-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Steve Kargl]

On Sun, May 19, 2002 at 02:19:27PM -0700, Terry Lambert wrote:
 Both Twins:   Wonder Twin powers, Activate!

 Jayna:Take the form of ... patches!
 Zan:  Take the form of ... a complaining email!
 Gleek the code monkey:Gleek!  Gleek!  Gleek!
 

Terry, you are an idiot.  I wasn't complaining!  I hadn't
seen this particular failure mentioned on the list.  David
was probably aware of the problem, but in case he (and others)
hadn't seen the problem, I reported it in a short email with
the details.

If I were to complain, I'd choose the lack of functional
C++ libraries after the gcc 3.1 upgrade.  I, however,
recognize the difficult and thankless job that David has
with maintaining the compiler infrastructure.

Finally, since you're quick with the wit, can you tell me
how to debug the following problem when I can't compile
the debugger. 

kargl[223] cat a.c
#include stdlib.h
int main(void) {
   /* This isn't the problem.  The problem is with gdb. */
   abort();
}
kargl[224] !gcc
gcc -g a.c
kargl[225] gdb a.out
GNU gdb 4.18
Copyright 1998 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 i386-unknown-freebsd...

Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Mark Peek]

At 2:58 PM -0700 5/19/02, Steve Kargl wrote:
Finally, since you're quick with the wit, can you tell me
how to debug the following problem when I can't compile
the debugger.

kargl[223] cat a.c
#include stdlib.h
int main(void) {
/* This isn't the problem.  The problem is with gdb. */
abort();
}
kargl[224] !gcc
gcc -g a.c
kargl[225] gdb a.out
GNU gdb 4.18
Copyright 1998 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 i386-unknown-freebsd...

Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.


This appears to be due to the switch to gcc-3.1. A bug has been filed 
in gnats on this problem (bin/38236: gdb do not work with gcc-3.1).

For now, the workaround is to use the devel/gdb52 port.

Mark

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Giorgos Keramidas]

On 2002-05-19 13:31, Matthew Dillon wrote:
 David O'Brien wrote:
:
:Because we are wanting for people to let the dust settle on the switch to
:GCC 3.1.  It is best for people to juse use -DNO_WERROR for now.
:Patience.

 Ahhh.. so *that's* why everything broke when I did a full update.

 You know, every time I update my -current sources it's winding up
 taking me an entire day to get things to build again.

There are cases where updating with the `new files' requires that you
have updated to the `new files', aka chicken and egg problems.  This
is true with the -DNO_WERROR thing, in my opinion.  Let's not blame
David O'Brien for anything, since he's doing such a huge amount of
work already :/

After all, this is -CURRENT.
It's not even guaranteed to work at all times ;-)

- Giorgos


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Matthew Dillon]

: You know, every time I update my -current sources it's winding up
: taking me an entire day to get things to build again.
:
:There are cases where updating with the `new files' requires that you
:have updated to the `new files', aka chicken and egg problems.  This
:is true with the -DNO_WERROR thing, in my opinion.  Let's not blame
:David O'Brien for anything, since he's doing such a huge amount of
:work already :/
:
:After all, this is -CURRENT.
:It's not even guaranteed to work at all times ;-)
:
:- Giorgos

It's just that it gets frustrating.  If there were only one problem
with the build then, sure, no big deal.  But between the filesystem
import, compiler upgrade, and the warnings failures it has taken all
day for me just to get to the point where it is now dying on Greg's
doc commit.  And when we get past that problem will another hit us? 
I'll probably wind up having to build the world a dozen times before I
get something I can install.  Throw in ipfw changes and the fact that
procfs does not work with the old mount binary and it's taken
quite a bit of munging to just be able to build, install, and run a new
kernel, let alone the world.

I'm going to try make -k next but I don't have high hopes.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Giorgos Keramidas]

On 2002-05-19 17:00, Matthew Dillon wrote:
 
 : You know, every time I update my -current sources it's winding up
 : taking me an entire day to get things to build again.
 :
 :There are cases where updating with the `new files' requires that you
 :have updated to the `new files', aka chicken and egg problems.  This
 :is true with the -DNO_WERROR thing, in my opinion.  Let's not blame
 :David O'Brien for anything, since he's doing such a huge amount of
 :work already :/
 :
 :After all, this is -CURRENT.
 :It's not even guaranteed to work at all times ;-)
 :
 :- Giorgos
 
 It's just that it gets frustrating.  If there were only one problem
 with the build then, sure, no big deal.  But between the filesystem
 import, compiler upgrade, and the warnings failures it has taken all
 day for me just to get to the point where it is now dying on Greg's
 doc commit.  And when we get past that problem will another hit us? 
 I'll probably wind up having to build the world a dozen times before I
 get something I can install.

I know the feeling, I haven't been ablt to build world on this slow
machine of mine for ages.  This is why I'm still running on a 5.x
build of late April :-/

% uname -v
FreeBSD 5.0-CURRENT #1: Thu Apr 25 01:11:09 EEST 2002 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GALADRIEL

But whatever.  I can still test most of the work I'm doing, being
mostly interested in manpages and SGML docs.  You have a point though,
no objections from here.  CURRENT is approaching the -RELEASE of
November every day, and is still somewhat fragile for me ;)

-- 
Giorgos Keramidas- http://www.FreeBSD.org
[EMAIL PROTECTED] - The Power to Serve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Terry Lambert]

Steve Kargl wrote:
 Finally, since you're quick with the wit, can you tell me
 how to debug the following problem when I can't compile
 the debugger.

[ ... ]

 gcc -g a.c

[ ... ]

 Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.

Use -ggdb instead, thus avoiding DWARF.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Steve Kargl]

On Sun, May 19, 2002 at 05:50:32PM -0700, Terry Lambert wrote:
 
  Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.
 
 Use -ggdb instead, thus avoiding DWARF.
 

BZZZT...  Thanks for play!

kargl[204] gcc -ggdb a.c
kargl[205] gdb a.out
GNU gdb 4.18
Copyright 1998 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 i386-unknown-freebsd...

Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.

-- 
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Terry Lambert]

Steve Kargl wrote:
  Use -ggdb instead, thus avoiding DWARF.
 
 BZZZT...  Thanks for play!

Did Mark Peek's suggestion of using the gdb that matched
the compiler (gdb 5.2 from ports) work instead?

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Giorgos Keramidas]

On 2002-05-18 12:56, Steve Kargl wrote:
 === gnu/usr.bin/binutils/gdb
 cc -O -pipe -march=athlon -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/gdb/i386 
-I/usr/src/gnu/usr.bin/binutils/gdb 
-I/usr/src/gnu/usr.bin/binutils/gdb/../libbfd/i386 
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/include 
-Dprint_insn_i386=print_insn_i386_att -Dprint_insn_i386=print_insn_i386_att 
-I/usr/src/gnu/usr.bin/binutils/gdb/i386 
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/binutils 
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/bfd 
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb 
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/config 
-DFREEBSD_ELF -I/usr/src/gnu/usr.bin/binutils/gdb 
-I/usr/obj/usr/src/i386/usr/include/readline   -Werror -Wall -Wno-format-y2k -W 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized  -c init.c
 cc1: warnings being treated as errors

Known problem.

Warnings are treated as errors.  Since GCC 3.1 has brought a hell of a
lot more warnings with us, you should use -DNO_WERROR until the dust
of the GCC 3.1 import settles down.

-- 
Giorgos Keramidas- http://www.FreeBSD.org
[EMAIL PROTECTED] - The Power to Serve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Steve Kargl]

On Sun, May 19, 2002 at 05:31:08AM +0300, Giorgos Keramidas wrote:
 On 2002-05-18 12:56, Steve Kargl wrote:
  === gnu/usr.bin/binutils/gdb
  cc -O -pipe -march=athlon -D_GNU_SOURCE -I. 
-I/usr/src/gnu/usr.bin/binutils/gdb/i386 -I/usr/src/gnu/usr.bin/binutils/gdb 
-I/usr/src/gnu/usr.bin/binutils/gdb/../libbfd/i386 
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/include 
-Dprint_insn_i386=print_insn_i386_att -Dprint_insn_i386=print_insn_i386_att 
-I/usr/src/gnu/usr.bin/binutils/gdb/i386 
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/binutils 
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/bfd 
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb 
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/config 
-DFREEBSD_ELF -I/usr/src/gnu/usr.bin/binutils/gdb 
-I/usr/obj/usr/src/i386/usr/include/readline   -Werror -Wall -Wno-format-y2k -W 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized  -c init.c
  cc1: warnings being treated as errors
 
 Known problem.

I read this list everyday.  I did not recall seeing this
particular failure mentioned, so I thought I'd report it.

 Warnings are treated as errors.  Since GCC 3.1 has brought a hell of a
 lot more warnings with us, you should use -DNO_WERROR until the dust
 of the GCC 3.1 import settles down.

If everyone is using  -DNO_WERROR, then who would report build
problems :-).

-- 
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb breaks world

[Giorgos Keramidas]

On 2002-05-18 20:12, Steve Kargl wrote:
 On Sun, May 19, 2002 at 05:31:08AM +0300, Giorgos Keramidas wrote:
  Warnings are treated as errors.  Since GCC 3.1 has brought a hell
  of a lot more warnings with us, you should use -DNO_WERROR until
  the dust of the GCC 3.1 import settles down.

 If everyone is using  -DNO_WERROR, then who would report build
 problems :-).

True.  I mentioned -DNO_WERROR to help you complete the buildworld.
If you can help with those warnings, then I'm sure David O'Brien will
be very glad to see patches ;-)

-- 
Giorgos Keramidas- http://www.FreeBSD.org
[EMAIL PROTECTED] - The Power to Serve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GDB maintainer?

[Sheldon Hearn]

On Sun, 20 Jan 2002 17:18:30 PST, k Macy wrote:

 Who is the current GDB maintainer?

Not sure there's a single maintainer, but I know these two gentlemen
take a keen interest in the beast:

Bruce Evans [EMAIL PROTECTED]
Brian Dean [EMAIL PROTECTED]

Ciao,
Sheldon.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb(1) broken?

[Mark Santcroos]

Hi Peter,

What is the state of this (for i386)?

Mark

On Sun, Sep 16, 2001 at 11:24:54AM -0700, Julian Elischer wrote:
 Marcel Moolenaar wrote:
  
  Gang,
  
  I don't know exactly what the gdb(1) problems on Alpha are, but we
  do have a problem that's probably not specific to an architecture.
  
  The problem is basicly this: one cannot debug any programs because
  gdb(1) gets a SIGTRAP delivered when it invokes ptrace(2) and never
  gets a change to wait4(2) the interior process.
  
  I don't know the details, but one of the following can be the case
  1. We now deliver a SIGTRAP, when we didn't do so before,
  2. The SIGTRAP comes too quick, it should be caught by the wait4(2).
  
  I couldn't find any indication that 1 happened, so my guess is that
  we suffer from 2.
  
  Is this known?
  Any thoughts?
 
 peter has been working on this...
 
 It's because the process structure and u-area have changed entirely.
 
 
  
  --
   Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
  
  To Unsubscribe: send mail to [EMAIL PROTECTED]
  with unsubscribe freebsd-current in the body of the message
 
 -- 
 ++   __ _  __
 |   __--_|\  Julian Elischer |   \ U \/ / hard at work in 
 |  /   \ [EMAIL PROTECTED] +--x   USA\ a very strange
 | (   OZ)\___   ___ | country !
 +- X_.---._/presently in San Francisco   \_/   \\
   v
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message

-- 
Mark Santcroos  RIPE Network Coordination Centre
http://www.ripe.net/home/mark/  New Projects Group/TTM

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb(1) broken?

[Mark Peek]

At 9:22 AM +0200 9/18/01, Mark Santcroos wrote:
Hi Peter,

What is the state of this (for i386)?

Mark

On Sun, Sep 16, 2001 at 11:24:54AM -0700, Julian Elischer wrote:
  Marcel Moolenaar wrote:
  
   Gang,
  
   I don't know exactly what the gdb(1) problems on Alpha are, but we
   do have a problem that's probably not specific to an architecture.
  
   The problem is basicly this: one cannot debug any programs because
   gdb(1) gets a SIGTRAP delivered when it invokes ptrace(2) and never
   gets a change to wait4(2) the interior process.
  
   I don't know the details, but one of the following can be the case
   1. We now deliver a SIGTRAP, when we didn't do so before,
   2. The SIGTRAP comes too quick, it should be caught by the wait4(2).
  
   I couldn't find any indication that 1 happened, so my guess is that
   we suffer from 2.
  
   Is this known?
   Any thoughts?

  peter has been working on this...

   It's because the process structure and u-area have changed entirely.


I just checked in a change to fix this problem 
(sys/kern/sys_process.c v1.71). The KSE changes caused the trace 
information to be put into the debug process state instead of the 
traced process.

Mark

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb(1) broken?

[Julian Elischer]

Marcel Moolenaar wrote:
 
 Gang,
 
 I don't know exactly what the gdb(1) problems on Alpha are, but we
 do have a problem that's probably not specific to an architecture.
 
 The problem is basicly this: one cannot debug any programs because
 gdb(1) gets a SIGTRAP delivered when it invokes ptrace(2) and never
 gets a change to wait4(2) the "interior" process.
 
 I don't know the details, but one of the following can be the case
 1. We now deliver a SIGTRAP, when we didn't do so before,
 2. The SIGTRAP comes too quick, it should be "caught" by the wait4(2).
 
 I couldn't find any indication that 1 happened, so my guess is that
 we suffer from 2.
 
 Is this known?
 Any thoughts?

peter has been working on this...

It's because the process structure and u-area have changed entirely.


 
 --
  Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message

-- 
++   __ _  __
|   __--_|\  Julian Elischer |   \ U \/ / hard at work in 
|  /   \ [EMAIL PROTECTED] +--x   USA\ a very strange
| (   OZ)\___   ___ | country !
+- X_.---._/presently in San Francisco   \_/   \\
  v

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb(1) broken?

[Marcel Moolenaar]

On Sun, Sep 16, 2001 at 11:24:54AM -0700, Julian Elischer wrote:
 
 peter has been working on this...
 
 It's because the process structure and u-area have changed entirely.

Hmmm... I can't explain the behaviour I see with this info. Can you
explain why gdb(1) gets the SIGTRAP?

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb bug w/ dlopen()ed images

[Max Khon]

hi, there!

On Fri, 25 Aug 2000, John DeBoskey wrote:

There appears to be a problem with gdb when debugging
 dynamically loaded images. On 5.0-current with
 sources current and built as of this evenning and a
 4.1-STABLE system, the following incorrect result is seen:

PR/20373

Solution: apply patch 1.8-1.9 for bfd/elf32-i386.c from binutils source
tree (their cvsweb is somewhere at http://sources.redhat.com/binutils/)
to src/contrib/binutils/bfd/elf32-i386.c and rebuild
src/gnu/usr.bin/binutils/libbfd and
src/gnu/usr.bin/binutils/ld

Unfortunately for some reason I cannot post follow-up for this PR. 
David O'Brien has all the information.

/fjoe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: GDB 5...

[Kris Kennaway]

On Sun, 2 Apr 2000, Mirko Viviani wrote:

 Ciao.
 
 As stated in gdb mlist, gdb 5.0 is on the way but it hasn't support for  
 freebsd-elf in
 the package. Is there anyone that could explain me why ?

You're more likely to get an answer by asking the gdb developers on the
gdb "mlist" :-)

Kris


In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: GDB Problems !

[Dag-Erling Smorgrav]

Pascal Hofstee [EMAIL PROTECTED] writes:
 just noticed this again. And considering 4.0 is coming up soon, I really
 Compiling this program with -ggdb will give normal results (a list of i =
 0, upto i = 9). However when running the program through gdb Every Value
 you can print is completely Bogus, which makes debugging impossible.

For the record, I'm seeing the same problem.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb trouble in 4.0-current

[Sheldon Hearn]

On Sat, 20 Nov 1999 20:24:47 EST, Wes Morgan wrote:

 (gdb) r
 Starting program: /usr/home/by-tor/mms-0.90/./mms
 warning: find_solib: Can't read pathname for load map: Bad address
 
 Segmentation fault (core dumped)

You're not alone.  The work-around is to compile with --static.

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb trouble in 4.0-current

[Bruce Evans]

On Mon, 22 Nov 1999, Sheldon Hearn wrote:
 
 On Sat, 20 Nov 1999 20:24:47 EST, Wes Morgan wrote:
 
  (gdb) r
  Starting program: /usr/home/by-tor/mms-0.90/./mms
  warning: find_solib: Can't read pathname for load map: Bad address
  
  Segmentation fault (core dumped)
 
 You're not alone.  The work-around is to compile with --static.

Even that is broken for attaching to running (statically linked) processes.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

[Kip Macy]

I tried doing the same on FreeBSD 3.2-STABLE
but when I run it it complains that it is unable to find dynamic linker
breakpoint function and then it stops with a SIGTRAP.
Any ideas what might be wrong?

Thanks.

-Kip

On Fri, 20 Aug 1999, Richard Cownie wrote:

 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 ([EMAIL PROTECTED])
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message
 
 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

[Alex Zepeda]

On Sun, 22 Aug 1999, Richard Cownie wrote:

 On Sat, 21 Aug 1999, David O'Brien wrote:
  Are you saying 4.17 is better than 4.18 for debugging C++?  Or are you
  saying you didn't know FreeBSD comes with gdb:
 
 gdb-4.18 is badly broken on all platforms (at least for C++).  You can't
 call methods from the gdb command line, and also it frequently freezes
 to the point where you have to kill the window.  gdb-4.17 is much better
 for C++. 

Really?  I don't use gdb much so, I wouldn't know, but I've seen reports
that KOffice is undebugable with 4.17 (gdb segfaults), but is with 4.18.
Hmm.

- alex



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

[Kip Macy]

on 3.2-R gdb-4.18 will core dump without fail when I try to read a core
file generated by the C++ program I am developing - gdb-4.17 does not have
this problem.

-Kip

On Tue, 31 Aug 1999, Alex Zepeda wrote:

 On Sun, 22 Aug 1999, Richard Cownie wrote:
 
  On Sat, 21 Aug 1999, David O'Brien wrote:
   Are you saying 4.17 is better than 4.18 for debugging C++?  Or are you
   saying you didn't know FreeBSD comes with gdb:
  
  gdb-4.18 is badly broken on all platforms (at least for C++).  You can't
  call methods from the gdb command line, and also it frequently freezes
  to the point where you have to kill the window.  gdb-4.17 is much better
  for C++. 
 
 Really?  I don't use gdb much so, I wouldn't know, but I've seen reports
 that KOffice is undebugable with 4.17 (gdb segfaults), but is with 4.18.
 Hmm.
 
 - alex
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message
 
 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb weirdness

[Greg Lehey]

On Sunday, 29 August 1999 at 10:46:33 +0200, Pascal Hofstee wrote:
 On Sun, 29 Aug 1999, Greg Lehey wrote:

 I seem to having some weird problems using GDB on 4.0-CURRENT
 27for (j = 1; j = 31; j++) {
 (gdb)
 28   temp = wmalloc(sizeof(ADay));
 (gdb) print j
 $1 = -1077947156

 Does it do this without the -O flag?  It may use j elsewhere, but have
 elided it here.

 All files are compiled like this:
 gcc -Wall -ggdb -ansi -pedantic-I/usr/X11R6/include
 -I/usr/X11R6/include  `get-wraster-flags --cflags` -I. -DCSRG_BASED
 -DFUNCPROTO=15 -DNARROWPROTO   -c main.c

 And I still get the weird gdb behaviour

Make sure you're really where you think you are.  If so, it could be a
bug.  What does the assembly code look like?

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

[Daniel Eischen]

 Did anyone of you took care that you can build an aout gdb on an ELF
 FreeBSD system? 

 I don't mean a gdb that is aout, but one that can debug aout binaries.

I thought the gdb in our base system could debug aout binaries.  Or
am I sadly mistaken.

 That would be most useful to have as a port. Just step to
 `/usr/ports/devel/aout-gdb  make install` and it uses
 /usr/src/gnu/usr.bin/gdb or fetches some other source by itself if it
 can't use native sources. The modula-3 port does something in that
 line, uses /usr/src if it can.

I haven't tested the port on aout.  The main reason I did the port
was to make an Ada-aware version of gdb.  The GNAT maintainers
release patches to a specific version of gdb (in this case gdb-4.17),
so basing a port of gdb on what's in our base system was a bad
idea.  The gdb port I mentioned wasn't the Ada-aware gdb port, it
was just a step to get there.

Dan Eischen
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

[Martin Cracauer]

In [EMAIL PROTECTED], Daniel Eischen wrote: 
  Did anyone of you took care that you can build an aout gdb on an ELF
  FreeBSD system? 
 
  I don't mean a gdb that is aout, but one that can debug aout binaries.
 
 I thought the gdb in our base system could debug aout binaries.  Or
 am I sadly mistaken.

You can compile it so that the gdb binary is aout 
(`cd /usr/src/gnu/usr.bin/binutils  make OBJFORMAT=aout), but that's
still a debugger that debugs ELF binaries.

It can't handle aout binaries unless you explicitly configure it to do
so and this ability seems to be broken by the FreeBSD-specific
changes.
 
  That would be most useful to have as a port. Just step to
  `/usr/ports/devel/aout-gdb  make install` and it uses
  /usr/src/gnu/usr.bin/gdb or fetches some other source by itself if it
  can't use native sources. The modula-3 port does something in that
  line, uses /usr/src if it can.
 
 I haven't tested the port on aout.  The main reason I did the port
 was to make an Ada-aware version of gdb.  The GNAT maintainers
 release patches to a specific version of gdb (in this case gdb-4.17),
 so basing a port of gdb on what's in our base system was a bad
 idea.  The gdb port I mentioned wasn't the Ada-aware gdb port, it
 was just a step to get there.

Well, on second thinking the idea to build from /usr/src might not
save much.

You need the binutils libraries and friends as aout, so it might be
easier to start from a source that carries everything you need with
it and link it statically.

Martin
-- 
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

SIGBUS [was Re: gdb]

[Joel Ray Holveck]

 (gdb) run
 Starting program: /tmp/./sieve 
 Program received signal SIGBUS, Bus error.

That reminds me.  I thought that SIGBUS meant byte-alignment errors.
What does it mean on FreeBSD/x86?

Cheers,
joelh

-- 
Joel Ray Holveck - [EMAIL PROTECTED]
   Fourth law of programming:
   Anything that can go wrong wi
sendmail: segmentation violation - core dumped


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

[Daniel Eischen]

Richard Cownie wrote:
 On Sat, 21 Aug 1999, David O'Brien wrote:
  Are you saying 4.17 is better than 4.18 for debugging C++?  Or are you
  saying you didn't know FreeBSD comes with gdb:

 gdb-4.18 is badly broken on all platforms (at least for C++).  You can't
 call methods from the gdb command line, and also it frequently freezes
 to the point where you have to kill the window.  gdb-4.17 is much better
 for C++. 

There's a port for gdb-4.17 sitting on my ftp site at:

  ftp://ftp.pcnet.com/users/eischen/FreeBSD/gdb-4.17-port.tar.gz

The port includes changes made to the gdb in our base system
(then, Mar 1999, it was gdb-4.15 I believe).  I haven't made
any further updates to it since.  You're welcome to play around
with it.

Dan Eischen
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SIGBUS [was Re: gdb]

[Alfred Perlstein]

On 18 Aug 1999, Joel Ray Holveck wrote:

  (gdb) run
  Starting program: /tmp/./sieve 
  Program received signal SIGBUS, Bus error.
 
 That reminds me.  I thought that SIGBUS meant byte-alignment errors.
 What does it mean on FreeBSD/x86?

Another possible source for SIGBUS should be generated when accessing
a mmap'd region past the end of a file.

-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] 
systems administrator and programmer
Wintelcom - http://www.wintelcom.net/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb

[Richard Cownie]

On Tue, 17 Aug 1999, Alex Zepeda wrote:
 4.17 is really no better, it tended to crash on some C++ programs.  If
 4.18 doesn't work, try sending email to the authors of gdb, or look for a
 pre-release version.
 
 - alex

From personal experience here, I disagree.  We use gdb-4.17 all the
time on Solaris and it works well enough.  gdb-4.17 on Linux is also ok.
gdb-4.18 is much worse (at least for our particular style of usage).
Your mileage may vary.

I just checked out the latest sources of gdb from CVS.  It doesn't build
under 4.0-19990604-CURRENT, has problems compiling gdb/solib.c

Richard Cownie ([EMAIL PROTECTED])


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb

[Amancio Hasty]

 A side note on gdb-4.18 8)


(gdb) run
Starting program: /tmp/./sieve 

Program received signal SIGBUS, Bus error.
0x281eeac7 in GC_find_limit (p=0xbfbfcff8 "", up=1)
at ../../../../libgcj-2.95/boehm-gc/os_dep.c:681
681 ../../../../libgcj-2.95/boehm-gc/os_dep.c: No such file or directory.
Current language:  auto; currently c
(gdb) cont
Continuing.
Running Sieve benchmark.
This will take about 10 seconds.

Breakpoint 1, Sieve.runSieve () at Sieve.java:16
16   int SIZE = 8190;
Current language:  auto; currently java
(gdb) list
11   System.out.println(results1);
12   System.out.println(results2);
13}
14
15static void runSieve() {
16   int SIZE = 8190;
17   boolean flags[] = new boolean[SIZE+1];
18   int i, prime, k, iter, count;
19   int iterations = 0;
20   double seconds = 0.0;
(gdb) list
21   int score = 0;
22   long startTime, elapsedTime;
23
24   startTime = System.currentTimeMillis();
25   while (true) {
26  count=0;
27  for(i=0; i=SIZE; i++) flags[i]=true;
28  for (i=0; i=SIZE; i++) {
29 if(flags[i]) {
30prime=i+i+3;

It still needs a little work however gdb appears to work java programs
compiled with  "gcj" -- GNU's java compiler -- java to native binary ..

gcj still needs work however it is starting to shape up.


Enjoy

-- 

 Amancio Hasty
 [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message