Re: compile: objfiles lifetime UI

[Alexandre Oliva <aoliva at redhat dot com>]

On May  6, 2015, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:

> On Thu, 30 Apr 2015 12:53:49 +0200, Jan Kratochvil wrote:
>> 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.

> Maybe it would be best if GCC can report whether the compiled code exposes
> address to its internal object outside - such as by such an assignment or by
> passing such a pointer to some external function.  I expect some scan of the
> IR (intermediate representation - RTL/GIMPLE?) would be sufficient.

There is some pointer escaping analysis that could be repurposed to that
end in GCC.  -Wreturn-local-addr is surely not enough to cover assigning
gdb-compile pointers to inferior variables, but a new warning to cover
more general pointer escaping to automatic variables might could be
useful on its own, with a small extension for user expressions for it to
apply to strings as well.

However, it's not clear where to draw the line when a (pointer to a)
string (literal) is passed to some inferior function.  Technically, it
is an escaping pointer, but printf won't save it, whereas add_to_list
will.  So we don't want it to be an error, at most a warning.

But then, wouldn't we be better served by teaching users to use strdup
in gdb-compile snippets when they wish to get strings preserved (and
permanently leaked) in the inferior?  Since we can't tell when it's ok
for a pointer to escape in relatively common and harmless cases (the
printf example above, any C++ function that takes a reference argument,
C++ non-static member functions), I think even a warning would quickly
become annoying due to the number of false positives.

Using memory allocation primitives of the inferior might be cumbersome,
but it will likely be learned fast, given how the failure to use them
would break the inferior.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer