* Re: GDB & FreeBSD
[not found] <200005211217.e4LCHPv00623@delius.kettenis.local>
2000-05-22 10:17 ` GDB & FreeBSD Daniel Berlin
@ 2000-05-23 12:43 ` J.T. Conklin
1 sibling, 0 replies; 3+ messages in thread
From: J.T. Conklin @ 2000-05-23 12:43 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gdb
Mark> I spent some time on reviving GDB on FreeBSD. Not too difficult
Mark> since it turns out that I can re-use a lot of code from the
Mark> NetBSD port (thanks J.T. :-)).
Your welcome.
Mark> However, in doing so, I've probably killed support for older
Mark> FreeBSD systems (I suspect that the same happened with NetBSD).
If so, it wasn't the intent.
The earliest machines I have are running 1.3. If it turns out I broke
an earlier release, I'll fix it. But I'm not planning on installing
NetBSD 0.9 just to check... I'd rather spend the time to get i386/ELF
support into the tree.
--jtc
--
J.T. Conklin
RedBack Networks
From jtc@redback.com Tue May 23 12:53:00 2000
From: jtc@redback.com (J.T. Conklin)
To: <riazr@cat.co.za>
Cc: <gdb@sourceware.cygnus.com>
Subject: Re: Breakpoint on Memory Range?
Date: Tue, 23 May 2000 12:53:00 -0000
Message-id: <5mya5182nx.fsf@jtc.redback.com>
References: <000001bfc4d2$7424ac80$1923a8c0@cat.co.za>
X-SW-Source: 2000-05/msg00118.html
Content-length: 829
>>>>> "Riaz" == Riaz <riazr@cat.co.za> writes:
Riaz> Does GDB 5.0 (i386 NetBSD) offer the ability to stop execution
Riaz> when there has been a "write" to a memory range?
GDB supports watchpoints, that can be used to see if a memory variable
is changed. The watchpoint command takes an expression, not a memory
range, as its argument; although I suppose that you could construct a
expression that would fit your range. Even if this works, it will be
slow.
Riaz> I specifically need to know whether my code is being overwritten.
I think this is unlikely, unless you are dynamically generating code
on the stack, in the heap or in the data segment. The .text (code)
segment is mapped read only. Any attempt to overwrite your code
should result in a segmentation violation.
--jtc
--
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Tue May 23 18:58:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Larry Cohen <Larry.J.Cohen@saic.com>
Cc: help-gcc@gnu.org, gdb@sourceware.cygnus.com
Subject: Re: Request for status on fix for limitations with g77 -fdebug_kludge option
Date: Tue, 23 May 2000 18:58:00 -0000
Message-id: <392B36FA.67079BC8@cygnus.com>
References: <002d01bfc4b8$b0343020$1b2731cc@FWB.SAIC.Com>
X-SW-Source: 2000-05/msg00119.html
Content-length: 1036
Larry Cohen wrote:
>
> To Whom It May Concern;
>
> I have recently downloaded and installed gcc-2.95.2 and gdb-5.0 packages
> for the purposes of compiling and running FORTRAN-77 programs. The gcc
> package documentation states that gdb is currently incapable of printing
> out the values of variables that are part of COMMON BLOCK storage and
> that rudimentary COMMON BLOCK variable information could be retrieved
> within gdb by invoking the -fdebug-kludge option during the g77 compile
> process. Also, the documentation states that this limitation in
> printing out the explicit value of a COMMON BLOCK variable will be fixed
> in some future release of gcc and gdb. Would you please send me any
> information about when these future gcc and gdb releases (that print out
> the value of a COMMON BLOCK variable) will occur.
FYI,
At present there is no active Fortran GDB maintainer and effectivly zero
activity on GDB's support for fortran :-(
Definitly an oportunity in the making for anyone interested.
Andrew
From guy@netapp.com Tue May 23 21:22:00 2000
From: Guy Harris <guy@netapp.com>
To: gdb@sourceware.cygnus.com
Subject: On Digital UNIX, "continue" doesn't continue correctly if a signal isdelivered
Date: Tue, 23 May 2000 21:22:00 -0000
Message-id: <200005240422.VAA19399@tooting>
X-SW-Source: 2000-05/msg00120.html
Content-length: 4264
On Digital UNIX/Alpha, we have a program that has an interval timer set
up to continuously deliver signals; with GDB 4.18, we find that if you
stop at a breakpoint, and then try to continue from that breakpoint, it
doesn't continue - instead, it stops again at the same breakpoint.
The same thing happens with the GDB that was in the CVS tree as of a
short while ago.
The problem appears to be that various tests in "wait_for_inferior()",
which test whether the current SP is for a frame closer to the top of
the stack than the frame for "step_sp" (or "step_sp - 16") fail, because
"step_sp" hasn't been set. When continuing from the breakpoint (with
the PRSTEP flag set in the "pr_flags" field of the structure passed to
PIOCRUN, so that it executes only one instruction), it stops in
"__sigtramp", as a SIGALRM was delivered to the process in the interval
since the breakpoint trap; however, GDB doesn't realize that it's in the
signal trampoline, and doesn't properly continue, so that when it next
gets a breakpoint trap after returning from the signal, as it presumably
re-executes the breakpoint instruction, it doesn't realize that it
should drive on, and it just stops.
"step_sp" gets set by "step_1()", "step_once()", and
"until_next_command()", presumably because all those routines call
"proceed()" with "step" set; however, "step_sp" isn't set by
"continue_command()" or any routine between "continue_command()" and
"proceed()", presumably because "proceed()" isn't called with "step" set
in that code path.
However, "proceed()" will be single-stepping, because we're resuming
from a breakpoint, and we need to step over the instruction at which the
breakpoint was placed and then put the breakpoint back, as per:
if (addr == (CORE_ADDR) -1)
{
/* If there is a breakpoint at the address we will resume at,
step one instruction before inserting breakpoints
so that we do not stop right away (and report a second
hit at this breakpoint). */
if (read_pc () == stop_pc && breakpoint_here_p (read_pc ()))
oneproc = 1;
in "proceed()".
Making "proceed()" set "step_frame_address" and "step_sp" if "oneproc"
is set but "step" isn't set appears to fix the problem:
Index: gdb/infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.14
diff -c -r1.14 gdb/infrun.c
*** gdb/infrun.c 2000/05/22 09:02:23 1.14
--- gdb/infrun.c 2000/05/24 03:44:38
***************
*** 1040,1048 ****
#endif /* HP_OS_BUG */
if (oneproc)
! /* We will get a trace trap after one instruction.
! Continue it automatically and insert breakpoints then. */
! trap_expected = 1;
else
{
int temp = insert_breakpoints ();
--- 1040,1058 ----
#endif /* HP_OS_BUG */
if (oneproc)
! {
! /* We will get a trace trap after one instruction.
! Continue it automatically and insert breakpoints then. */
! trap_expected = 1;
!
! /* Oh, and if we weren't explicitly told to single-step, our
! caller may not have updated "step_sp", so do it ourselves. */
! if (!step)
! {
! step_frame_address = FRAME_FP (get_current_frame ());
! step_sp = read_sp ();
! }
! }
else
{
int temp = insert_breakpoints ();
Whether this is the right way to fix this is another matter. (For
example, perhaps "proceed()" should always set "step_frame_address" and
"step_sp" if it will be passing a non-zero value as the first argument
to "resume()", and the routines in "gdb/infcmd.c" that set them should
leave it up to "proceed()" to do so.)
I've attached a small sample program which exhibits the problem; if run
with "clock" as an argument, it sets up a timer to repeatedly deliver
SIGALRM, and if you set a breakpoint on "procedure()", run the program,
and then type "continue", it will stop again in "procedure()" without
printing "Hello", indicating that it hasn't continued from the
breakpoint.
However, if run with "noclock" as an argument, so that it doesn't
repeatedly get SIGALRM, it *will* print "Hello" before stopping again at
"procedure()".
Applying the patch above makes "continue" behave correctly regardless of
whether the program was run with "clock" or "noclock".
From kettenis@wins.uva.nl Wed May 24 01:34:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ldm@ilog.fr, chrisd@reservoir.com, wim.delvaux@desc.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: bug in gdb-5.0 & shared libraries on Solaris 7
Date: Wed, 24 May 2000 01:34:00 -0000
Message-id: <200005240834.e4O8Y6c00547@delius.kettenis.local>
References: <00052401214900.31315@buro> <m3d7mch3zq.fsf@namur.ilog.fr>
X-SW-Source: 2000-05/msg00121.html
Content-length: 536
Wow, three bug reports for the same problem in one day! We should
probably make fixing this a real priority :-).
Anyway, thanks for reporting.
The following patch will fix the problems with setting breakpoints in
dynamically loaded objects:
http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00230.html
This patch isn't checked in yet (ping Michael/JimB), but I hope this
will be in the next GDB release.
There should really be a test in the testsuite for this problem, since
it keeps coming up :-(. Any volunteers?
Mark
From moene@knmi.nl Wed May 24 02:54:00 2000
From: Toon Moene <moene@knmi.nl>
To: gdb@sourceware.cygnus.com
Subject: Re: Request for status on fix for limitations with g77 -fdebug_kludge option
Date: Wed, 24 May 2000 02:54:00 -0000
Message-id: <392BA6A9.ACE682F@knmi.nl>
X-SW-Source: 2000-05/msg00122.html
Content-length: 969
Andrew Cagney wrote:
>Larry Cohen wrote:
>> The gcc
>> package documentation states that gdb is currently incapable of printing
>> out the values of variables that are part of COMMON BLOCK storage and
>> that rudimentary COMMON BLOCK variable information could be retrieved
>> within gdb by invoking the -fdebug-kludge option during the g77 compile
>> process.
> At present there is no active Fortran GDB maintainer and effectivly
> zero activity on GDB's support for fortran :-(
While this is true, to the best of my knowledge the issue with printing
COMMON BLOCK items in gdb has been solved (it was a limitation of the
way g77 wrote debug information).
The solution is in the CVS mainline of GCC. Pick any recent snapshot of
GCC if you can't use CVS and see if using just -g solves your problem.
--
Toon Moene, KNMI, PO Box 201, 3730 AE De Bilt, The Netherlands.
Tel. +31302206443, Fax +31302210407, e-mail moene@knmi.nl
URL: http://www.knmi.nl/hirlam
From kevinb@cygnus.com Wed May 24 09:55:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb@sourceware.cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: PARAMS removal this weekend
Date: Wed, 24 May 2000 09:55:00 -0000
Message-id: <1000524165459.ZM30150@ocotillo.lan>
X-SW-Source: 2000-05/msg00123.html
Content-length: 1030
Earlier this week, I posted a patch for removing most occurrences of
PARAMS from the gdb sources. See:
http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00330.html
I have seen no objections to this patch and Andrew has suggested that
I specify a date and time for when this patch goes in.
So at 5:00 pm MST of Saturday, May 27 (which is midnight GMT on Sunday),
I'll tag the repository, do the PARAMS removal on the gdb directory,
and tag it again. I will use gdb-pre-params-removal-2000-05-28 and
gdb-post-params-removal-2000-05-28 for the tags. (I'm not sure how
long it will take to do all of this, but I wouldn't be surprised if
it were a couple of hours.)
Rather than relying on the patch posted earlier this week, I'll be
using a script to do the actual PARAMS removal. The script and some
additional commentary may be found at
http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00331.html
If you have any concerns about the PARAMS removal activity, please
let me know as soon as possible.
Kevin
From kettenis@wins.uva.nl Wed May 24 15:55:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: obrien@FreeBSD.org
Cc: ac131313@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: GDB & FreeBSD
Date: Wed, 24 May 2000 15:55:00 -0000
Message-id: <200005242255.e4OMtdm00475@delius.kettenis.local>
References: <200005211217.e4LCHPv00623@delius.kettenis.local> <3929EC4C.AD7E0620@cygnus.com> <200005231142.e4NBgjU00165@delius.kettenis.local> <20000523091639.D22706@dragon.nuxi.com>
X-SW-Source: 2000-05/msg00124.html
Content-length: 1546
Date: Tue, 23 May 2000 09:16:39 -0700
From: "David O'Brien" <obrien@FreeBSD.org>
On Tue, May 23, 2000 at 01:42:45PM +0200, Mark Kettenis wrote:
> I be able to cook something up that should work on all i386 BSD's with
The thust shouldn't be viewed as working on all i386 BSD's, but all
4.4BSD derived systems. FreeBSD/Alpha is very import to me also.
Most of the work I did is specifically related to i386-specific
things, so it doesn't help FreeBSD/Alphe very much :-(.
> I'd check it in along with a TODO entry mentioning the need to access
> how hard it is to ``fix'' 1.x.
I can offer a 1.x install CDROM, but I don't know of any one still
running a FreeBSD 1.x box.
It's probably not worth it. People still using FreeBSD 1.x, can use
older versions of GDB instead.
> OK, I'll do that for the code that I have right now (which should work
> on FreeBSD 2.2 and up) and then see if I can revive the support for
> older FreeBSD's after that.
My concern is for FreeBSD 3.0+ (ie. ELF). If support for FreeBSD 2.x had
to be dropped, it would not bother me. I'd like to have the current
systems supported; and those of the future (again ELF).
If I can be of any help providing access to FreeBSD 4-STABLE (which will
become 4.1 RELEASE) or 5-CURRENT systems, please let me know.
Well, testing on some other FreeBSD releases besides 3.4 wouldn't
hurt. If no-one volunteers, setting me up with an account on such a
system would probably lead to some test-runs on it :-).
Mark
From ac131313@cygnus.com Wed May 24 19:15:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: PARAMS removal this weekend
Date: Wed, 24 May 2000 19:15:00 -0000
Message-id: <392C8C8E.DE480348@cygnus.com>
References: <1000524165459.ZM30150@ocotillo.lan>
X-SW-Source: 2000-05/msg00125.html
Content-length: 812
Kevin Buettner wrote:
> So at 5:00 pm MST of Saturday, May 27 (which is midnight GMT on Sunday),
> I'll tag the repository, do the PARAMS removal on the gdb directory,
> and tag it again. I will use gdb-pre-params-removal-2000-05-28 and
> gdb-post-params-removal-2000-05-28 for the tags. (I'm not sure how
> long it will take to do all of this, but I wouldn't be surprised if
> it were a couple of hours.)
Sounds like then it is.
> Rather than relying on the patch posted earlier this week, I'll be
> using a script to do the actual PARAMS removal. The script and some
> additional commentary may be found at
Yes.
BTW, the best way for people to avoid being hurt by this is to mount a
pre-emptive strike - eliminate PARAMS from your code before Kevin comes
through on the script on the weekend.
Andrew
From donnte@microsoft.com Thu May 25 01:28:00 2000
From: Donn Terry <donnte@microsoft.com>
To: 'Mark Mitchell' <mark@codesourcery.com>
Cc: kettenis@wins.uva.nl, Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: RE: Suggested (easier) fix to ... RE: Regressions problem (200 failures)
Date: Thu, 25 May 2000 01:28:00 -0000
Message-id: <309F4FC4705DC844987051A517E9E39B09D1A9@red-pt-02.redmond.corp.microsoft.com>
X-SW-Source: 2000-05/msg00126.html
Content-length: 1556
I can't answer why any better than the author of the change
that started all this ;-) .
> 2000-02-17 Mark Mitchell <mark@codesourcery.com>
>
> * function.c (thread_prologue_and_epilogue_insns): Put a line note
> after the prologue.
My suspicion is that there were situations where the "first statement"
breakpoint wasn't happening correctly, but I don't know details beyond
this.
Agreed, it only affects a subset of all gcc/gdb implementations, which
clearly
explains why everyone wasn't seeing it.
Donn
> -----Original Message-----
> From: Mark Mitchell [ mailto:mark@codesourcery.com ]
> Sent: Tuesday, May 23, 2000 1:07 AM
> To: Donn Terry
> Cc: kettenis@wins.uva.nl;
> Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE;
> kingdon@redhat.com; gdb@sourceware.cygnus.com
> Subject: RE: Suggested (easier) fix to ... RE: Regressions
> problem (200
> fa ilures)
>
>
> >>>>> "Donn" == Donn Terry <donnte@microsoft.com> writes:
>
> Donn> Remember this one? I finally found time (or rather
> Donn> desperation :-) ) to look at it more closely.
>
> The analysis sounds good. So, this bug should only affect platforms
> that don't define HAS_INIT_SECTION; platforms that, for example, use
> ELF .init/.fini sections won't run into this issue.
>
> Why are we emitting a line note at the end of the prologue? (And
> thus before the call to __main?) Couldn't we wait until the first
> real statement?
>
> --
> Mark Mitchell mark@codesourcery.com
> CodeSourcery, LLC http://www.codesourcery.com
>
From mark@codesourcery.com Thu May 25 08:38:00 2000
From: Mark Mitchell <mark@codesourcery.com>
To: donnte@microsoft.com
Cc: kettenis@wins.uva.nl, Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: RE: Suggested (easier) fix to ... RE: Regressions problem(200 fa ilures)
Date: Thu, 25 May 2000 08:38:00 -0000
Message-id: <20000525084647W.mitchell@codesourcery.com>
References: <309F4FC4705DC844987051A517E9E39B09D1A9@red-pt-02.redmond.corp.microsoft.com>
X-SW-Source: 2000-05/msg00127.html
Content-length: 474
>>>>> "Donn" == Donn Terry <donnte@microsoft.com> writes:
Donn> I can't answer why any better than the author of the change
Donn> that started all this ;-) .
Touche.
OK, now I understand the problem -- thanks to you. I'll look back at
why I did what I did -- and then see if I can figure out how to fix
it.
Thanks for bearing with me on this.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
From mgalgoci@redhat.com Thu May 25 11:41:00 2000
From: Matt Galgoci <mgalgoci@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: [spolk@cygnus.com: Re: [smooge@redhat.com: helping the debian people]]
Date: Thu, 25 May 2000 11:41:00 -0000
Message-id: <20000525144136.B5227@redhat.com>
X-SW-Source: 2000-05/msg00128.html
Content-length: 2293
Would one of you folks, in your copius spare time ;-), please look
into this. THanks,
--Matt Galgoci
----- Forwarded message from Syd Polk <spolk@cygnus.com> -----
Date: Thu, 25 May 2000 11:01:57 -0700
From: Syd Polk <spolk@cygnus.com>
To: mgalgoci@redhat.com
CC: spolk@redhat.com
Subject: Re: [smooge@redhat.com: helping the debian people]
I would send mail to gdb@sourceware.cygnus.com or gdb-local@cygnus.com.
Matt Galgoci wrote:
>
> FYI.
>
> ----- Forwarded message from Stephen John Smoogen <smooge@redhat.com> -----
>
> Date: Wed, 24 May 2000 22:14:41 -0400 (EDT)
> From: Stephen John Smoogen <smooge@redhat.com>
> To: Matt Galgoci <mgalgoci@redhat.com>
> Subject: helping the debian people
>
> http://www.debian.org/Lists-Archives/debian-devel-announce-0005/msg00008.html
>
> Package: gdb (debian/main)
> Maintainer: Vincent Renardias <vincent@debian.org>
> [HELP] Fix needed. (RB)
> 58450 gdb: Won't compile on PowerPC
> 62081 Looking for gdb-4.18-objc patches....
>
> Stephen J Smoogen
> Web Support Peon
> Red Hat Inc
>
> ----- End forwarded message -----
>
> --
> Matthew J. Galgoci <mgalgoci@redhat.com>
> Key fingerprint = 46C1 B1EB 0BE9 E398 7CC3 E788 007D 4FF9 18C2 42C0
>
> "Take a shower. I can smell you across the vpn."
wrote:
>
> FYI.
>
> ----- Forwarded message from Stephen John Smoogen <smooge@redhat.com> -----
>
> Date: Wed, 24 May 2000 22:14:41 -0400 (EDT)
> From: Stephen John Smoogen <smooge@redhat.com>
> To: Matt Galgoci <mgalgoci@redhat.com>
> Subject: helping the debian people
>
> http://www.debian.org/Lists-Archives/debian-devel-announce-0005/msg00008.html
>
> Package: gdb (debian/main)
> Maintainer: Vincent Renardias <vincent@debian.org>
> [HELP] Fix needed. (RB)
> 58450 gdb: Won't compile on PowerPC
> 62081 Looking for gdb-4.18-objc patches....
>
> Stephen J Smoogen
> Web Support Peon
> Red Hat Inc
>
> ----- End forwarded message -----
>
> --
> Matthew J. Galgoci <mgalgoci@redhat.com>
> Key fingerprint = 46C1 B1EB 0BE9 E398 7CC3 E788 007D 4FF9 18C2 42C0
>
> "Take a shower. I can smell you across the vpn."
----- End forwarded message -----
--
Matthew J. Galgoci <mgalgoci@redhat.com>
Key fingerprint = 46C1 B1EB 0BE9 E398 7CC3 E788 007D 4FF9 18C2 42C0
"Take a shower. I can smell you across the vpn."
From donnte@microsoft.com Thu May 25 20:44:00 2000
From: Donn Terry <donnte@microsoft.com>
To: Mark Mitchell <mark@codesourcery.com>, rth@cygnus.com
Cc: kettenis@wins.uva.nl, Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: RE: Suggested (easier) fix to ... RE: Regressions problem (200 failures)
Date: Thu, 25 May 2000 20:44:00 -0000
Message-id: <309F4FC4705DC844987051A517E9E39B16EEF6@red-pt-02.redmond.corp.microsoft.com>
X-SW-Source: 2000-05/msg00129.html
Content-length: 10047
Mark:
I just tried to rebuild with my interim patch in place, and found that RTH
had completely
rewritten the area. If I don't run into too many ICEs during the rebuild of
the compiler
suite (it comes and goes regularly depending on who has patched what) I'll
know
something tomorrow (Fri) about what effect his changes had on this, but from
looking at the code, it may have the same problem. (I'm skipping my patch
for the moment.)
Richard: quick synopsis: the code in this area doesn't (didn't?) take into
account the
possibility of there being a call to __main, with the consequence that the
initial
breakpoint for main ends up at the {, rather than at the first statement
*if* the
call to __main is generated.
Donn
-----Original Message-----
From: Mark Mitchell
Sent: Thu 5/25/2000 8:46 AM
To: Donn Terry
Cc: kettenis@wins.uva.nl; Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE;
kingdon@redhat.com; gdb@sourceware.cygnus.com
Subject: RE: Suggested (easier) fix to ... RE: Regressions problem (200 fa
ilures)
>>>>> "Donn" == Donn Terry <donnte@microsoft.com> writes:
Donn> I can't answer why any better than the author of the change
Donn> that started all this ;-) .
Touche.
OK, now I understand the problem -- thanks to you. I'll look back at
why I did what I did -- and then see if I can figure out how to fix
it.
Thanks for bearing with me on this.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
< http://www.codesourcery.com >
begin 600 winmail.dat
M>)\^(@8#`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$%@`,`
M#@```-`'!0`9`!0`%P`:``0`/@$!"8`!`"$````P-#-$.30S0C`Y045!1C0S
M035#-#5&-C(R-T$R-$,R,@`A!P$@@`,`#@```-`'!0`9`!0`*@`%``0`/`$!
M#8`$``(````"``(``0.0!@!D%P``.P```$``.0"*4C_!P<:_`1\`,4`!````
M#@```#0`.0`P`#<`-@`Y```````#`!I``````!\`,$`!````#@```#0`.0`P
M`#<`-@`Y```````#`!E``````!\`20`!````E````%(`10`Z`"``4P!U`&<`
M9P!E`',`=`!E`&0`(``H`&4`80!S`&D`90!R`"D`(`!F`&D`>``@`'0`;P`@
M`"X`+@`N`"``4@!%`#H`(`!2`&4`9P!R`&4`<P!S`&D`;P!N`',`(`!P`'(`
M;P!B`&P`90!M`"``*``R`#``,``@`&8`80`)`&D`;`!U`'(`90!S`"D```!`
M`$X`@$WO;F#&OP$"`5L``0```$$`````````@2L?I+ZC$!F=;@#=`0]4`@``
M``!-87)K($UI=&-H96QL`%--5%``;6%R:T!C;V1E<V]U<F-E<GDN8V]M````
M`!\`9@`!````"@```%,`30!4`%```````!\`9P`!````+````&T`80!R`&L`
M0`!C`&\`9`!E`',`;P!U`'(`8P!E`'(`>0`N`&,`;P!M````'P!:``$````<
M````30!A`'(`:P`@`$T`:0!T`&,`:`!E`&P`;````!\`,D`!````+````&T`
M80!R`&L`0`!C`&\`9`!E`',`;P!U`'(`8P!E`'(`>0`N`&,`;P!M`````@%<
M``$````;````4TU44#I-05)+0$-/1$533U520T5262Y#3TT```,`'4``````
M`@%>``$```!!`````````($K'Z2^HQ`9G6X`W0$/5`(`````36%R:R!-:71C
M:&5L;`!33510`&UA<FM`8V]D97-O=7)C97)Y+F-O;0`````?`&@``0````H`
M``!3`$T`5`!0```````?`&D``0```"P```!M`&$`<@!K`$``8P!O`&0`90!S
M`&\`=0!R`&,`90!R`'D`+@!C`&\`;0```!\`70`!````'````$T`80!R`&L`
M(`!-`&D`=`!C`&@`90!L`&P````?`#-``0```"P```!M`&$`<@!K`$``8P!O
M`&0`90!S`&\`=0!R`&,`90!R`'D`+@!C`&\`;0````(!7P`!````&P```%--
M5%`Z34%22T!#3T1%4T]54D-%4EDN0T]-```#`!Y``````!\`<``!````C```
M`%,`=0!G`&<`90!S`'0`90!D`"``*`!E`&$`<P!I`&4`<@`I`"``9@!I`'@`
M(`!T`&\`(``N`"X`+@`@`%(`10`Z`"``4@!E`&<`<@!E`',`<P!I`&\`;@!S
M`"``<`!R`&\`8@!L`&4`;0`@`"@`,@`P`#``(`!F`&$`"0!I`&P`=0!R`&4`
M<P`I`````@%Q``$````;`````;_&7X8^4#+W%AL42P*QW/TNPFGG?@`83#?#
M`!\`<P`!````Y@```&L`90!T`'0`90!N`&D`<P!``'<`:0!N`',`+@!U`'8`
M80`N`&X`;``[`"``4`!E`'0`90!R`"X`4P!C`&@`80!U`&4`<@!``%(`90!G
M`&4`;@!T`"X`10`M`%0`90!C`&@`;@!I`&L`+@!4`%4`+0!-`'4`90!N`&,`
M:`!E`&X`+@!$`$4`.P`@`&L`:0!N`&<`9`!O`&X`0`!R`&4`9`!H`&$`=``N
M`&,`;P!M`#L`(`!G`&0`8@!``',`;P!U`'(`8P!E`'<`80!R`&4`+@!C`'D`
M9P!N`'4`<P`N`&,`;P!M```````?`'0``0```!8```!$`&\`;@!N`"``5`!E
M`'(`<@!Y```````"`0D0`0```$@,``!$#```C"X``$Q:1G6-5J)$`P`*`')C
M<&<Q,C6",@-#:'1M;#$#,#\!`P'W"H`"I`/C`@!C:,$*P'-E=#`@!Q,"@/\0
M`P!0!%8(50>R$=4.40,!W1#7,@8`!L,1U3,$1A#9;Q+K$>,([PGW.QC/#C`U
M.Q'2#&!C`%`+"0%D,S:3$6`+I30@$`(J7`ZRO0&09Q3P"J,1XQWH-!3P`#PA
M1$]#5%E0`$4@2%1-3"!0`%5"3$E#("(M("\O5S-#(8!$5")$()0S+C(A@$5.
MG"(^'NT>CR/!,3@?\&\@HB,/)!\FD#,=@"5P17Q!1"7-#O$F[REO)/0V00[P
M/$U%5$$'L$$Q+&`](D<)\`20871%!;`B$M!/3E0BT%03+/`%X45X$/%N9V4]
M!E)V$S$O00"0`B`@-M`N,"XT'-`X,#`B_A,JSR4#-S<?\%1)5!1,127.-`[P
M4D4Z208`=6<NX'-T"8`@&"AE80"0!)`I(&;(:7@@+7`@+C:@-+.\4F4)P000
M+\$$('`#8#D"8&5M-9`!T!%@9F%=#((@`Q`(<`>0*21N-?T?\"\S3S%_)D4T
MD3JP*$\+)I\^A#418#Q"3T1`62!D:7(]/J!RGSWP/F,`(0,P00%D;P#@\T$!
M"K%<<1BP00$0\`,P'T%E$6`^&QSQ/Q]G.3;Q'_!$259!.0``0W<^.2PV-$:O
M0\)-"L!K.G\^.0'`04<*HD%'"G$D?##_*!$AX$9[3`A#_T4/1A]'+Q=(/U*K
M/ALX'8`F;F+,<W`"@$%8)V$!0%+O_TKO2_]-#TX?53]0/U%/5'^#4V]@;R!)
M(&IU-5"?-F`(@36`-G$8T&)U`Q#+-8`#\'1#0&UY.1`",/<&<3A`"K!T0S$+
M@#?0"V!P8V4L(`!P-8`"$'7/9S%E0"U@!_!42!V<'8!O7H01`#6`!:!M"U`1
M0&7\;'E8?UF/6I];KUR_7<^_7M]?[V#_8@]O%QC0=P40OP)`"?!GL2[P"L`U
ML"Y5GS]6KU>Z8Y!!P&.@0B!N)_T%0')G@&62-H`M<#:``X'K98`A,$4$(&0(
M<2[0=D/W:%]PLF2F;T'`=E)IX@,0_PBB:J]KOVS/;=]N[V__<0_O<A]S+W0_
MA!5S9-`U8#60SV4P:=('D6<B9V\'D1C0-&=U"V!R:F!`L&5PSPGP0,!\,2_1
M=V@V@!$`/S?!9C(U<8V0+6`V$$DG#FP#('ROA9)K;F]W_W]O@'^!CX*?@Z^$
MOX7/AM__A^^(_XH(BT%E0'PC`W`%L/,#8`?@*$8%$#80`:`(8/L%0(Z2(`$1
M!9`%0)Q0!"#?+J0$(&FB+]&<07-G`&3`_P5`CT^7`@-2D-^1[Y+_E`__E1^6
M+Y<_F$^97YIOIJ]W;^=X?ZT"&&!O:WPB9^%^I/\!`&<`BP$`P&6`$0`O0'9#
M?'-A!X`WUG;?KD]X_"BOCO`X0*"/J$)SL%!P?Q#_?#%E<68D`A`%P'92!&`'
M@/D","XIHA^C+Z0_I4^F7_^G;ZA_J8^JGZNOOH^SS[3?_U@_NL^[W[SOO?^_
M#\`?P2^WPC_#3]!+4@W@$0%D-.!2<6308VN*@'F0H'#]`)!S-."PUF9RG^)V
M@WH1JP>0>D(H0,!D>D$_-A#]`9!KU3(V<;:/SC(`T`6@_V>`L+/(#\D?RB_+
M/\Q/S5^?SF_/?]"/T9_>=W!O-W%^8@,093!E@'YT&-"@,&6?L&-IT`=``R`V
M<5]?`,#?"X!G`&4C?J0`@&73P`GP_V;@9[1\;VDF"X!E,`<QV>__VO_<#]T?
MWB_?/^!/X5_B;^OC?_`78G:A:^409:&XXT_G@IXP9S`$('5PL)9<_GMG`"U1
MYA%GL@.@L*4V,/\1(`5`-5`M8#@PN:'IO_&C^BH&D"K9K^Q?[6_N?^^/__"?
M\:_RO_//]-\%:^;L.1#OBW`NX"TS&.`N_2_^/_]/_P!?`6\"?P./!)\%KP:_
M#J__Q:_&O\?/"N\+_PT/#A\/+U\0/Q%/$E\3;R!K1"_0;O\8+QD_&D\;7QQO
M'7\>CT!@@$Q/0TM154\M\!M`MOJA>3@@+C%!4D<`24XM4DE'2%3Q-.`P<'@P
MH1:X*;$HLO]"94,#0L%#7RD?,]MYH2GO'Q^/()\AKS`(0O!I,S81,(TQ-#@F
M\$9/3E)4BH!I>BR`,C1[9JQS,C%Q,!<M._)/=>#^9_?`YO!*`(M@LG`)<#OS
MM3A=,2KB4D$[]\!E,*#O,`\5MRL`-'MB+_F=0+F`^CHS/#(F\4&Z*`E*`TH`
M_XL`CD&/'S&/%>0S#CY_/X_W0)]!KTP(4_L10Y]$KWE'@%1H=2`U+S)2@4(P
M4N`@.#HT-!!!?DT]GTJO2[],STW?5C54?F]/GU"O>4<C4E(P?T!R_WN`1R](
M/TE/5%]5;U9_5X_Y0II#8UE_6H]Y1]=@=@*-GL!`Y^#HD"YU=G;`N&YL.US/
M7=]>Y5"<,!E_0"Y3GO'HT')`4G.,,+FB12U<<(Y`ZR!K8"Y452U-Z-)V8&ZX
M+D1%:1"P4GHA0(P@^F2.H2Z+,6D?:B]>UF[0W&)`G`!\`.D`=]71;X#P>6=N
M=6B0BS%3GV!?CV%O8G]CCT[F=6)JGG%G92]F/T6W4D73H'FP9_^?,0G1BN#5
M\.5`?T#7(/I0WG@(DF_O</]>]"Z!,'S#_VR1C"#E,>B!LK:*X%+1]U#OU@#E
M<'+`BV`I=`]U'W8OKX0?A2^&/R96-301+SF"_WMO%]\D7R5O)G^+CS"/?Z_W
M,J\V-9`04"W?-UDVSS??3SCO.?\[#15/9W06F3[_F]^<[YW_GP^@'Z$OHC^C
M3Q>D7Z5O1?,B(U(B(#W>/5P??P^`'ZOO)I.P%IF./*88;N'[(&5`;=-`>[+0
M<J!F;W.M+Z?/1<9W_SQ0"=#4D(GOBO]%BHV?CJ7_E:^F/XTDD!&5<9'?J[^3
M__^5#Y>OF+^9SYK?N6\5SQ;?_\0?Q2_&/\=/R%\7>2-#RA\[L@]%QDD(0=9B
M^;!S=_GY87=HY;#YL.6PYF!G\?_Y=:JOO%^LQ.@R;$#I,/=Q_^74Z&#YH0EP
MM`^U'T6*AN__A_^)#\#_P@_#'\GORO_)+__?K^"_X<_BW^/OS*_-O\[/_](/
MTQ_4)_AQ^K&W,'V!"&/2:`E!.RU^("[6']<O_[8OMS^X3^2ONF^[?[R/O9^_
MOJ^_O]O_W0_>'UCV=4;!_^\_\$_Q7_)O\W_TC_6?]J__][_XS_G?^N_[__T/
M_A\%A8!/2RP@;F]WS]'X=6YDJE#MX1$`U6."=ML]<='":X)0?H%Y<K#__'/F
M'^<O22=&_P@OK)=LQ&]O1G!B86-&<&]@_P`/`1_8/]E/VE\%;PU/#E__WIW0
MTL_@*\!]D-#0[;$CI*<]<1%EJB!S9=2P::[@O\_@%K\7SZS$T`%^,6>#D?O5
M,-3@(-4`$+!^@7Y!&?__&P\<'QTO'C\?3R!?(6_>G?]&H/__*Q\"'P,O!#\O
M3P9?_P=O"'\)CPJ?"Z\O[S#_,@_[6.82I&;5$=%0/`!NL;.`\4:@:"!M*1&J
M(.ZB,Z__-+\USS;?-^\X_SH/.Q\\+_\]/SY//U]`;T%_0H]+M22P_T8_1T\L
M/RU/+E]+GU-_5(]]WIU-3H`9L"8/3H^LQ$W_L[!N$1:`$W\4C^2/8[]DS_]E
MWV;O9_]I#VH?:R]L/VU/_VY?;V]P?W&/<I]SKW2_=<__=M]W[WC_>@]['WPO
M?3]^3_]_7X!O@7^"CX.?A*^%OX;/_X??B.^)_XL/C!^-+XX_CT]_D%^1;Y)_
MYVM@;V%_K,1MO6`A0+#`$1"P<"CP8ZI0_GFPOU=_6(]9GUJO6[]<S]==WU[O
MH,!#FA%3FE40<,>7/YA/K,1,3$.43Y5?_Y./J%^I;ZI_JX^LGZVOKK__K\^P
MW['OLO^T#[4?MB^W/_^X3[E?NF^[?[R/O9^^K[^__\#/P=_"[\/_Q0_&'\<O
MR#__R4_*7\MOEC^E;Z9_*#/-;HP\02E@*0!F/2+.X,!T<#HO+W?4T)K!59HL
M(J*\:6,P9$[B9@?7()_P$4![2%E01<!23$E.2R#47]5J/'U]HV'7(!$P3U!<
M8_!F,5QU%I#,R-B_FFBOG)]24MX/H,TY30)!35W_F]^<[]!OT7\H,TD?2B]+
M/PM,3^&N,%#A+T),3X!#2U%53U1%XS]OZ>]./^\_3P<UH='LH$^\1%E-7>L0
M\/]/<3?BP5!(5$U,HK!]];`#`"8```````,`-@``````'P!'$`$````>````
M;0!E`',`<P!A`&<`90`O`'(`9@!C`#@`,@`R```````#`-X_Z?T```,`\3\)
M!````P#]/^0$```+`/(0`0````L`]!``````"P#U$``````+`/80`````!\`
M\Q`!````H@```%(`10`E`#,`00`@`%,`=0!G`&<`90!S`'0`90!D`"``*`!E
M`&$`<P!I`&4`<@`I`"``9@!I`'@`(`!T`&\`(``N`"X`+@`@`%(`10`E`#,`
M00`@`%(`90!G`'(`90!S`',`:0!O`&X`<P`@`'``<@!O`&(`;`!E`&T`(``H
M`#(`,``P`"``9@!A`&D`;`!U`'(`90!S`"D`+@!%`$T`3````````@%'``$`
M```Q````8SU54SMA/4U#23MP/6US9G0[;#U2140M4%0M,#(M,#`P-3(V,#,R
M,S(V6BTR.3<R``````(!^3\!````40````````#<IT#(P$(0&K2Y"``K+^&"
M`0`````````O3SU-24-23U-/1E0O3U4]3D]25$A!345224-!+T-./5)%0TE0
M245.5%,O0TX]-#DP-S8Y`````!\`^#\!````%@```$0`;P!N`&X`(`!4`&4`
M<@!R`'D``````!\`.$`!````#@```#0`.0`P`#<`-@`Y```````"`?L_`0``
M`%$`````````W*=`R,!"$!JTN0@`*R_A@@$`````````+T\]34E#4D]33T94
M+T]5/4Y/4E1(04U%4DE#02]#3CU214-)4$E%3E13+T-./30Y,#<V.0`````?
M`/H_`0```!8```!$`&\`;@!N`"``5`!E`'(`<@!Y```````?`#E``0````X`
M```T`#D`,``W`#8`.0``````0``',+8/';?`QK\!0``(,`:6$%S$QK\!'P`:
M``$````2````20!0`$T`+@!.`$\`5`!%```````?`#<``0```)(```!2`$4`
M.@`@`%,`=0!G`&<`90!S`'0`90!D`"``*`!E`&$`<P!I`&4`<@`I`"``9@!I
M`'@`(`!T`&\`(``N`"X`+@`@`%(`10`Z`"``4@!E`&<`<@!E`',`<P!I`&\`
M;@!S`"``<`!R`&\`8@!L`&4`;0`@`"@`,@`P`#``(`!F`&$`:0!L`'4`<@!E
M`',`*0``````'P`]``$````*````4@!%`#H`(```````'P`=#@$```"*````
M4P!U`&<`9P!E`',`=`!E`&0`(``H`&4`80!S`&D`90!R`"D`(`!F`&D`>``@
M`'0`;P`@`"X`+@`N`"``4@!%`#H`(`!2`&4`9P!R`&4`<P!S`&D`;P!N`',`
M(`!P`'(`;P!B`&P`90!M`"``*``R`#``,``@`&8`80!I`&P`=0!R`&4`<P`I
M```````?`#40`0```)P````\`#,`,``Y`$8`-`!&`$,`-``W`#``-0!$`$,`
M.``T`#0`.0`X`#<`,``U`#$`00`U`#$`-P!%`#D`10`S`#D`0@`Q`#8`10!%
M`$8`-@!``'(`90!D`"T`<`!T`"T`,``R`"X`<@!E`&0`;0!O`&X`9``N`&,`
M;P!R`'``+@!M`&D`8P!R`&\`<P!O`&8`=``N`&,`;P!M`#X````+`"D`````
M``L`(P```````P`&$#3W0:`#``<0H00```,`$!```````P`1$`$````>``@0
M`0```&4```!-05)+.DE*55-45%))14143U)%0E5)3$17251(35E)3E1%4DE-
M4$%40TA)3E!,04-%+$%.1$9/54Y$5$A!5%)42$A!1$-/35!,151%3%E215=2
M251414Y42$5!4D5!249)1$].``````(!?P`!````3@```#PS,#E&-$9#-#<P
M-41#.#0T.3@W,#4Q034Q-T4Y13,Y0C$V145&-D!R960M<'0M,#(N<F5D;6]N
:9"YC;W)P+FUI8W)O<V]F="YC;VT^````_4P=
`
end
From dyp@perchine.com Thu May 25 21:06:00 2000
From: Denis Perchine <dyp@perchine.com>
To: gdb@sourceware.cygnus.com
Subject: GDB shows extra SIGTRAP and then SIGSEGV if continue on linux/glibc 2.1.3
Date: Thu, 25 May 2000 21:06:00 -0000
Message-id: <00052611073508.24471@dyp>
X-SW-Source: 2000-05/msg00130.html
Content-length: 283
Hello all,
Is there any solution for this problem available or planned to be available?
--
Sincerely Yours,
Denis Perchine
----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------
From ac131313@cygnus.com Thu May 25 22:23:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: mgalgoci@redhat.com, Vincent Renardias <vincent@debian.org>
Cc: gdb@sourceware.cygnus.com
Subject: Re: [spolk@cygnus.com: Re: [smooge@redhat.com: helping the debian people]]
Date: Thu, 25 May 2000 22:23:00 -0000
Message-id: <392E09B7.674006C@cygnus.com>
References: <20000525144136.B5227@redhat.com>
X-SW-Source: 2000-05/msg00131.html
Content-length: 792
Matt Galgoci wrote:
> > ----- Forwarded message from Stephen John Smoogen <smooge@redhat.com> -----
> >
> > Date: Wed, 24 May 2000 22:14:41 -0400 (EDT)
> > From: Stephen John Smoogen <smooge@redhat.com>
> > To: Matt Galgoci <mgalgoci@redhat.com>
> > Subject: helping the debian people
> >
> > http://www.debian.org/Lists-Archives/debian-devel-announce-0005/msg00008.html
> >
> > Package: gdb (debian/main)
> > Maintainer: Vincent Renardias <vincent@debian.org>
> > [HELP] Fix needed. (RB)
> > 58450 gdb: Won't compile on PowerPC
> > 62081 Looking for gdb-4.18-objc patches....
Is that GDB 4.18? If it is then the problem isn't suprising. Patches to
support Linux/PPC were only merged into GDB after gdb 4.18 was created.
I would suggest restarting with GDB - 5.0.
enjoy,
Andrew
From vincent@redhat.com Fri May 26 06:04:00 2000
From: Vincent Renardias <vincent@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: mgalgoci@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: [spolk@cygnus.com: Re: [smooge@redhat.com: helping the debian people]]
Date: Fri, 26 May 2000 06:04:00 -0000
Message-id: <Pine.LNX.4.20.0005261301520.16057-100000@v2.ldsol.com>
References: <392E09B7.674006C@cygnus.com>
X-SW-Source: 2000-05/msg00132.html
Content-length: 700
On Fri, 26 May 2000, Andrew Cagney wrote:
> > > http://www.debian.org/Lists-Archives/debian-devel-announce-0005/msg00008.html
> > >
> > > Package: gdb (debian/main)
> > > Maintainer: Vincent Renardias <vincent@debian.org>
> > > [HELP] Fix needed. (RB)
> > > 58450 gdb: Won't compile on PowerPC
> > > 62081 Looking for gdb-4.18-objc patches....
>
> Is that GDB 4.18? If it is then the problem isn't suprising. Patches to
> support Linux/PPC were only merged into GDB after gdb 4.18 was created.
> I would suggest restarting with GDB - 5.0.
Indeed, it was 4.18. I'm going to package 5.0 soon.
Cordialement,
--
Vincent Renardias <vincent@redhat.com> Red Hat France BOFH
^ permalink raw reply [flat|nested] 3+ messages in thread