From: Phil Muldoon <pmuldoon@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>, gdb@sourceware.org
Subject: Re: compile: objfiles lifetime UI
Date: Thu, 30 Apr 2015 10:31:00 -0000 [thread overview]
Message-ID: <55420463.10400@redhat.com> (raw)
In-Reply-To: <20150429135735.GA16974@host1.jankratochvil.net>
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
next prev parent reply other threads:[~2015-04-30 10:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-29 13:57 Jan Kratochvil
2015-04-30 10:31 ` Phil Muldoon [this message]
2015-04-30 10:53 ` Jan Kratochvil
2015-05-06 12:26 ` Jan Kratochvil
2015-05-07 2:53 ` Alexandre Oliva
2015-05-07 17:06 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55420463.10400@redhat.com \
--to=pmuldoon@redhat.com \
--cc=gdb@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox