From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19429 invoked by alias); 18 Aug 2006 12:27:46 -0000 Received: (qmail 19421 invoked by uid 22791); 18 Aug 2006 12:27:45 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Aug 2006 12:27:44 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-205-172.inter.net.il [80.230.205.172]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id FNN00996 (AUTH halo1); Fri, 18 Aug 2006 15:27:40 +0300 (IDT) Date: Fri, 18 Aug 2006 12:27:00 -0000 Message-Id: From: Eli Zaretskii To: Jan Kratochvil CC: gdb@sourceware.org In-reply-to: <20060815142819.GA26405@host0.dyn.jankratochvil.net> (message from Jan Kratochvil on Tue, 15 Aug 2006 16:28:19 +0200) Subject: Re: Debugging through exec() (Linux MAY_FOLLOW_EXEC) Reply-to: Eli Zaretskii References: <20060722123102.GA1936@lace.redhat.com> <20060724190332.GA13612@nevyn.them.org> <20060729185317.GA16200@host0.dyn.jankratochvil.net> <200607312038.k6VKchKj018729@elgar.sibelius.xs4all.nl> <20060805164144.GA23819@host0.dyn.jankratochvil.net> <20060808160113.GC21032@nevyn.them.org> <20060814150628.GA24544@host0.dyn.jankratochvil.net> <20060814213849.GA1433@nevyn.them.org> <20060815142819.GA26405@host0.dyn.jankratochvil.net> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00134.txt.bz2 > Date: Tue, 15 Aug 2006 16:28:19 +0200 > From: Jan Kratochvil > Cc: gdb@sourceware.org > > Currently gdb does not notice `exec' at all - it does not apply the inferior > changes to its debugging information about the inferior. By default in the > point of `exec' it will lose any breakpoints and the execution will continue > without any gdb influence and the program will just finish uncaught. > > If you turn on "catch exec" you will get back the control after `exec' changes > the virtual memory context but gdb will still expect the original executable is > still loaded. All the sources will be displayed for the original program and > breakpoints put to the addresses according to the debuginfo of the original > program, still everything will be messed up as a complately different > executable is already running. Thanks for the explanations, but I seem to be dense today, because I don't get to the cheese yet. Perhaps if you could describe a scenario where the current behavior is inconvenient, and what does your patch change in this respect, I will understand the issues. Please also tell how, if at all, the suggested changes interact with follow-fork mode.