Multiple inferiors and memory consumption

Multiple inferiors and memory consumption

[Vladimir Prus]

It could be me, but I always expected that using GDB multi-process functionality should be better than
separate GDB instances -- including memory consumption. So, I've just tried to run CVS gdb on itself
inside 4 inferiors, and it looks like each inferior, the amount of data used by GDB (the DATA column
in top) grows pretty much linearly. That is, it does not seem like GDB notices that symbol tables of
all 4 loaded executables are identical (There's a link to the chart: http://goo.gl/0auVf)

Is this something that is going to be improved upon in future?

And now for my real question -- is there any case when using multi-process to debug several applications
not related via parent-child relationship is better than running N copies of GDB?

Thanks,

-- 
Vladimir Prus
CodeSourcery / Mentor Graphics
http://www.mentor.com/embedded-software/

Re: Multiple inferiors and memory consumption

[Tom Tromey]

>>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:

Volodya> That is, it does not seem like GDB notices that symbol tables
Volodya> of all 4 loaded executables are identical

Volodya> Is this something that is going to be improved upon in future?

I've been working on it off and on.

You can see my latest attempt, search for

    [0/17] RFC: share minimal symbols across objfiles

in the Dec 2011 archives.

There are some follow-up thoughts scattered through the subsequent
months.  The problem is reasonably hard -- those 17 patches only address
minsym sharing, but there is at least partial- and full-symbol sharing
to deal with as well; plus some other things making it harder (dlmopen
support, should we want it, makes a mess of it all).

Volodya> And now for my real question -- is there any case when using
Volodya> multi-process to debug several applications
Volodya> not related via parent-child relationship is better than running N
Volodya> copies of GDB?

Nothing today.

In the future they'll share debuginfo when possible, but that may be the
only advantage.

I've occasionally wondered whether we could have gdb fork when in MI
mode and it follows both parent and child.

Tom

Re: Multiple inferiors and memory consumption

[Vladimir Prus]

On 10.07.2012 06:29, Tom Tromey wrote:
>>>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:
>
> Volodya> That is, it does not seem like GDB notices that symbol tables
> Volodya> of all 4 loaded executables are identical
>
> Volodya> Is this something that is going to be improved upon in future?
>
> I've been working on it off and on.
>
> You can see my latest attempt, search for
>
>      [0/17] RFC: share minimal symbols across objfiles
>
> in the Dec 2011 archives.
>
> There are some follow-up thoughts scattered through the subsequent
> months.  The problem is reasonably hard -- those 17 patches only address
> minsym sharing, but there is at least partial- and full-symbol sharing
> to deal with as well; plus some other things making it harder (dlmopen
> support, should we want it, makes a mess of it all).

I see -- I did not even know about dlmopen until now ;-)

>
> Volodya> And now for my real question -- is there any case when using
> Volodya> multi-process to debug several applications
> Volodya> not related via parent-child relationship is better than running N
> Volodya> copies of GDB?
>
> Nothing today.
>
> In the future they'll share debuginfo when possible, but that may be the
> only advantage.
>
> I've occasionally wondered whether we could have gdb fork when in MI
> mode and it follows both parent and child.

Interesting approach ;-)

Though I'm thinking that single GDB might allow easier
implementation of possible cool things like "step through DBus call". Or anything where
direct access to two, or several, processes, is needed. Of course, we can do this via
IDE, but with remote debugging that might end up awkward/slow.

- Volodya

-- 
Vladimir Prus
CodeSourcery / Mentor Graphics
http://www.mentor.com/embedded-software/

Re: Multiple inferiors and memory consumption

[Chris January]

