From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27455 invoked by alias); 7 Sep 2006 12:30:42 -0000 Received: (qmail 27447 invoked by uid 22791); 7 Sep 2006 12:30:42 -0000 X-Spam-Check-By: sourceware.org Received: from mail.bfw-online.de (HELO mail.bfw-online.de) (62.245.186.164) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 07 Sep 2006 12:30:38 +0000 Received: from [192.168.222.4] (helo=lar.bfw.de ident=springl) by mail.bfw-online.de with esmtp (Exim 4.51) id 1GLJ1f-0005yE-B6 for gdb-patches@sourceware.org; Thu, 07 Sep 2006 14:30:35 +0200 Date: Thu, 07 Sep 2006 12:30:00 -0000 From: Stephan Springl To: gdb-patches@sourceware.org Subject: fix comment typo Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-555875106-1150433456-1157632231=:22397" X-SA-Exim-Connect-IP: 192.168.222.4 X-SA-Exim-Mail-From: springl-gdb@bfw-online.de X-SA-Exim-Scanned: No (on mail.bfw-online.de); SAEximRunCond expanded to false Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00025.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---555875106-1150433456-1157632231=:22397 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-length: 1196 Hi! while digging into the fact that gdb 6.5 does not close .gdbinit and the=20 child programs binary in the child process before execing, I found a typo. BTW does anyone who is into gdb know how to close the possibly open init=20 file without looking at the whole code? Stephan index 1bfb98b..a95984d 100644 Binary files a/gdb/.fork-child.c.swp and b/gdb/.fork-child.c.swp differ index 8940151..44049dc 100644 --- a/gdb/fork-child.c +++ b/gdb/fork-child.c @@ -277,7 +277,7 @@ #endif (*pre_trace_fun) (); /* Create the child process. Since the child process is going to - exec(3) shortlty afterwards, try to reduce the overhead by + exec(3) shortly afterwards, try to reduce the overhead by calling vfork(2). However, if PRE_TRACE_FUN is non-null, it's likely that this optimization won't work since there's too much work to do between the vfork(2) and the exec(3). This is known -- Stephan Springl BFW Werner V=F6lk GmbH springl-gdb@bfw-online.de Energiemesstechnik & Service +49 89 82917-452 Drosselgasse 5 82166 Gr=E4felfing/M=FCnchen= ---555875106-1150433456-1157632231=:22397--