This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: compile: objfiles lifetime UI

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]