This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v4 11/11] RFC only: compile: Use also inferior munmap
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Phil Muldoon <pmuldoon at redhat dot com>
- Date: Wed, 6 May 2015 21:32:08 +0200
- Subject: Re: [PATCH v4 11/11] RFC only: compile: Use also inferior munmap
- Authentication-results: sourceware.org; auth=none
- References: <20150503140647 dot 18583 dot 2012 dot stgit at host1 dot jankratochvil dot net> <20150503140815 dot 18583 dot 29612 dot stgit at host1 dot jankratochvil dot net> <554A3181 dot 9040903 at redhat dot com>
On Wed, 06 May 2015 17:21:37 +0200, Pedro Alves wrote:
> On 05/03/2015 03:08 PM, Jan Kratochvil wrote:
> > I believe later patches will be needed to introduce full control over keeping
> > vs. discarding the injected module as being discussed in:
> > compile: objfiles lifetime UI
> > https://sourceware.org/ml/gdb/2015-04/msg00051.html
> > Message-ID: <20150429135735.GA16974@host1.jankratochvil.net>
> > This patch at least introduces code which will be needed for the part/cases of
> > really freeing all the resources of an injected module.
> >
> > It is "RFC only" as given the patch as is it regresses GDB functionality.
>
> I don't which parts of this would cause regressions;
For example the existing testsuite case - without its change it would
PASS->FAIL.
> it's helpful
> when an RFC points out what is known to be hacky or patch bits that are known
> to need to change. It's not obvious, at least to me.
One can imagine many cases when the inferior can later reference the injected
object's memory; although I agree for most of the 'print' expressions it will
not happen. Maybe only the C 'char *' case
https://sourceware.org/ml/gdb/2015-04/msg00054.html
is the most visible one, C++ has better memory ownership/management in its
objects.
> That said, I skimmed it and it overall looks good. The stop_registers
> bits looked surprising. My reaction was that I'd think that would be
> something handled around save_infcall_suspend_state/restore_infcall_suspend_state,
> though it's not clear to me.
This was a minimal change how to make this patch working. I agree
'stop_registers' (also) looks as a hack to me, I will therefore try to make
some pre/post cleanup patch if we can get rid of 'stop_registers', I have no
idea.
Thanks,
Jan