Re: [obish?sym;rfa:doc] Wire up vsyscall

[Andrew Cagney <cagney at gnu dot org>]

> On Thu, May 06, 2004 at 05:48:54PM -0700, Roland McGrath wrote:
>
> > > > > At present I know of the following problems:
> > > > > 
> > > > > 1. The code assumes ELF support in BFD
> > > > > Per recent BFD posts, I'm fixing this.
> >
> > > I didn't find what you're referring to in a quick scan of the archives.
> > > Can you give me a specific URL in the mailing list archive, or an exact
> > > subject line to search for?  I participated in the discussion about the
> > > issue, but I don't recall a posting from you proposing changes to address it.
>
>
> See the binutils list, where Andrew has been reimplementing the
> underlying I/O mechanism lately.
>
>
> > > > > 3. inferior recycle VS inferior create
> > > > > Because GDB currently fudges things by recycling the inferior at each 
> > > > > run (instead of creating a new fresh inferior) symfile tries to reload 
> > > > > the vsyscall page.  Doesn't do any harm fortunatly.  Having a proper 
> > > > > inferior will fix this.
>
>
> I don't see how this is different than any other shared library.  I
> think we already set a flag that causes the objfile to be discarded
> at re-run (OBJF_SHARED) unless this has been lost somewhere?

As roland wrote:

> I'm not clear on what you mean by "reload the vsyscall page" here.  What
> needs to happen on a repeated run is to repeat from scratch all the
> vsyscall-page-related work that was done on the first run/attach.  
> That is, all of the details can turn out different on each new exec:
> whether or not AT_SYSINFO_EHDR is supplied at all; the address of the page;
> the contents of the page, i.e. its symbol table and unwind info.

GDB should start from scratch with each new inferior.  While I've 
correctly written this new code that way, the existing symfile code and 
many chunks of GDB are not.  Instead of a nice crisp new inferior, that 
code recycles (re-loads) existing globals containing values left over 
from the previous inferior.

> > > > > +	/* FIXME: cagney/2004-05-06: Should not require an existing
> > > > > +	   BFD when trying to create a run-time BFD of the VSYSCALL
> > > > > +	   page in the inferior.  Unfortunatly that's the current
> > > > > +	   interface so for the moment bail.  Introducing a
> > > > > +	   ``bfd_runtime'' (a BFD created using the loaded image) file
> > > > > +	   format should fix this.  */
> > > > > +	return;
> >
> > > I think there should be an error thrown or at least a warning message here,
> > > instead of just silent not-doing.  The user can then do "file" before
> > > "attach" to make the backtraces work.

- you can't throw an error, that aborts the run command

> > > > > +	printf_unfiltered ("Loaded system supplied DSO at 0x%s\n",
> > > > > +			   paddr_nz (sysinfo_ehdr));
> >
> > > I don't know if printf_unfiltered means this or not, but this output should
> > > only appear under `set verbose on'.  Also, I would change the message to
> > > fix the grammar and to be consistent with other gdb messages:
> > >
> > > 	"Reading symbols from system-supplied DSO at 0x%s\n"
>
>
> Either set verbose, or at least propogate from_tty here.

I'll tweak.

Andrew