[rfa/remote] Reread symbols on 'target remote'

[rfa/remote] Reread symbols on 'target remote'

[Daniel Jacobowitz]

Right now chng-syms.exp fails for remote targets, because "run" causes the
executable to be reread but "target remote" doesn't.  I thought I'd already
submitted a patch for this, a year or two ago, but I can't find it in my
archives anywhere.  This patch just adds a matching check to remote_open_1.

This patch, and another I'm about to send separately, fix chng-syms.exp for
gdbserver targets.

OK?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2004-02-28  Daniel Jacobowitz  <drow@mvista.com>

	* remote.c (remote_open_1): Reopen the exec file and reread symbols
	if necessary.

Index: gdb/remote.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/remote.c,v
retrieving revision 1.129
diff -u -p -r1.129 remote.c
--- gdb/remote.c	15 Feb 2004 15:22:06 -0000	1.129
+++ gdb/remote.c	27 Feb 2004 22:36:05 -0000
@@ -2146,6 +2146,9 @@ remote_open_1 (char *name, int from_tty,
   if (!async_p)
     wait_forever_enabled_p = 1;
 
+  reopen_exec_file ();
+  reread_symbols ();
+
   target_preopen (from_tty);
 
   unpush_target (target);

Re: [rfa/remote] Reread symbols on 'target remote'

[Andrew Cagney]

> 2004-02-28  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	* remote.c (remote_open_1): Reopen the exec file and reread symbols
> 	if necessary.

What happens if the target is "extended-remote"?

Andrew

Re: [rfa/remote] Reread symbols on 'target remote'

[Daniel Jacobowitz]

On Fri, Mar 05, 2004 at 12:31:46AM -0500, Andrew Cagney wrote:
> >2004-02-28  Daniel Jacobowitz  <drow@mvista.com>
> >
> >	* remote.c (remote_open_1): Reopen the exec file and reread symbols
> >	if necessary.
> 
> What happens if the target is "extended-remote"?

Works fine.  remote_open_1 is only called when we create the initial
connection and handles any rereading at that time; run_command in
infcmd.c will handle if the "run" command is issued over an existing
extended-remote connection.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/remote] Reread symbols on 'target remote'

[Andrew Cagney]

> On Fri, Mar 05, 2004 at 12:31:46AM -0500, Andrew Cagney wrote:
> 
>>>> >2004-02-28  Daniel Jacobowitz  <drow@mvista.com>
>>>> >
>>>> >	* remote.c (remote_open_1): Reopen the exec file and reread symbols
>>>> >	if necessary.
>>
>>> 
>>> What happens if the target is "extended-remote"?
> 
> 
> Works fine.  remote_open_1 is only called when we create the initial
> connection and handles any rereading at that time; run_command in
> infcmd.c will handle if the "run" command is issued over an existing
> extended-remote connection.

