call observer_notify_new_objfile after the attach command

Message ID 7e50a9e5f62f49c39dfaff1a57487393@BLUPR03MB136.namprd03.prod.outlook.com
State Superseded
Headers

Commit Message

Adrian Sendroiu July 9, 2014, 1:51 p.m. UTC
  When debugging a remote bare-metal target which implements the gdb protocol,
using target extended-remote + attach, gdb will not send the qSymbol packet,
even if a file was previously specified using file or symbol-file.

Normally gdb would call remote_check_symbols in several places: the solib
inferior hook, the add_vsyscall_page hook or if the executable file changed
in the time passed between the file and the attach commands. Since none of these
conditions hold in the above scenario (no shared libraries are used and no
vsyscall page is present), gdb won't send a qSymbol packet.

To fix this problem this patch calls observer_notify_new_objfile after the attach
command is completed, if such a symbol file is present.
---
 gdb/infcmd.c |    4 ++++
 1 file changed, 4 insertions(+)
  

Comments

Pedro Alves July 9, 2014, 2:18 p.m. UTC | #1
On 07/09/2014 02:51 PM, Adrian Sendroiu wrote:
> When debugging a remote bare-metal target which implements the gdb protocol,
> using target extended-remote + attach, gdb will not send the qSymbol packet,
> even if a file was previously specified using file or symbol-file.
> 
> Normally gdb would call remote_check_symbols in several places: the solib
> inferior hook, the add_vsyscall_page hook or if the executable file changed
> in the time passed between the file and the attach commands. Since none of these
> conditions hold in the above scenario (no shared libraries are used and no
> vsyscall page is present), gdb won't send a qSymbol packet.
> 
> To fix this problem this patch calls observer_notify_new_objfile after the attach
> command is completed, if such a symbol file is present.

But, if no new objfile was (re)loaded, then why call the new_objfile
observer?  That's a bit backwards as it makes the core assume
what a particular observer wants to do with the event/subject.  If
remote.c is interested in doing something when the attach is complete,
then we can look for such a hook.  And it turns out one already
exists -- target_post_attach.  So it seems like remote.c should call
remote_check_symbols from its target_post_attach method ?
That's not that different in principle from the remote_check_symbols
call in remote_start_remote.
  

Patch

diff --git a/gdb/infcmd.c b/gdb/infcmd.c
index 14736a5..e491b5d 100644
--- a/gdb/infcmd.c
+++ b/gdb/infcmd.c
@@ -2368,11 +2368,15 @@  attach_command_post_wait (char *args, int from_tty, int async_exec)
 	  exec_file_attach (full_exec_path, from_tty);
 	  symbol_file_add_main (full_exec_path, from_tty);
 	}
+      else if (symfile_objfile)
+	observer_notify_new_objfile(symfile_objfile);
     }
   else
     {
       reopen_exec_file ();
       reread_symbols ();
+
+      observer_notify_new_objfile(symfile_objfile);
     }
 
   /* Take any necessary post-attaching actions for this platform.  */