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

[Roland McGrath <roland@redhat.com>]

> 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.

> 2. bfd_elf_bfd_from_remote_memory requires an existing bfd
> For the case:
> 	$ ./gdb
> 	(gdb) attach <pid>
> that isn't necessarially so.  1. will fix this.

I used a bfd argument this way because the functions I saw handy to do
target-integer-format extraction used a bfd argument.  Not knowing BFD too
well, I probably overlooked some other way to get at that info.  

> 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'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.


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.

> +	/* 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.  Of course the details of the
workaround don't matter if the problem is being fixed properly quite soon.

> +	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"

> +  /* Want to know of each new inferior so that it's vsyscall info can
> +     be extracted.  */

Typo here: it's -> its.

> +@var{GDBN} has just created to a new inferior.  For @samp{run}, it is

Extra word here:	       ^^

> +immediatly after opening the inferior (and before any information on

Typo here: immediatly -> immediately.

> but remember I intend changing the second to:
> 
> ...
> #1 0x1234 in <signal trampoline>
> ...

That's a nice improvement anyway.  
I have never liked the hiding of the PC value.


Thanks,
Roland