Re: [RFC] [1/2] First cut at multi-executable support.

[Tom Tromey <tromey@redhat.com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> All-in-all, what do you think of this, and the patch below?  

I think it is unbelievably awesome.

Pedro> There's certainly scope of a lot of goodies to be added on top
Pedro> of this, like extending thread control support (threads groups, itsets
Pedro> or whatever); better support for symbol scoping a-la HPD's ## syntax
Pedro> would be great too; Making the breakpoints module smarter about
Pedro> that also would be nice.

... sharing objfiles across inferiors would be nice.  It seems to me
that this would be important for capping memory use when there are
many inferiors.  I wonder if this makes sense with the aspace/sspace
stuff, given that an objfile now has a symbol space.

When gdb sees a new inferior, does it immediately read its debuginfo?
This seems like another possible performance problem; lazily reading
it would be friendlier.  In a scenario like the "make" case, I would
assume that most inferiors will not actually require any user
attention, and time and memory spent on their debuginfo is just
wasted.


I saw this in the output:

    [Thread debugging using libthread_db enabled]
    process 16875 is executing new program: /bin/true
    (no debugging symbols found)
    (no debugging symbols found)
    (no debugging symbols found)

    Program exited normally.
    make[2]: Leaving directory `/home/pedro/gdb/sspaces/build/gdb/gdbserver'

    Program exited normally.

    Program exited normally.

    Program exited normally.
    make[1]: Leaving directory `/home/pedro/gdb/sspaces/build/gdb'

    Program exited normally.

I think the "(no debugging symbols found)" thing has been addressed.
At least, there was a patch.

"Program exited normally." could also use some love... at least some
info about the program, and maybe removing the excess newlines?


I see in many places that we pass an address_space and a CORE_ADDR
together, e.g.:

+insert_single_step_breakpoint (struct address_space *aspace, CORE_ADDR next_pc)

Does a CORE_ADDR make sense without an address_space?
I'm curious whether you considered putting the address_space into
CORE_ADDR, or making a new type holding both.


+#define exec_bfd current_symbol_space->ebfd
+#define exec_bfd_mtime current_symbol_space->ebfd_mtime

+#define so_list_head current_symbol_space->so_list

+#define symfile_objfile current_symbol_space->symfile_objfile_1

+#define object_files current_symbol_space->objfiles

+#define current_target_sections (&current_symbol_space->target_sections)

I don't mind this kind of thing as a transitional change, to make it
so a patch doesn't completely explode.  But I think I'd prefer, in the
long run, to replace these macros with their expansions (or maybe
accessor macros taking current_symbol_space as an argument)
everywhere.  What do you think?

Also, I am curious about the relationship between the current inferior
and the current symbol space.  I guess whenever the current inferior
changes, the current inferior space must as well?

+  ui_out_table_header (uiout, 1, ui_left, "current", "");

For some reason I did not think of leaving the header empty when I did
this for "info inferiors".  I like this better... since you're also
touching print_inferior, how about just making that change?


I can't really comment on the rest of the patch.
I skimmed it but I don't know the original code well enough.
Nothing stood out as bad.

Tom