From: Daniel Jacobowitz <drow@mvista.com>
To: "John S. Yates, Jr." <jyates@netezza.com>
Cc: gdb <gdb@sources.redhat.com>
Subject: Re: malloc in inferior
Date: Thu, 29 May 2003 16:09:00 -0000 [thread overview]
Message-ID: <20030529160927.GA11795@nevyn.them.org> (raw)
In-Reply-To: <0ec201c325fb$764554a0$1400a8c0@astral>
On Thu, May 29, 2003 at 12:00:44PM -0400, John S. Yates, Jr. wrote:
>
> From: "Daniel Jacobowitz" <drow@mvista.com>
> To: "John S. Yates, Jr." <jyates@netezza.com>
> Cc: "gdb" <gdb@sources.redhat.com>
> Sent: Thursday, May 29, 2003 11:27 AM
> Subject: Re: malloc in inferior
>
>
> > On Thu, May 29, 2003 at 09:51:15AM -0400, John S. Yates, Jr. wrote:
>
> [..SNIP..]
>
> > > Why can gdb not allocate values within its own
> > > address space?
> >
> > Because it's not useful to do so. Sure, trivial examples like
> > print "foo" could be done this way; and it would be nice to do that.
> > But to do anything more complicated requires materializing them in the
> > inferior. Some optimization is missing but you can't get away from the
> > problem that way.
>
> Is there anything short of calling a function in the
> target that requires materialization in the inferior?
> I can perform an enormous amount of debugging without
> ever thinking about trying to call a function.
What can you usefully do with strings that doesn't communicate them to
the inferior?
For instance, assigning "set x = "abc"" must materialize it in the
inferior.
> > > I understand that to support calling functions
> > > in the inferior gdb may have to materialize
> > > values there. But these should be pushed into
> > > the inferior once it is clear that they need to
> > > exist there.
>
> I think this suggestion got missed. Instead of today's
> immediate materialization in the inferior against the
> possibility that the value might be required there in
> the future why not use a lazy approach? Before calling
> an inferior function push down any accessible objects.
I didn't miss it; see above. It would have to happen every time the
inferior is _resumed_, too.
> > > And how can gdb possibly debug a multi-threaded
> > > application with a thread-safe malloc?
> >
> > This wasn't considered in the current design, true. I'm open to
> > suggestions.
> >
> > > One possibility would be to add malloc and free
> > > messages to the remote protocol. Then a stub
> > > could allocation memory in the proper address
> > > space without interacting with the inferior's
> > > environment.
> > >
> > > Another would be to have a stub provide a block
> > > of memory. A query would determine the address
> > > and size of this block. Then gdb could manage
> > > the memory entirely on its own.
> >
> > For some stubs these would be useful; for the stubs I deal with, which
> > sit in user space on normal OS's, rather less so. The stub would end
> > up calling malloc anyway.
>
> This may be the case for the first suggestion. The
> second was that gdb have access to a chunk of memory
> that it manages itself. That is the allocation and
> freeing would operator on structures in gdb's address
> space, only the actual memory would exist in the
> inferior. In a remote stub the block of memory might
> simply be a large static array.
Which would, in a protected memory system, have to be allocated in the
child anyway. And you can't call malloc() before program
initialization necessarily.
> > Personally, I'm of the opinion that we should solve this problem by
> > changing the definitions: mark strings as ephemeral and let the user
> > call malloc or strdup directly if they want something to last. Or make
> > it a set option. I'm not sure how popular that idea would be; anyone
> > else have a comment?
>
> The problem is more general than just strings.
Care to give another example of when GDB calls malloc? Strings are far
and away the most common.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2003-05-29 16:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-29 13:51 John S. Yates, Jr.
2003-05-29 15:27 ` Daniel Jacobowitz
2003-05-29 16:00 ` John S. Yates, Jr.
2003-05-29 16:09 ` Daniel Jacobowitz [this message]
2003-05-29 17:18 ` John S. Yates, Jr.
2003-05-29 17:24 ` Daniel Jacobowitz
2003-05-29 18:18 ` Andrew Cagney
2003-05-29 18:34 ` Alain Magloire
2003-05-30 13:12 ` John S. Yates, Jr.
[not found] ` <16086.16988.657059.717389@pkoning.dev.equallogic.com>
2003-05-30 13:03 ` John S. Yates, Jr.
2003-05-29 16:42 ` Andrew Cagney
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=20030529160927.GA11795@nevyn.them.org \
--to=drow@mvista.com \
--cc=gdb@sources.redhat.com \
--cc=jyates@netezza.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).