On Tue, 2012-07-10 at 00:31 +0400, Vladimir Prus wrote:
> It could be me, but I always expected that using GDB multi-process functionality should be better than
> separate GDB instances -- including memory consumption. So, I've just tried to run CVS gdb on itself
> inside 4 inferiors, and it looks like each inferior, the amount of data used by GDB (the DATA column
> in top) grows pretty much linearly. That is, it does not seem like GDB notices that symbol tables of
> all 4 loaded executables are identical (There's a link to the chart: http://goo.gl/0auVf)

We ran across the same problem some time back. There is a comment in
objfiles.h:

FIXME:  There is a problem here if the objfile is reusable, and if
        multiple users are to be supported.  The problem is that the 

so it looks like at least one person has thought about re-using objfile
in the past.

We have a patch that allows multiple programs_spaces to share the same
objfiles by moving the linked list entry into a new struct
objfile_instance.

> And now for my real question -- is there any case when using
> multi-process to debug several applications
> not related via parent-child relationship is better than running N
> copies of GDB?

Most of the time, no. If you are debugging so many processes that the
per GDB memory overhead is starting to hurt then yes, but only if you
are sharing symbol files between inferiors as above.

Regards,
Chris January

Re: Multiple inferiors and memory consumption

[Tom Tromey]

>>>>> "Chris" == Chris January <chris.january@allinea.com> writes:

Chris> We ran across the same problem some time back. There is a comment in
Chris> objfiles.h:
Chris> FIXME:  There is a problem here if the objfile is reusable, and if
Chris>         multiple users are to be supported.  The problem is that the 

I think this refers to some ancient code that wrote out data to a file
and then later mmap'd it back in.  Search the archives for "mmalloc", I
think.

That code is long gone.  I see the comment is gone now too.

Chris> We have a patch that allows multiple programs_spaces to share the same
Chris> objfiles by moving the linked list entry into a new struct
Chris> objfile_instance.

Presumably this only works if the objfile is mapped at the same address
in each inferior.

I wouldn't mind your patch -- I think it is an improvement -- but I was
trying to make it so that sharing happened regardless of the mapping.
There's no deep reason this can't be done, it is just a gdb design
error.

Tom

Re: Multiple inferiors and memory consumption

[Tom Tromey]

>>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:

Volodya> Though I'm thinking that single GDB might allow easier
Volodya> implementation of possible cool things like "step through DBus
Volodya> call". Or anything where direct access to two, or several,
Volodya> processes, is needed. Of course, we can do this via IDE, but
Volodya> with remote debugging that might end up awkward/slow.

Yeah, I think there may be some useful features along these lines that
could be done.  There's nothing pre-canned, though.

I do tend to think that debugging multiple totally unrelated inferiors
is unusual.  That is, gdb will probably provide more benefit than you
might ordinarily expect.

Though, based on bug reporting rates, I think any kind of multi-inferior
debugging is still very rare.

Tom

RE: Multiple inferiors and memory consumption

[Marc Khouzam]

 
> And now for my real question -- is there any case when using 
> multi-process to debug several applications
> not related via parent-child relationship is better than 
> running N copies of GDB?

For the sake of completeness, let me mention the obvious.
When doing remote debugging, only one GDB can connect
to the target, so multi-process is the only option to debug
several applications.

Marc

Re: Multiple inferiors and memory consumption

[Paul_Koning]

On Jul 10, 2012, at 4:35 PM, Marc Khouzam wrote:

> 
>> And now for my real question -- is there any case when using 
>> multi-process to debug several applications
>> not related via parent-child relationship is better than 
>> running N copies of GDB?
> 
> For the sake of completeness, let me mention the obvious.
> When doing remote debugging, only one GDB can connect
> to the target, so multi-process is the only option to debug
> several applications.

True if you have a centralized stub.  If you have gdbserver implemented, you can run multiple instances of that, OS permitting.

	paul

Re: Multiple inferiors and memory consumption

[Vladimir Prus]

On 11.07.2012 00:35, Marc Khouzam wrote:
>
>> And now for my real question -- is there any case when using
>> multi-process to debug several applications
>> not related via parent-child relationship is better than
>> running N copies of GDB?
>
> For the sake of completeness, let me mention the obvious.
> When doing remote debugging, only one GDB can connect
> to the target, so multi-process is the only option to debug
> several applications.

Well, yeah. Which seems like a limitation, not feature ;-)


-- 
Vladimir Prus
CodeSourcery / Mentor Graphics
http://www.mentor.com/embedded-software/

Re: Multiple inferiors and memory consumption

[Chris January]

On Tue, 2012-07-10 at 13:09 -0600, Tom Tromey wrote:
> Chris> We have a patch that allows multiple programs_spaces to share the same
> Chris> objfiles by moving the linked list entry into a new struct
> Chris> objfile_instance.
> 
> Presumably this only works if the objfile is mapped at the same address
> in each inferior.

Yes, indeed, so it works well for executables, but less well for shared
libraries.

Chris