From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17410 invoked by alias); 30 Apr 2015 10:31:04 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 17341 invoked by uid 89); 30 Apr 2015 10:31:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 30 Apr 2015 10:31:03 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 06D458EA2C for ; Thu, 30 Apr 2015 10:31:02 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-44.ams2.redhat.com [10.36.112.44]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3UAV0uU012253; Thu, 30 Apr 2015 06:31:01 -0400 Message-ID: <55420463.10400@redhat.com> Date: Thu, 30 Apr 2015 10:31:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: Jan Kratochvil , gdb@sourceware.org Subject: Re: compile: objfiles lifetime UI References: <20150429135735.GA16974@host1.jankratochvil.net> In-Reply-To: <20150429135735.GA16974@host1.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00053.txt.bz2 On 29/04/15 14:57, Jan Kratochvil wrote: > Hi, > > posting first for an approval CLI UI for managing objfiles currently in > inferior for the 'compile' command. > > With each injected code is associated: > * infcall dummy frame - deleted when the code returns or when user interrupts > the code and 'return's from it in CLI. > * objfile - deleted when the dummy frame is deleted > * inferior mmap()ped memory - currently leaked in inferior forever > - prepared in a local patchset: deleted when the objfile is deleted > * inferior malloc()ed memory - only from the posted 'compile print' command > - in the posted 'compile print' command: deleted when the objfile is deleted > > The mmap leak was intentional so that one can do for example: > inferior: > char *str = "foo"; > GDB: > (gdb) compile code str = "bar"; > > Now there should be a way to delete everything by default (so that a loop with > 'compile print' command will not run the inferior out of memory) but to have > a way to keep the memory alive (so that for example strings can be set) or > even to keep the objfile alive (so that for example a callback function can be > set which may crash so that we want to keep DWARF loaded for the callback > function). > I'm not sure we need a UI at all? I suppose I am trying to think of a reason why the user would want to manage an object's life-cycle, and not let GDB dispose of it according to the following rules: * Object files involved in an expression should be discarded after the expression evaluation; * Object files created by the "compile code" command should be discarded after the execution of the injected code; * Object files created by "fast" breakpoints (where the evaluation of whether the inferior should be stopped is determined by the return value of an injected piece of code) should be deleted when the breakpoint is deleted. Of the three examples above, only the last requires the object file to be held for an indefinite time. Note I am not against a user interface, I just want to envision when a user would need to use it. Cheers Phil