Re: [patch/rfc] New program_changed event, cleanup some HPUXHPPAmess

[Andrew Cagney <cagney at gnu dot org>]

> On Wed, May 26, 2004 at 01:54:30PM -0400, Andrew Cagney wrote:
>
> > > > >+static void
> > > > >+hppa_hpux_observer_inferior_created (struct target_ops *objfile, int 
> > > > >from_tty)
> > > > >+{
> > > > >+  struct gdbarch_tdep *tdep;
> > > > >+  struct minimal_symbol *minsym;
> > > > >+
> > > > >+  tdep = gdbarch_tdep (current_gdbarch);
> > > > >+
> > > > >+  /* Some HP-UX related globals to clear when a new "main"
> > > > >+     symbol file is loaded. HP-specific.  */
> > > > >+
> > > > >+  /* Indicates HP-compiled code.  */
> > > > >+  deprecated_hp_som_som_object_present = 0;
> > > > >+  /* Must reinitialize exception stuff.  */
> > > > >+  hp_cxx_exception_support_initialized = 0;
> > > > >+
> > > > >+  minsym = lookup_minimal_symbol ("$$dyncall_external", NULL, NULL);
> > > > >+  if (minsym)
> > > > >+    tdep->dyncall_external = SYMBOL_VALUE_ADDRESS (minsym);
> > > > >+  else
> > > > >+    tdep->dyncall_external = -1;
> > > > >+
> > > > >+  minsym = lookup_minimal_symbol ("_sr4export", NULL, NULL);
> > > > >+  if (minsym)
> > > > >+    tdep->sr4export = SYMBOL_VALUE_ADDRESS (minsym);
> > > > >+  else
> > > > >+    tdep->sr4export = -1;
> > > > >+}
> >
> > > Unfortunatly, not really but as you've noticed, it does ``work'', sigh. 
> > >  At least we can now see what the code is doing.
> > >
> > > The above values are dependant on the inferior (and make change between 
> > > inferior invocations) and not the architecture so their lifetime should 
> > > be bound to the inferior.  This patch binds them to the current 
> > > ``global'' architecture :-(
>
>
> ... but forces them to update every time the inferior restarts.

The information needs to be determined for each new inferior, yes.

> Yes,
> if we have multiple inferiors sharing an architecture this won't work. 
> I think that's true of many mutable fields in various targets' tdep. 
> They need to migrate to a per-inferior data object someday.

> > > Can, for the immediate term, hppa_hpux_skip_trampoline_code be 
> > > simplified so that it doesn't even try to cache these values?  This will 
> > > put a real strain on the symtab but I think its the symtab that is the 
> > > place that needs the fix.
>
>
> What's wrong with the symtab here?

We'll find out - the change will put the additional lookups will put the 
symtab under extra strain.

Andrew