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

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

Re: gdb problem

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

Re: gdb has outdated knowledge of signal trampolines

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

Re: gdb has outdated knowledge of signal trampolines

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

Re: GDB - do we dare?

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

Re: GDB - do we dare?

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

Re: GDB - do we dare?

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

Re: GDB - do we dare?

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

Re: GDB - do we dare?

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

Re: GDB - do we dare?

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

Re: GDB - do we dare?

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

Re: GDB - do we dare?

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

Re: GDB - do we dare?

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

Re: GDB - do we dare?

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

Re: GDB kernel debug new command

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

Re: GDB kernel debug new command

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

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

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

Re: GDB auto enter/detach patch

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

Re: GDB auto enter/detach patch

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

Re: gdb errors in world

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

Re: gdb errors in world

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

Re: gdb breaks world

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

Re: gdb breaks world

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

Re: gdb breaks world

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

Re: gdb breaks world

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

Re: gdb breaks world

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

Re: gdb breaks world

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

Re: gdb breaks world

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

Re: gdb breaks world

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 -

Re: gdb breaks world

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

Re: gdb breaks world

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

Re: gdb breaks world

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.

Re: gdb breaks world

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

Re: gdb breaks world

: 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

Re: gdb breaks world

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

Re: gdb breaks world

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

Re: gdb breaks world

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

Re: gdb breaks world

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.

Re: gdb breaks world

: 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

Re: gdb breaks world

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

Re: gdb breaks world

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

Re: gdb breaks world

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,

Re: gdb breaks world

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

Re: gdb breaks world

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

Re: gdb breaks world

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

Re: gdb breaks world

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

Re: GDB maintainer?

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

Re: gdb(1) broken?

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.

Re: gdb(1) broken?

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

Re: gdb(1) broken?

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

Re: gdb(1) broken?

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

Re: gdb bug w/ dlopen()ed images

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:

Re: GDB 5...

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

Re: GDB Problems !

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

Re: gdb trouble in 4.0-current

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,

Re: gdb trouble in 4.0-current

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

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

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

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

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

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

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:

Re: gdb weirdness

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 =

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

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.

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

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

SIGBUS [was Re: gdb]

(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

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

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

Re: SIGBUS [was Re: gdb]

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

Re: gdb

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

Re: gdb

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