Sorry, I ment without the patch (but I think you've answered that anyway).

While "run" and "load" are fairly obvious sync points for GDB and its 
executable I'm not sure that "target remote" is - it's behavior is kind 
of sort of a screwed up version of attach.

What does that do (as far as I can tell it doesn't re-read symbols)?

Andrew

Re: [rfa/remote] Reread symbols on 'target remote'

[Daniel Jacobowitz]

On Wed, Mar 17, 2004 at 10:16:19AM -0500, Andrew Cagney wrote:
> >On Fri, Mar 05, 2004 at 12:31:46AM -0500, Andrew Cagney wrote:
> >
> >>>>>2004-02-28  Daniel Jacobowitz  <drow@mvista.com>
> >>>>>
> >>>>>	* remote.c (remote_open_1): Reopen the exec file and reread symbols
> >>>>>	if necessary.
> >>
> >>>
> >>>What happens if the target is "extended-remote"?
> >
> >
> >Works fine.  remote_open_1 is only called when we create the initial
> >connection and handles any rereading at that time; run_command in
> >infcmd.c will handle if the "run" command is issued over an existing
> >extended-remote connection.
> 
> Sorry, I ment without the patch (but I think you've answered that anyway).

Yeah - with extended-remote we don't reload on target extended-remote
but do reload on run.

> While "run" and "load" are fairly obvious sync points for GDB and its 
> executable I'm not sure that "target remote" is - it's behavior is kind 
> of sort of a screwed up version of attach.
> 
> What does that do (as far as I can tell it doesn't re-read symbols)?

I think you're right - attach won't reread symbols either.  I believe
run is the only current sync point.  My instinct is that target remote
and attach both ought to be - I know that if I'm debugging something
that needs to be started in a separate environment and attached to, and
I detach, rebuilt, re-attach, I'd be confused if GDB didn't
auto-reload.  I know I've tried to do the same thing for target remote,
and expected GDB to reload - it didn't, and it took me a while to work
out what the problem was.

We should probably be consistent.  Want me to get attach too?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/remote] Reread symbols on 'target remote'

[Daniel Jacobowitz]

On Wed, Mar 17, 2004 at 10:16:19AM -0500, Andrew Cagney wrote:
> >On Fri, Mar 05, 2004 at 12:31:46AM -0500, Andrew Cagney wrote:
> >
> >>>>>2004-02-28  Daniel Jacobowitz  <drow@mvista.com>
> >>>>>
> >>>>>	* remote.c (remote_open_1): Reopen the exec file and reread symbols
> >>>>>	if necessary.
> >>
> >>>
> >>>What happens if the target is "extended-remote"?
> >
> >
> >Works fine.  remote_open_1 is only called when we create the initial
> >connection and handles any rereading at that time; run_command in
> >infcmd.c will handle if the "run" command is issued over an existing
> >extended-remote connection.
> 
> Sorry, I ment without the patch (but I think you've answered that anyway).

Yeah - with extended-remote we don't reload on target extended-remote
but do reload on run.

> While "run" and "load" are fairly obvious sync points for GDB and its 
> executable I'm not sure that "target remote" is - it's behavior is kind 
> of sort of a screwed up version of attach.
> 
> What does that do (as far as I can tell it doesn't re-read symbols)?

I think you're right - attach won't reread symbols either.  I believe
run is the only current sync point.  My instinct is that target remote
and attach both ought to be - I know that if I'm debugging something
that needs to be started in a separate environment and attached to, and
I detach, rebuilt, re-attach, I'd be confused if GDB didn't
auto-reload.  I know I've tried to do the same thing for target remote,
and expected GDB to reload - it didn't, and it took me a while to work
out what the problem was.

We should probably be consistent.  Want me to get attach too?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/remote] Reread symbols on 'target remote'

[Andrew Cagney]

>>> While "run" and "load" are fairly obvious sync points for GDB and its 
>>> executable I'm not sure that "target remote" is - it's behavior is kind 
>>> of sort of a screwed up version of attach.
>>> 
>>> What does that do (as far as I can tell it doesn't re-read symbols)?
> 
> 
> I think you're right - attach won't reread symbols either.  I believe
> run is the only current sync point.  My instinct is that target remote
> and attach both ought to be - I know that if I'm debugging something
> that needs to be started in a separate environment and attached to, and
> I detach, rebuilt, re-attach, I'd be confused if GDB didn't
> auto-reload.  I know I've tried to do the same thing for target remote,
> and expected GDB to reload - it didn't, and it took me a while to work
> out what the problem was.
> 
> We should probably be consistent.  Want me to get attach too?

Well attach is more messed up than that.  It might load the symbol table 
(if it isn't already loaded and can be determined from /proc).  Should 
attach instead always load the symbol table, prefering what is provided 
by the executable?

(meanwhile the remote change might as well go in to mainline)

Andrew

Re: [rfa/remote] Reread symbols on 'target remote'

[Daniel Jacobowitz]

On Mon, Mar 22, 2004 at 05:28:48PM -0500, Andrew Cagney wrote:
> 
> >>>While "run" and "load" are fairly obvious sync points for GDB and its 
> >>>executable I'm not sure that "target remote" is - it's behavior is kind 
> >>>of sort of a screwed up version of attach.
> >>>
> >>>What does that do (as far as I can tell it doesn't re-read symbols)?
> >
> >
> >I think you're right - attach won't reread symbols either.  I believe
> >run is the only current sync point.  My instinct is that target remote
> >and attach both ought to be - I know that if I'm debugging something
> >that needs to be started in a separate environment and attached to, and
> >I detach, rebuilt, re-attach, I'd be confused if GDB didn't
> >auto-reload.  I know I've tried to do the same thing for target remote,
> >and expected GDB to reload - it didn't, and it took me a while to work
> >out what the problem was.
> >
> >We should probably be consistent.  Want me to get attach too?
> 
> Well attach is more messed up than that.  It might load the symbol table 
> (if it isn't already loaded and can be determined from /proc).  Should 
> attach instead always load the symbol table, prefering what is provided 
> by the executable?

If I'm reading you right - then I think the answer is yes.  What's your
opinion on the patch below?  If there is no exec file, then attempt to
determine one from target_pid_to_exec_file.  Otherwise, attempt to
reread the exec file.

> (meanwhile the remote change might as well go in to mainline)

OK, checked in.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2004-03-23  Daniel Jacobowitz  <drow@mvista.com>

	* infcmd.c (attach_command): Reread symbols if we already have
	an exec file.

Index: infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.105
diff -u -p -r1.105 infcmd.c
--- infcmd.c	14 Feb 2004 17:26:35 -0000	1.105
+++ infcmd.c	23 Mar 2004 15:47:33 -0000
@@ -1843,6 +1843,11 @@ attach_command (char *args, int from_tty
 	  symbol_file_add_main (full_exec_path, from_tty);
 	}
     }
+  else
+    {
+      reopen_exec_file ();
+      reread_symbols ();
+    }
 
 #ifdef SOLIB_ADD
   /* Add shared library symbols from the newly attached process, if any.  */

Re: [rfa/remote] Reread symbols on 'target remote'

[Andrew Cagney]

>>Well attach is more messed up than that.  It might load the symbol table 
>>> (if it isn't already loaded and can be determined from /proc).  Should 
>>> attach instead always load the symbol table, prefering what is provided 
>>> by the executable?
> 
> 
> If I'm reading you right - then I think the answer is yes.  What's your
> opinion on the patch below?  If there is no exec file, then attempt to
> determine one from target_pid_to_exec_file.  Otherwise, attempt to
> reread the exec file.

I was thinking of something more agressive:

if target (via /proc) can identify exec file
	switch to target's exec file, load
else if exec file known
	load
else
	hope the user knows what they are doing
fi

which is different to the current logic like:

if exec file known
	do nothing
else if target (via /proc) can identify exec file
	switch to target's exec file, load
else
	hope ...
fi

however yes, at least (per your patch) always loading the symbols is a 
good first step.

(this goes back to earlier posts where we need to overaul the target 
stack so that multiple instances are available)

Andrew

Re: [rfa/remote] Reread symbols on 'target remote'

[Daniel Jacobowitz]

On Tue, Mar 23, 2004 at 11:42:03AM -0500, Andrew Cagney wrote:
> I was thinking of something more agressive:
> 
> if target (via /proc) can identify exec file
> 	switch to target's exec file, load
> else if exec file known
> 	load
> else
> 	hope the user knows what they are doing
> fi

I don't think that's a good idea.  For example, recently, I was running
/usr/bin/gdb.  It got stuck in a loop.  I attached, but could not get a
backtrace - it was stripped - so I detached, loaded
/nevyn/local/gdb/gdb-6.0/objdir/gdb/gdb, and attached.  Then I had my
backtrace.  Your proposed change above would have made GDB switch back
to the stripped version.

Sure, separate debug info is a nice solution to this - if you've
prepared it in advance.

> however yes, at least (per your patch) always loading the symbols is a 
> good first step.

OK, I'm checking it in for HEAD.

> (this goes back to earlier posts where we need to overaul the target 
> stack so that multiple instances are available)

Absolutely agreed.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/remote] Reread symbols on 'target remote'

[Andrew Cagney]

> On Fri, Mar 05, 2004 at 12:31:46AM -0500, Andrew Cagney wrote:
> 
>>>> >2004-02-28  Daniel Jacobowitz  <drow@mvista.com>
>>>> >
>>>> >	* remote.c (remote_open_1): Reopen the exec file and reread symbols
>>>> >	if necessary.
>>
>>> 
>>> What happens if the target is "extended-remote"?
> 
> 
> Works fine.  remote_open_1 is only called when we create the initial
> connection and handles any rereading at that time; run_command in
> infcmd.c will handle if the "run" command is issued over an existing
> extended-remote connection.

Sorry, I ment without the patch (but I think you've answered that anyway).

While "run" and "load" are fairly obvious sync points for GDB and its 
executable I'm not sure that "target remote" is - it's behavior is kind 
of sort of a screwed up version of attach.

What does that do (as far as I can tell it doesn't re-read symbols)?

Andrew

Re: [rfa/remote] Reread symbols on 'target remote'

[Daniel Jacobowitz]

On Fri, Mar 05, 2004 at 12:31:46AM -0500, Andrew Cagney wrote:
> >2004-02-28  Daniel Jacobowitz  <drow@mvista.com>
> >
> >	* remote.c (remote_open_1): Reopen the exec file and reread symbols
> >	if necessary.
> 
> What happens if the target is "extended-remote"?

Works fine.  remote_open_1 is only called when we create the initial
connection and handles any rereading at that time; run_command in
infcmd.c will handle if the "run" command is issued over an existing
extended-remote connection.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/remote] Reread symbols on 'target remote'

[Andrew Cagney]

> 2004-02-28  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	* remote.c (remote_open_1): Reopen the exec file and reread symbols
> 	if necessary.

What happens if the target is "extended-remote"?

Andrew