;> Could you please try to narrow down the crashing command? e.g.
>>>>> Ifconfig lo0
>>>>> Ifconfig lo0 net
>>>>> Ifconfig lo0 inet6
>>>>> Could you try to rebuild ifconfig w/o netlink (e.g. set
>>>>> WITHOUT_NETLINK=yes
et6
> >>> Could you try to rebuild ifconfig w/o netlink (e.g. set
> >>> WITHOUT_NETLINK=yes in the make.conf & make -C sbin/ifconfig clean all
> >>> install) and see if the new binary works?
> >>>
> >>
> >> I already have WITH
>>
>>
>> I already have WITHOUT_NETLINK=yes in my /etc/src.conf.
>>
>> I didn't install ifconfig. I simply started it from the build directory.
>>
>> ifconfig lo0 shows the settings for lo0 and then dumps core.
>>
>
> After your most re
t; in the make.conf & make -C sbin/ifconfig clean all install) and see if the
> > new binary works?
> >
>
> I already have WITHOUT_NETLINK=yes in my /etc/src.conf.
>
> I didn't install ifconfig. I simply started it from the build directory.
>
> ifconfig lo0 sho
tting
> >> some weird errors.
> >>
> >> -O0 -g3 removes too much and gdb shows no useful information.
> >
> > Build it with:
> >
> > WITH_DEBUG=1 DEBUG_FLAGS="-O3 -g3"
> >
>
> Silly me.
>
> Actually with:
>
> WITH_DEB
>> in the make.conf & make -C sbin/ifconfig clean all install) and see if the
>> new binary works?
>>
>
> I already have WITHOUT_NETLINK=yes in my /etc/src.conf.
>
> I didn't install ifconfig. I simply started it from the build directory.
>
> ifconf
> On 14 Jun 2023, at 11:12, Juraj Lutter wrote:
>
>
>
>> On 14 Jun 2023, at 11:01, Gary Jennejohn wrote:
>> I compiled gbd under /usr/ports and it now works, although it's emitting
>> some weird errors.
>>
>> -O0 -g3 removes too much and gdb
> On 14 Jun 2023, at 11:01, Gary Jennejohn wrote:
> I compiled gbd under /usr/ports and it now works, although it's emitting
> some weird errors.
>
> -O0 -g3 removes too much and gdb shows no useful information.
Build it with:
WITH_DEBUG=1 DEBUG_FLAGS=“-O3 -g3”
ot
config. I simply started it from the build directory.
ifconfig lo0 shows the settings for lo0 and then dumps core.
> >
> > Unfortunately, I see this error message when I try to look at the core
> > file with gdb:
> >
> > gdb /sbin/ifconfig ifconfig.core
> >
ee if the new
binary works?
>
> Unfortunately, I see this error message when I try to look at the core
> file with gdb:
>
> gdb /sbin/ifconfig ifconfig.core
> ld-elf.so.1: Undefined symbol "rl_eof_found" referenced from COPY
> relocation in /usr/local/bin/gdb
Not a
correctly
shown:
ifconfig
re0: flags=8843 metric 0 mtu 4088
options=82098
ether redacted
inet 192.168.178.XXX netmask 0xff00 broadcast 192.168.178.255
Segmentation fault (core dumped)
Unfortunately, I see this error message when I try to look at the core
file with gdb:
gdb /sbin
I would like to call attention to this change to prevent accidentally
rebooting the target of remote kernel GDB. The code is mundane, but the
default could be controversial.
https://reviews.freebsd.org/D35473
Please comment on the review, not on this thread. If you need an
account on
Adding the FreeBSD-stable list to CC for more visibility.
On Wed, 2 Dec 2020 at 12:43, Ed Maste wrote:
>
> I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to
> switch the GDB knob to default to NO in the near future. If the
> crashinfo utility and related man pages do
on FreeBSD, and they've done
great work getting it into shape. Their work is in LLVM upstream now,
and they're iterating on fixing issues found by LLDB's test suite.
LLDB 12 should provide a capable userland debugging experience in
FreeBSD 13, although I suspect many users will still
On Wed, Dec 2, 2020 at 10:44 AM Ed Maste wrote:
> We currently have an obsolete version of GDB 6.1 installed as
> /usr/libexec/gdb, kept only for use by crashinfo(8), which extracts
> some basic information from a kernel core dump after a crash. If the
> gdb port is installed crashi
We currently have an obsolete version of GDB 6.1 installed as
/usr/libexec/gdb, kept only for use by crashinfo(8), which extracts
some basic information from a kernel core dump after a crash. If the
gdb port is installed crashinfo will use that in preference to
/usr/libexec/gdb. If neither exists
restarting fortune core dumps. When trying to load the core dump,
> > gdb core dumps.
> >
> > The message is always:
> >
> > Bad system call (core dumped)
> >
> > Trying to install ports results in the same effect.
> >
> > Erich
>
> Try
On Sat, Aug 4, 2018 at 9:17 PM Erich Dollansky
wrote:
>
> Hi,
>
> I compiled me yesterday this system:
>
> 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r337285:
>
> When restarting fortune core dumps. When trying to load the core dump,
> gdb core dumps.
>
> The messa
> On 8/8/18 4:49 PM, Erich Dollansky wrote:
> > Hi,
> >
> > here we are:
> >
> > http://sumeritec/FreeBSD/fortune.core
> > http://sumeritec/FreeBSD/gdb.core
> >
> > The fortune core is from the same source as the now running system
On 8/8/18 4:49 PM, Erich Dollansky wrote:
> Hi,
>
> here we are:
>
> http://sumeritec/FreeBSD/fortune.core
> http://sumeritec/FreeBSD/gdb.core
>
> The fortune core is from the same source as the now running system. The
> gdb core should be but I am not 100% sure.
>
Hi,
here we are:
http://sumeritec/FreeBSD/fortune.core
http://sumeritec/FreeBSD/gdb.core
The fortune core is from the same source as the now running system. The
gdb core should be but I am not 100% sure.
Revision: Revision: 337343
Erich
On Wed, 8 Aug 2018 08:57:06 -0700
John Baldwin wrote
On 8/7/18 7:00 PM, Erich Dollansky wrote:
> Hi,
>
> On Tue, 7 Aug 2018 11:59:11 -0700
> John Baldwin wrote:
>
>> On 8/6/18 8:11 PM, Erich Dollansky wrote:
>>> On Mon, 6 Aug 2018 15:57:53 -0700
>>> John Baldwin wrote:
>>>
On 8/4/18 4:38 PM, Erich Dollansky wrote:
>
> Bad system ca
Hi,
On Tue, 7 Aug 2018 11:59:11 -0700
John Baldwin wrote:
> On 8/6/18 8:11 PM, Erich Dollansky wrote:
> > On Mon, 6 Aug 2018 15:57:53 -0700
> > John Baldwin wrote:
> >
> >> On 8/4/18 4:38 PM, Erich Dollansky wrote:
> >>> Bad system call (core dumped)
> >>
> >> Did you upgrade from stable/
T FreeBSD 12.0-CURRENT #1 r337285:
>>>
>>> When restarting fortune core dumps. When trying to load the core
>>> dump, gdb core dumps.
>>>
>>> The message is always:
>>>
>>> Bad system call (core dumped)
>>>
>>> Trying to
Hi,
On Tue, 7 Aug 2018 00:09:15 -0400
Allan Jude wrote:
> On 2018-08-06 23:11, Erich Dollansky wrote:
> >>> The message is always:
> >>>
> >>> Bad system call (core dumped)
>
> compare the output of: `uname -K` and `uname -U`
>
both outputs are
1200076
I got just access to that machine aga
T FreeBSD 12.0-CURRENT #1 r337285:
>>>
>>> When restarting fortune core dumps. When trying to load the core
>>> dump, gdb core dumps.
>>>
>>> The message is always:
>>>
>>> Bad system call (core dumped)
>>>
>>> Tryi
dumps. When trying to load the core
> > dump, gdb core dumps.
> >
> > The message is always:
> >
> > Bad system call (core dumped)
> >
> > Trying to install ports results in the same effect.
> >
> > Erich
>
> Did you upgrade fr
On 8/4/18 4:38 PM, Erich Dollansky wrote:
> Hi,
>
> I compiled me yesterday this system:
>
> 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r337285:
>
> When restarting fortune core dumps. When trying to load the core dump,
> gdb core dumps.
>
> The message is always:
>
Hi,
I compiled me yesterday this system:
12.0-CURRENT FreeBSD 12.0-CURRENT #1 r337285:
When restarting fortune core dumps. When trying to load the core dump,
gdb core dumps.
The message is always:
Bad system call (core dumped)
Trying to install ports results in the same effect.
Erich
ser
> > software.
>
> ---
> r317416 | jhb | 2017-04-25 13:08:56 -0500 (Tue, 25 Apr 2017) | 16 lines
>
> Add a new GDB_LIBEXEC option to install gdb and kgdb to /usr/libexec.
>
> When this option is enabled, only gdb and kgdb are installed to
> /usr/libexec for use by crashinfo(8). O
On Sun, Jun 25, 2017 at 09:03:58PM +0200, Trond Endrestøl wrote:
> On Sun, 25 Jun 2017 20:55+0200, Trond Endrestøl wrote:
>
> > I was at bit surprised to see gdb missing from /usr/bin this evening.
> > The executables are still being built in /usr/obj/usr/src/gnu/usr.bin/gdb.
&
On Sun, 25 Jun 2017 20:55+0200, Trond Endrestøl wrote:
> I was at bit surprised to see gdb missing from /usr/bin this evening.
> The executables are still being built in /usr/obj/usr/src/gnu/usr.bin/gdb.
>
> This is on base/head r320329.
>
> Do we need to add WITH_GDB=yes to
I was at bit surprised to see gdb missing from /usr/bin this evening.
The executables are still being built in /usr/obj/usr/src/gnu/usr.bin/gdb.
This is on base/head r320329.
Do we need to add WITH_GDB=yes to our src.conf files
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 eva
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?
And if so, better to lear
> On Dec 8, 2015, at 10:42 AM, John Baldwin wrote:
>
> On Tuesday, December 08, 2015 12:31:11 PM David Chisnall wrote:
>> The gdb in the base system doesn’t support DWARF4. Use gdb791 or lldb-devel
>> from ports (I believe gdb791 is probably a better bet on ARM, curre
On Tuesday, December 08, 2015 12:31:11 PM David Chisnall wrote:
> The gdb in the base system doesn’t support DWARF4. Use gdb791 or lldb-devel
> from ports (I believe gdb791 is probably a better bet on ARM, currently).
gdb710 in ports does not support arm (yet).
--
John B
On 08 Dec 2015, at 10:02, Ray Newman wrote:
>
> Compiled using gcc (FreeBSD Ports Collection) 4.8.5 on arm (Raspberry Pi -
> several versions); BSDmakefile attached (make test used).
> gdb gives:
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
>
The gdb in the base system doesn’t support DWARF4. Use gdb791 or lldb-devel
from ports (I believe gdb791 is probably a better bet on ARM, currently).
David
> On 8 Dec 2015, at 09:02, Ray Newman wrote:
>
> Hi,
>
> Compiled using gcc (FreeBSD Ports Collection) 4.8.5 on ar
Hi,
Compiled using gcc (FreeBSD Ports Collection) 4.8.5 on arm (Raspberry Pi -
several versions); BSDmakefile attached (make test used).
gdb gives:
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
On Monday, August 31, 2015 02:32:04 PM John Baldwin wrote:
> Over the past several months I have ported kgdb to the version of gdb in
> ports.
> I have a pending patch to the gdb port to add fork following, but once that is
> done (and possibly after updating to 7.10) I will t
On Friday, October 02, 2015 09:19:13 AM Andriy Gapon wrote:
> On 01/09/2015 00:32, John Baldwin wrote:
> > Over the past several months I have ported kgdb to the version of gdb in
> > ports.
> > I have a pending patch to the gdb port to add fork following, but once that
On Fri, Oct 02, 2015 at 09:19:13AM +0300, Andriy Gapon wrote:
> On 01/09/2015 00:32, John Baldwin wrote:
> > Over the past several months I have ported kgdb to the version of gdb in
> > ports.
> > I have a pending patch to the gdb port to add fork following, but once that
On 01/09/2015 00:32, John Baldwin wrote:
> Over the past several months I have ported kgdb to the version of gdb in
> ports.
> I have a pending patch to the gdb port to add fork following, but once that is
> done (and possibly after updating to 7.10) I will try to add my existing work
Over the past several months I have ported kgdb to the version of gdb in ports.
I have a pending patch to the gdb port to add fork following, but once that is
done (and possibly after updating to 7.10) I will try to add my existing work
as a KGDB option on the port. Until such time, you can try
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 P
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
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.
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
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
On Wednesday, January 16, 2013 1:30:37 am Adrian Chadd wrote:
> Also, I found 'set remotebaud' and 'set debug remote 1' to do this.
>
> I'd like to add the code just to support the same -b flag as gdb (so
> -r can also be used with a non-standard ser
d yes, it'd be nice to have -b so I can use -b and -r to instantly
open up a remote gdb session.
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "
t; Hi,
>>>
>>> There doesn't seem to be a blessed way to set the baudrate from inside
>>> gdb/kgdb. It seems to be set from '-b' on the command line.
>>>
>>> However kgdb doesn't have this support.
>>>
>>> This pat
On Jan 16, 2013, at 7:35 AM, Warner Losh wrote:
> How does 'set remotebaud' not do what you want?
>
> Warner
>
> On Jan 15, 2013, at 10:15 PM, Adrian Chadd wrote:
>
>> Hi,
>>
>> There doesn't seem to be a blessed way to set the baudrate f
How does 'set remotebaud' not do what you want?
Warner
On Jan 15, 2013, at 10:15 PM, Adrian Chadd wrote:
> Hi,
>
> There doesn't seem to be a blessed way to set the baudrate from inside
> gdb/kgdb. It seems to be set from '-b' on the command line.
>
Also, I found 'set remotebaud' and 'set debug remote 1' to do this.
I'd like to add the code just to support the same -b flag as gdb (so
-r can also be used with a non-standard serial port.)
Thanks,
Adrian
On 15 January 2013 21:15, Adrian Chadd wrote:
> Hi,
&g
Hi,
There doesn't seem to be a blessed way to set the baudrate from inside
gdb/kgdb. It seems to be set from '-b' on the command line.
However kgdb doesn't have this support.
This patch adds -b support so kgdb so I can override the default speed
(9600 it seems) to speak k
On Tue, Mar 13, 2012 at 01:40:12PM +0100, Alexandre Martins wrote:
> Two other thing
> - The process consume memory, but there is no allocation in my code. Maybe a
> leak in the libc ?
No, this is a leak in rtld. I fixed it in r233546.
> - My kernel have crashed after some minute of leak (i hav
ompilled with "MALLOC_DEBUG" flag to detect double
> >>> free. When i run this piece of code (attached file) thought GDB, i
> >>> have this assertion :
> >>>
> >>> Assertion failed: ((run->regs_mask[elm] & (1U << bit)) == 0)
gt;> When i run this piece of code (attached file) thought GDB, i have this
>>> assertion :
>>>
>>> Assertion failed: ((run->regs_mask[elm] & (1U << bit)) == 0), function
>>> arena_run_reg_dalloc, file /usr/src/lib/libc/stdlib/malloc.c, line 2543.
I
27;s just a sample. There is no exit here, you have to kill the process.
>
> > ...
> > Compilation and execution :
> >
> > gcc -shared -O0 -g second.c -o second.so
> > gcc -shared -O0 -g first.c -o libfirst.so
> > gcc -O0 -g toto.c -lfirst -L. -o test
> >
first.c -o libfirst.so
> gcc -O0 -g toto.c -lfirst -L. -o test
> export LD_LIBRARY_PATH=$PWD
> gdb ./test
> ...
What is your toto.c (source code) ?
What about your main.c in compilation ?
jb
___
freebsd-current@freebsd.org mailing list
htt
:
> > > > Dear all,
> > > >
> > > > I'm currently having some trouble with the dynamic loader.
> > > >
> > > > I have the libc compilled with "MALLOC_DEBUG" flag to detect double
> > > > free. When i run this piece of c
ving some trouble with the dynamic loader.
> > >
> > > I have the libc compilled with "MALLOC_DEBUG" flag to detect double free.
> > > When i run this piece of code (attached file) thought GDB, i have this
> > > assertion :
> > >
> > > Asserti
ot;MALLOC_DEBUG" flag to detect double free.
> > When i run this piece of code (attached file) thought GDB, i have this
> > assertion :
> >
> > Assertion failed: ((run->regs_mask[elm] & (1U << bit)) == 0), function
> > arena_run_reg_dalloc, file /usr/src/l
On Mon, Mar 12, 2012 at 05:50:33PM +0100, Alexandre Martins wrote:
> Dear all,
>
> I'm currently having some trouble with the dynamic loader.
>
> I have the libc compilled with "MALLOC_DEBUG" flag to detect double free.
> When i run this piece of code (attach
Dear all,
I'm currently having some trouble with the dynamic loader.
I have the libc compilled with "MALLOC_DEBUG" flag to detect double free.
When i run this piece of code (attached file) thought GDB, i have this
assertion :
Assertion failed: ((run->regs_mask[elm] &
On 2/5/12 3:05 AM, Andriy Gapon wrote:
on 05/02/2012 09:58 Julian Elischer said the following:
In 9.x ( can't check -current, but teh mailing list has a better readership)
I'm still seeing this and have still not found any solution:
possible reasons for the change may be:
1/ change to kgdb?
2/
on 05/02/2012 09:58 Julian Elischer said the following:
> In 9.x ( can't check -current, but teh mailing list has a better readership)
>
> I'm still seeing this and have still not found any solution:
> possible reasons for the change may be:
> 1/ change to kgdb?
> 2/ change to the compiling toolse
In 9.x ( can't check -current, but teh mailing list has a better
readership)
I'm still seeing this and have still not found any solution:
possible reasons for the change may be:
1/ change to kgdb?
2/ change to the compiling toolset?
3/ change to the .mk files for compiling modules?
any guidance
>Submitter-Id: current-users
>Originator:Vladimir Grebenschikov
>Organization: SWsoft
>Confidential: no
>Synopsis: Problem with GDB on latest -CURRENT
>Severity: non-critical
>Priority: medium
>Category: bin
>Class: sw-bug
>Rele
В вт, 07.10.2003, в 04:24, Kris Kennaway пишет:
> > Debugging CURRENT kernels using remote gdb on STABLE does not work ?
>
> That's probably to be expected - trying to debug a 5.x crashdump with
> 4.x's gdb also doesn't work, because gdb needs to know details of
On Mon, Oct 06, 2003 at 10:34:50PM +0400, Vladimir B. Grebenschikov wrote:
>
> Hi
>
> Debugging CURRENT kernels using remote gdb on STABLE does not work ?
That's probably to be expected - trying to debug a 5.x crashdump with
4.x's gdb also doesn't work, because gdb n
Hi
Debugging CURRENT kernels using remote gdb on STABLE does not work ?
/ext/current/src# uname -r
4.9-PRERELEASE
/ext/current/src# gdb -k /usr/obj/ext/current/src/sys/VBOOK/kernel.debug
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the
I'm running a ~2 week old -current, and when debugging some hacks of
mine, I noticed that gdb -k seems to be missing at least one frame
in its stack. Eg, ddb shows:
panic: page fault
cpuid = 0; lapic.id =
Stack backtrace:
backtrace(c0380cf2,0,c036e757,d96d4bd4,100) at backtrace
Hi.
This might be of interest to anyone who has tried debugging
multi-threaded programs (of the libc_r variety) with gdb. This has been
bugging me for months, and I finally got frustrated enough to find out
what was going on.
The symptom:
Once you call any function that puts a thread to sleep
;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 upgradin
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,
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 Al
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,
> 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] m
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 :-
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 t
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
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
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 w
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.
o We still have the Alpha gdb -k bug moved
Hello all,
I was recently playing around with gdb. I do not use it much but I found that
it had an apropos command. I hoped that apropos would make it quicker for me
to find information about gdb's commands so I wouldn't have to go hunting in
info. Turns out there is a bug in gdb
Hello,
I have updated my scripts for loading KLD symbols into kgdb. This is
designed to work with core dumps. It will search out and find the symbol
files automaticly. It will search both the compile directory and the
modules directory of the source tree. This is for people who want to
work on
e 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 /
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 i
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. :)
Jun Su
--/usr/src/gnu/usr.bin/binutils/gdb/fbsd
Howdy all,
I have a situation on my FreeBSD 5.0-CURRENT #7: Thu Jan 23 14:12:15 CST 2003 box.
After the box has been up for approx 15 days with X running, X suddenly 'freezes' and
the
root window becomes corrupt (looks distorted and getting eaten away). I can swtich to
the
Virtual Console and ba
Sorry if this appears twice: my webmail client appears to have dropped
the original message on the floor.
gdb didn't find threads in corefiles: The support was just missing.
The attached patch does the job.
Also attached is a small test program which easily generates a corefile
with th
On Sun, 5 Jan 2003, ryan beasley wrote:
> For what it's worth, I've taken Nate's suggestion and backed down to
> 9600bps, and this problem hasn't occurred yet, so I'm assuming this is
> the "fix". (The 4.7 machine has an ASUS P2B-D board, and the -CURRENT
> box is a recent Dell Dim
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()
>faile
r ast()
failed to set signal flags properly for ast()
It appears to happen frequently when running the previously posted "test"
source code for -pthread under gdb. When running the test program outside
of gdb, this doesn't happen, suggesting a possible interaction with
ptrace. To trigg
On Sat, Jan 04, 2003 at 06:32:43AM +1100, Bruce Evans wrote:
> Another possible problem is using the same serial line for gdb as for
> the console and mixing speeds. If the userland speed differs from the
> low level speed, then the i/o routines switch back and forth between
> th
On Fri, Jan 03, 2003 at 09:13:44AM -0600, ryan beasley wrote:
> instance of gdb was compiled from source w/ the patches found in the
> devel/gdb52 port. (I don't have room for the ports tree locally.)
pkg_add -r gdb52
(or try the gdb53 port also)
To Unsubscribe: send mai
On Fri, 3 Jan 2003, Nate Lawson wrote:
> On Fri, 3 Jan 2003, ryan beasley wrote:
> > The serial port on the -CURRENT machine is compiled at 38400. FYI,
> > jesper == 4.7R-p2 debugging box, and fredrik == 5.0 panic box. This
> > instance of gdb was compiled from
1 - 100 of 284 matches
Mail list logo
