This is the mail archive of the
mailing list for the GDB project.
Re: compile: objfiles lifetime UI
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: gdb at sourceware dot org
- Date: Thu, 30 Apr 2015 12:53:49 +0200
- Subject: Re: compile: objfiles lifetime UI
- Authentication-results: sourceware.org; auth=none
- References: <20150429135735 dot GA16974 at host1 dot jankratochvil dot net> <55420463 dot 10400 at redhat dot com>
On Thu, 30 Apr 2015 12:30:59 +0200, Phil Muldoon wrote:
> 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.
What about that 2nd case example of:
(gdb) compile code str = "bar";
That can be also typed as the 1st case:
(gdb) compile print str = "bar"
Obviously "bar" remains the GDB-mmap()ed memory. For C++ one will be able to
similarly assign whole new objects residing in the GDB-mmap()ed memory.
This is all a light variant of the possible far future feature "fix&continue",
that one tries to modify the inferior's behavior some way and continue its