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

Daniel Jacobowitz
2004-05-07T01:31:00Z

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