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

[Daniel Jacobowitz <drow at false 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?

> I don't know the status of the "catch exec" functionality.
> But if that works at all, it needs to do this observer notification too.
> Otherwise the patch looks good to me modulo the following tiny nits.

It doesn't work.  It's broken by design; I have patches that make it
"work" again, but I never submitted them because both the code and the
interface are so ugly.

> > +	/* 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.

I agree.

> > +	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.  Right now the
thread_db message is the only thing in startup that disregards from_tty
(I've been meaning to fix this for ages).

-- 
Daniel Jacobowitz