This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC,v2] Yank out target_ops->to_sections


Pedro Alves wrote:

> I've been thinking for a while that the exec_ops target
> should be pushed whenever we have any kind of file loaded (main
> executable or dynamic shared module) that we can read memory
> from.  It implements the file_stratum after all, and target.h says:
> 
> file_stratum,               /* Executable files, etc */
>                                                  ^^^

I agree, and I like the approach in your v3 patch :-)

> Here's a stripped down version of what I've got here currently:
> 
> /* A symbol space represents a symbolic view of an address space.  It
>    holds all the data associated with a non-running-yet program (main
>    executable, main symbols), and when an inferior is running and is
>    bound to it, includes the list of its mapped in shared libraries.
> 
>    In the traditional debugging scenario, there's a 1-1 correspondence
>    among symbol spaces, inferiors and address spaces, like so:
> 
>      sspace1 (prog1) <--> inf1(pid1) <--> aspace1

Thanks for the detailed description!  This makes sense to me.

> There still needs to be a global somewhere, there's no way around it,
> but, it will be the "current_symbol_space", not the target sections.
> This global is then switched whenever we need to switch context
> --- switch thread, insert breakpoints, or by user command, to e.g.,
> prepare to start a new inferior --- in a sense, this structure holds
> the globals that currently form a "prototype" for an inferior.

This is the one part I'm not sure I agree with.  I would have hoped
we could actually get *rid* of all those globals, at least as far
as the GDB core is concerned.  (There may be globals in the UI code
where it makes sense, to represent conceptually global settings at
the the UI level like the notion of the "selected frame".  But all
of GDB's core should IMO be fully parameterized and not rely on
globals.  I'd expect this could be achieved by passing "inferior"
or "thread" arguments to some of the central functions ...)

> > Also, I'm not completely sure I understand the implications of the solib_add
> > change.  The old method allowed callers to explicitly ask that the library
> > sections be *not* added to the section table, and several callers did that.
> > With your patch, sections are always added.  Was it always an error to not
> > add sections?  I'm not really sure why this feature was introduced ...
> 
> I think that historically, it was the other way around.  They were never
> added in the beggining, and when shared libraries support for core
> files was added to GDB, the corresponing targets that supported it
> were adjusted to pass a target_ops pointer.
> 
> We've currently got more use for the target sections (trust-readonly-sections,
> for once), so I think we should always add the sections.  I've done a bit
> of history digging.  Looking at gdb 3.98's sources, and I see in solib.c:

Thanks for doing this research!  You've convinced me it should be fine
to unconditionally add solib target sections.

>  solib-irix.c:  solib_add ((char *) 0, 0, (struct target_ops *) 0, auto_solib_add);
> 
> I can't see a native .mt file pulling this in.

It's a target property:

mips*-sgi-irix5*)
        # Target: MIPS SGI running Irix 5
        gdb_target_obs="mips-tdep.o mips-irix-tdep.o solib.o solib-irix.o"
        ;;
mips*-sgi-irix6*)
        # Target: MIPS SGI running Irix 6.x
        gdb_target_obs="mips-tdep.o mips-irix-tdep.o solib.o solib-irix.o"
        ;;


> This shared library support can't be being used with core inferiors, since
> irix_solib_create_inferior_hook always wants to resume the target.

Hmm, good point.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]