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 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.



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