RE: regarding transparent data ranges (in tracepoint support)

RE: regarding transparent data ranges (in tracepoint support)

[Newman, Mark (N-Superior Technical Resource Inc)]

ankit -

My feeling (i.e. imho) is that the engineer should be able to get at
tracepointed data at any time.

To me tracepointed data provides an historical "trail" of what occurred
during the execution of the inferior.  The engineer needs to be able to
"see" that data while the inferior is running and after the inferior
stops.

When the operator specifies a time slice (via a tfind) then only the
data collected should be available to that engineer.  Anything else that
he/she would see would be from a different time slice.  I realize that
transparent data should not change - but the engineer may be looking to
see if it did change inappropriately.  If the engineer wants to "see"
that transparent data it should have been collected.  (Which leaves open
the question of whether or not an engineer should be able to collect
transparent data).

                                               Mark Newman

> -----Original Message-----
> From: gdb-owner@sources.redhat.com
> [mailto:gdb-owner@sources.redhat.com]On Behalf Of ankit thukral
> Sent: Sunday, November 16, 2003 1:32 AM
> To: gdb@sources.redhat.com
> Subject: regarding transparent data ranges (in tracepoint support)
> 
> 
> hi all,
>      i read about the transparent data ranges and
> learned that data in these ranges are not supposed to
> be collected by the remote stub since they belong to
> read-only segment of the debuggee.my problem is : a
> TSTART would start the debuggee and it may so happen
> that the debuggee finishes executing.at this point,if
> the GDB requests for some data in the transparent data
> range,then how can the remote stub provide it with one
> since the debuggee has exited ?
>       i think the debuggee needs to be stopped after
> main() has finished .this may be achieved by setting
> an internal breakpoint somewhere (i have no idea
> where).or may be something else.
>       any ideas or suggestions??
> 
> 
> thanks in advance,
> ankit.
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> 

Re: regarding transparent data ranges (in tracepoint support)

[Ramana Radhakrishnan]

Newman, Mark (N-Superior Technical Resource Inc) wrote:

>ankit -
>
>My feeling (i.e. imho) is that the engineer should be able to get at
>tracepointed data at any time.
>
>To me tracepointed data provides an historical "trail" of what occurred
>during the execution of the inferior.  The engineer needs to be able to
>"see" that data while the inferior is running and after the inferior
>stops.
>
>When the operator specifies a time slice (via a tfind) then only the
>data collected should be available to that engineer.  Anything else that
>he/she would see would be from a different time slice.  I realize that
>transparent data should not change - but the engineer may be looking to
>see if it did change inappropriately.  If the engineer wants to "see"
>that transparent data it should have been collected.  (Which leaves open
>the question of whether or not an engineer should be able to collect
>transparent data).
>  
>

I would also leave the option upto the user to say whether he wants to 
actually collect the data from the transparent
regions.
what say others?
cheers
Ramana

>                                               Mark Newman
>
>  
>
>>-----Original Message-----
>>From: gdb-owner@sources.redhat.com
>>[mailto:gdb-owner@sources.redhat.com]On Behalf Of ankit thukral
>>Sent: Sunday, November 16, 2003 1:32 AM
>>To: gdb@sources.redhat.com
>>Subject: regarding transparent data ranges (in tracepoint support)
>>
>>
>>hi all,
>>     i read about the transparent data ranges and
>>learned that data in these ranges are not supposed to
>>be collected by the remote stub since they belong to
>>read-only segment of the debuggee.my problem is : a
>>TSTART would start the debuggee and it may so happen
>>that the debuggee finishes executing.at this point,if
>>the GDB requests for some data in the transparent data
>>range,then how can the remote stub provide it with one
>>since the debuggee has exited ?
>>      i think the debuggee needs to be stopped after
>>main() has finished .this may be achieved by setting
>>an internal breakpoint somewhere (i have no idea
>>where).or may be something else.
>>      any ideas or suggestions??
>>
>>
>>thanks in advance,
>>ankit.
>>
>>__________________________________
>>Do you Yahoo!?
>>Protect your identity with Yahoo! Mail AddressGuard
>>http://antispam.yahoo.com/whatsnewfree
>>
>>    
>>

RE: regarding transparent data ranges (in tracepoint support)

[Ramana Radhakrishnan]

Hi Mark,

We had a similar problem and we added a hack to put in an internal
breakpoint at _fini and not at exit so that the program halts there. The
problem however is that if the debuggee exits on a SEGV for eg. the
transparent data regions cannot be queried anyways.

So the cleanest option would be to add support for PTRACE_EVENT_EXIT but
thats not available in the 2.4 series of kernels which are the ones on
which we are also working.

I am travelling for the next week and hence can't make a release without
the copyright assignment on which our firm's lawyers are working on. So
will try and make a release sometime next week after the copyright
assignment is done.


cheers
Ramana


> Could you be specific as to what kernel/file this is in?
>
> I am using 2.4.18 and can't find it in kernel/ptrace.c .
>
>                                Mark Newman
>
>> -----Original Message-----
>> From: Daniel Jacobowitz [mailto:drow@mvista.com]
>> Sent: Wednesday, November 19, 2003 3:22 PM
>> To: Newman, Mark (N-Superior Technical Resource Inc)
>> Cc: ankit thukral; Jim Blandy; gdb@sources.redhat.com
>> Subject: Re: regarding transparent data ranges (in tracepoint support)
>>
>>
>> On Wed, Nov 19, 2003 at 02:50:29PM -0500, Newman, Mark
>> (N-Superior Technical Resource Inc) wrote:
>> > Sorry about the tunnel vision.  When the SUT exits we loose
>> all of the
>> > tracepoint data in target memory. Stopping that from
>> happening is the
>> > next thing on my list after I finish making interrupt work.
>>  After the
>> > program finishes it should not exit without an ok from the engineer.
>> >
>> > So Ankit if that is what you are looking to do I agree completely.
>> > However can't gdbserver do something more like the restart
>> that occurs
>> > with a "w" or "x" status after the putpkt in the case statement in
>> > server.c
>>
>> For recent Linux kernels see PTRACE_EVENT_EXIT.
>>
>> In general, however, there's no easy way to prevent it from exiting
>> without that.
>>
>> >
>> >                                            Mark
>> >
>> > > -----Original Message-----
>> > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
>> > > Sent: Wednesday, November 19, 2003 2:39 PM
>> > > To: Newman, Mark (N-Superior Technical Resource Inc)
>> > > Cc: ankit thukral; Jim Blandy; gdb@sources.redhat.com
>> > > Subject: Re: regarding transparent data ranges (in
>> tracepoint support)
>> > >
>> > >
>> > > On Wed, Nov 19, 2003 at 02:34:49PM -0500, Newman, Mark
>> > > (N-Superior Technical Resource Inc) wrote:
>> > > > Guys - again please excuse my ignorance but
>> > > >
>> > > > I was assuming that transparent memory would either be
>> > > >
>> > > > In ROM
>> > > > In a write protected page
>> > > > In an unprotected page (for those systems without
>> memory protection)
>> > > > Possibly swapped out to the disk (for those system with a disk)
>> > > >
>> > > > However definitely readable by "read_inferior_memory".
>> > > >
>> > > > Why would the data not be loaded into some form of memory?
>> > > > What kind of data are we talking about?
>> > >
>> > > Ankit is talking about reading the transparant tracepoint
>> data after
>> > > the program has exited - when its memory isn't there any more.
>> > >
>> > > >
>> > > >                              Mark Newman
>> > > >
>> > > > > -----Original Message-----
>> > > > > From: gdb-owner@sources.redhat.com
>> > > > > [mailto:gdb-owner@sources.redhat.com]On Behalf Of Daniel
>> > > Jacobowitz
>> > > > > Sent: Wednesday, November 19, 2003 1:56 PM
>> > > > > To: ankit thukral
>> > > > > Cc: Jim Blandy; gdb@sources.redhat.com
>> > > > > Subject: Re: regarding transparent data ranges (in
>> > > tracepoint support)
>> > > > >
>> > > > >
>> > > > > On Wed, Nov 19, 2003 at 08:25:37AM -0800, ankit thukral wrote:
>> > > > > >
>> > > > > > --- Jim Blandy <jimb@redhat.com> wrote:
>> > > > > > >
>> > > > > > > ankit thukral <ankit_plug@yahoo.com> writes:
>> > > > > > >
>> > > > > > > > hi all,
>> > > > > > > >      i read about the transparent data ranges and
>> > > > > > > > learned that data in these ranges are not supposed
>> > > > > > > to
>> > > > > > > > be collected by the remote stub since they belong
>> > > > > > > to
>> > > > > > > > read-only segment of the debuggee.my problem is :
>> > > > > > > a
>> > > > > > > > TSTART would start the debuggee and it may so
>> > > > > > > happen
>> > > > > > > > that the debuggee finishes executing.at this
>> > > > > > > point,if
>> > > > > > > > the GDB requests for some data in the transparent
>> > > > > > > data
>> > > > > > > > range,then how can the remote stub provide it with
>> > > > > > > one
>> > > > > > > > since the debuggee has exited ?
>> > > > > > >
>> > > > > > > If the target is a gdbserver, then it would need to
>> > > > > > > read the bytes
>> > > > > > > from the executable file.  This is easy to do with
>> > > > > > > BFD, but if I
>> > > > > > > remember right, gdbserver doesn't use BFD at the
>> > > > > > > moment; not sure how
>> > > > > > > to get around that.
>> > > > > > >
>> > > > > > > If the target is an embedded system, then presumably
>> > > > > > > the transparent
>> > > > > > > data ranges correspond to ROM regions, so the data
>> > > > > > > is still there.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >   how about setting a (internal) breakpoint in the
>> > > > > > debuggee which would prevent it from exiting even
>> > > > > > though it has finished executing main(),and then
>> > > > > > entertain GDB requests for the transparent (or
>> > > > > > read-only) memory regions by reading from the memory
>> > > > > > of the debuggee???
>> > > > >
>> > > > > That would work (but be wasteful).  At least on Linux,
>> > > you could read
>> > > > > /proc/pid/maps to find what ranges correspond to where in
>> > > what file,
>> > > > > and save that information.
>> > > > >
>> > > > > --
>> > > > > Daniel Jacobowitz
>> > > > > MontaVista Software                         Debian
>> > > GNU/Linux Developer
>> > > > >
>> > > >
>> > >
>> > > --
>> > > Daniel Jacobowitz
>> > > MontaVista Software                         Debian
>> GNU/Linux Developer
>> > >
>> >
>>
>> --
>> Daniel Jacobowitz
>> MontaVista Software                         Debian GNU/Linux Developer
>>
>


----
Ramana Radhakrishnan
Codito Technologies

RE: regarding transparent data ranges (in tracepoint support)

[Newman, Mark (N-Superior Technical Resource Inc)]

Thanks Daniel;

Any other comments on the async changes?  

                                Mark

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Friday, November 28, 2003 12:28 PM
> To: Newman, Mark (N-Superior Technical Resource Inc)
> Cc: ankit thukral; Jim Blandy; gdb@sources.redhat.com
> Subject: Re: regarding transparent data ranges (in tracepoint support)
> 
> 
> On Fri, Nov 28, 2003 at 12:19:12PM -0500, Newman, Mark 
> (N-Superior Technical Resource Inc) wrote:
> > Could you be specific as to what kernel/file this is in?
> > 
> > I am using 2.4.18 and can't find it in kernel/ptrace.c .
> 
> That's your problem.  It was added around 2.5.38.
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 

Re: regarding transparent data ranges (in tracepoint support)

[Daniel Jacobowitz]

On Fri, Nov 28, 2003 at 12:31:13PM -0500, Newman, Mark (N-Superior Technical Resource Inc) wrote:
> Thanks Daniel;
> 
> Any other comments on the async changes?  

I asked for you to repost them using some readable format.  Describing
changes is both inefficient and ambiguous.

> 
>                                 Mark
> 
> > -----Original Message-----
> > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > Sent: Friday, November 28, 2003 12:28 PM
> > To: Newman, Mark (N-Superior Technical Resource Inc)
> > Cc: ankit thukral; Jim Blandy; gdb@sources.redhat.com
> > Subject: Re: regarding transparent data ranges (in tracepoint support)
> > 
> > 
> > On Fri, Nov 28, 2003 at 12:19:12PM -0500, Newman, Mark 
> > (N-Superior Technical Resource Inc) wrote:
> > > Could you be specific as to what kernel/file this is in?
> > > 
> > > I am using 2.4.18 and can't find it in kernel/ptrace.c .
> > 
> > That's your problem.  It was added around 2.5.38.
> > 
> > -- 
> > Daniel Jacobowitz
> > MontaVista Software                         Debian GNU/Linux Developer
> > 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: regarding transparent data ranges (in tracepoint support)

[Mark Newman]

Here ya go - but I'll be darned if this is clearer.

                       Mark

Index: gdb/infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.122
diff -r1.122 infrun.c
46a47,48
> #include "cli/cli-decode.h"
> 
4007a4010,4011
>     async_cmd(stop_command , ASYNC_OK);
> 
Index: gdb/maint.c
===================================================================
RCS file: /cvs/src/src/gdb/maint.c,v
retrieving revision 1.40
diff -r1.40 maint.c
737c737
<   add_prefix_cmd ("show", class_maintenance,
maintenance_show_cmd, "\
---
> async_cmd (  add_prefix_cmd ("show",
class_maintenance, maintenance_show_cmd, "\
742c742,743
< 		  &maintenancelist);
---
> 		  &maintenancelist)
> , ASYNC_OK);
Index: gdb/top.c
===================================================================
RCS file: /cvs/src/src/gdb/top.c,v
retrieving revision 1.85
diff -r1.85 top.c
671,676c671,673
<       if (event_loop_p && target_can_async_p () &&
target_executing)
< 	if (strcmp (c->name, "help") != 0
< 	    && strcmp (c->name, "pwd") != 0
< 	    && strcmp (c->name, "show") != 0
< 	    && strcmp (c->name, "stop") != 0)
< 	  error ("Cannot execute this command while the
target is running.");
---
>       if (event_loop_p && target_can_async_p () &&
target_executing) 
> 	     if ((c->flags & ASYNC_OK) != 0)
> 	        error ("Cannot execute this command while
the target is running.");
749a747,754
>     
>     if (event_loop_p && target_can_async_p () &&
target_executing) {
> 	if ((c->flags & ASYNC_WAIT) != 0) {
> 	   wait_for_inferior();
> 	  }
>       }
> 
> 
Index: gdb/cli/cli-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-cmds.c,v
retrieving revision 1.36
diff -r1.36 cli-cmds.c
1059,1060c1059,1061
<   add_com ("pwd", class_files, pwd_command,
< 	"Print working directory.  This is used for your
program as well.");
---
>   async_cmd(add_com ("pwd", class_files,
pwd_command,
> 	"Print working directory.  This is used for your
program as well.")
> , ASYNC_OK);
1093a1095,1096
>   async_cmd(c, ASYNC_OK);
> 
Index: gdb/cli/cli-decode.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-decode.c,v
retrieving revision 1.34
diff -r1.34 cli-decode.c
1541a1542,1550
> struct cmd_list_element *
> async_cmd (struct cmd_list_element *cmd, int f)
> {
> 
>     cmd->flags |= f;
> 
>   return cmd;
> }
> 
Index: gdb/cli/cli-decode.h
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-decode.h,v
retrieving revision 1.17
diff -r1.17 cli-decode.h
51a52,54
> #define ASYNC_OK                  0x08
> #define ASYNC_WAIT                0x10
> 





--- Daniel Jacobowitz <drow@mvista.com> wrote:
> On Fri, Nov 28, 2003 at 12:31:13PM -0500, Newman,
> Mark (N-Superior Technical Resource Inc) wrote:
> > Thanks Daniel;
> > 
> > Any other comments on the async changes?  
> 
> I asked for you to repost them using some readable
> format.  Describing
> changes is both inefficient and ambiguous.
> 
> > 
> >                                 Mark
> > 
> > > -----Original Message-----
> > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > Sent: Friday, November 28, 2003 12:28 PM
> > > To: Newman, Mark (N-Superior Technical Resource
> Inc)
> > > Cc: ankit thukral; Jim Blandy;
> gdb@sources.redhat.com
> > > Subject: Re: regarding transparent data ranges
> (in tracepoint support)
> > > 
> > > 
> > > On Fri, Nov 28, 2003 at 12:19:12PM -0500,
> Newman, Mark 
> > > (N-Superior Technical Resource Inc) wrote:
> > > > Could you be specific as to what kernel/file
> this is in?
> > > > 
> > > > I am using 2.4.18 and can't find it in
> kernel/ptrace.c .
> > > 
> > > That's your problem.  It was added around
> 2.5.38.
> > > 
> > > -- 
> > > Daniel Jacobowitz
> > > MontaVista Software                        
> Debian GNU/Linux Developer
> > > 
> > 
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian
> GNU/Linux Developer

Re: regarding transparent data ranges (in tracepoint support)

[Daniel Jacobowitz]

On Fri, Nov 28, 2003 at 05:29:52PM -0800, Mark Newman wrote:
> Here ya go - but I'll be darned if this is clearer.

You might want to read the original message to see what I meant :)
Or try gdb/CONTRIBUTE for directions.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: regarding transparent data ranges (in tracepoint support)

[Mark Newman]

I looked at gdb/CONTRIBUTE.  I hope that this meets
the requirements:

Change Log:

2003-11-28 Mark Newman <markn_46@yahoo.com>

   * provide a better method for filtering of asyn
commands




===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.122
diff -c -p -r1.122 infrun.c
*** gdb/infrun.c	25 Nov 2003 16:01:36 -0000	1.122
--- gdb/infrun.c	29 Nov 2003 02:00:15 -0000
***************
*** 44,49 ****
--- 44,51 ----
  #include "value.h"
  #include "observer.h"
  #include "language.h"
+ #include "cli/cli-decode.h"
+ 
  
  /* Prototypes for local functions */
  
*************** Pass and Stop may be combined.",
NULL));
*** 4005,4010 ****
--- 4007,4014 ----
        add_cmd ("stop", class_obscure,
not_just_help_class_command, "There is no `stop'
command, but you can set a hook on `stop'.\n\
  This allows you to set a list of commands to be run
each time execution\n\
  of the program stops.", &cmdlist);
+     async_cmd(stop_command , ASYNC_OK);
+ 
  
    numsigs = (int) TARGET_SIGNAL_LAST;
    signal_stop = (unsigned char *) xmalloc (sizeof
(signal_stop[0]) * numsigs);
Index: gdb/maint.c
===================================================================
RCS file: /cvs/src/src/gdb/maint.c,v
retrieving revision 1.40
diff -c -p -r1.40 maint.c
*** gdb/maint.c	21 Sep 2003 01:26:45 -0000	1.40
--- gdb/maint.c	29 Nov 2003 02:00:15 -0000
*************** Configure variables internal to GDB
that
*** 734,745 ****
  		  0/*allow-unknown*/,
  		  &maintenancelist);
  
!   add_prefix_cmd ("show", class_maintenance,
maintenance_show_cmd, "\
  Show GDB internal variables used by the GDB
maintainer.\n\
  Configure variables internal to GDB that aid in
GDB's maintenance",
  		  &maintenance_show_cmdlist, "maintenance show ",
  		  0/*allow-unknown*/,
! 		  &maintenancelist);
  
  #ifndef _WIN32
    add_cmd ("dump-me", class_maintenance,
maintenance_dump_me,
--- 734,746 ----
  		  0/*allow-unknown*/,
  		  &maintenancelist);
  
! async_cmd (  add_prefix_cmd ("show",
class_maintenance, maintenance_show_cmd, "\
  Show GDB internal variables used by the GDB
maintainer.\n\
  Configure variables internal to GDB that aid in
GDB's maintenance",
  		  &maintenance_show_cmdlist, "maintenance show ",
  		  0/*allow-unknown*/,
! 		  &maintenancelist)
! , ASYNC_OK);
  
  #ifndef _WIN32
    add_cmd ("dump-me", class_maintenance,
maintenance_dump_me,
Index: gdb/top.c
===================================================================
RCS file: /cvs/src/src/gdb/top.c,v
retrieving revision 1.85
diff -c -p -r1.85 top.c
*** gdb/top.c	8 Nov 2003 00:13:03 -0000	1.85
--- gdb/top.c	29 Nov 2003 02:00:19 -0000
*************** execute_command (char *p, int
from_tty)
*** 668,679 ****
  
        /* If the target is running, we allow only a
limited set of
           commands. */
!       if (event_loop_p && target_can_async_p () &&
target_executing)
! 	if (strcmp (c->name, "help") != 0
! 	    && strcmp (c->name, "pwd") != 0
! 	    && strcmp (c->name, "show") != 0
! 	    && strcmp (c->name, "stop") != 0)
! 	  error ("Cannot execute this command while the
target is running.");
  
        /* Pass null arg rather than an empty one.  */
        arg = *p ? p : 0;
--- 668,676 ----
  
        /* If the target is running, we allow only a
limited set of
           commands. */
!       if (event_loop_p && target_can_async_p () &&
target_executing) 
! 	     if ((c->flags & ASYNC_OK) != 0)
! 	        error ("Cannot execute this command while
the target is running.");
  
        /* Pass null arg rather than an empty one.  */
        arg = *p ? p : 0;
*************** execute_command (char *p, int
from_tty)
*** 747,752 ****
--- 744,757 ----
  	  warned = 1;
  	}
      }
+     
+     if (event_loop_p && target_can_async_p () &&
target_executing) {
+ 	if ((c->flags & ASYNC_WAIT) != 0) {
+ 	   wait_for_inferior();
+ 	  }
+       }
+ 
+ 
  }
  
  /* Read commands from `instream' and execute them
Index: gdb/cli/cli-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-cmds.c,v
retrieving revision 1.36
diff -c -p -r1.36 cli-cmds.c
*** gdb/cli/cli-cmds.c	8 Nov 2003 00:13:03 -0000	1.36
--- gdb/cli/cli-cmds.c	29 Nov 2003 02:00:20 -0000
*************** The commands below can be used to
select
*** 1056,1063 ****
  
    /* Define general commands. */
  
!   add_com ("pwd", class_files, pwd_command,
! 	"Print working directory.  This is used for your
program as well.");
    c = add_cmd ("cd", class_files, cd_command,
  	       "Set working directory to DIR for debugger
and program being debugged.\n\
  The change does not take effect for the program
being debugged\n\
--- 1056,1064 ----
  
    /* Define general commands. */
  
!   async_cmd(add_com ("pwd", class_files,
pwd_command,
! 	"Print working directory.  This is used for your
program as well.")
! , ASYNC_OK);
    c = add_cmd ("cd", class_files, cd_command,
  	       "Set working directory to DIR for debugger
and program being debugged.\n\
  The change does not take effect for the program
being debugged\n\
*************** when gdb is started.", &cmdlist);
*** 1091,1096 ****
--- 1092,1099 ----
  
    add_com ("quit", class_support, quit_command,
"Exit gdb.");
    c = add_com ("help", class_support, help_command,
"Print list of commands.");
+   async_cmd(c, ASYNC_OK);
+ 
    set_cmd_completer (c, command_completer);
    add_com_alias ("q", "quit", class_support, 1);
    add_com_alias ("h", "help", class_support, 1);
Index: gdb/cli/cli-decode.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-decode.c,v
retrieving revision 1.34
diff -c -p -r1.34 cli-decode.c
*** gdb/cli/cli-decode.c	8 Nov 2003 00:13:03 -0000
1.34
--- gdb/cli/cli-decode.c	29 Nov 2003 02:00:21 -0000
*************** cmd_func (struct cmd_list_element
*cmd, 
*** 1539,1542 ****
--- 1539,1551 ----
      error ("Invalid command");
  }
  
+ struct cmd_list_element *
+ async_cmd (struct cmd_list_element *cmd, int f)
+ {
+ 
+     cmd->flags |= f;
+ 
+   return cmd;
+ }
+ 
  
Index: gdb/cli/cli-decode.h
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-decode.h,v
retrieving revision 1.17
diff -c -p -r1.17 cli-decode.h
*** gdb/cli/cli-decode.h	14 Jan 2003 00:49:05 -0000
1.17
--- gdb/cli/cli-decode.h	29 Nov 2003 02:00:22 -0000
*************** cmd_types;
*** 49,54 ****
--- 49,57 ----
  #define CMD_DEPRECATED            0x1
  #define DEPRECATED_WARN_USER      0x2
  #define MALLOCED_REPLACEMENT      0x4
+ #define ASYNC_OK                  0x08
+ #define ASYNC_WAIT                0x10
+ 
  
  struct cmd_list_element
    {

--- Daniel Jacobowitz <drow@mvista.com> wrote:
> On Fri, Nov 28, 2003 at 05:29:52PM -0800, Mark
> Newman wrote:
> > Here ya go - but I'll be darned if this is
> clearer.
> 
> You might want to read the original message to see
> what I meant :)
> Or try gdb/CONTRIBUTE for directions.
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian
> GNU/Linux Developer

Re: regarding transparent data ranges (in tracepoint support)

[Daniel Jacobowitz]

On Fri, Nov 28, 2003 at 06:07:25PM -0800, Mark Newman wrote:
> I looked at gdb/CONTRIBUTE.  I hope that this meets
> the requirements:

Yes and no.  You definitely need to get a mail client which does not
wrap lines and mangle whitespace: take a look at how it came out below.

> Change Log:
> 
> 2003-11-28 Mark Newman <markn_46@yahoo.com>
> 
>    * provide a better method for filtering of asyn
> commands

You may also want to read the GNU Coding Standards (or just browse
gdb/ChangeLog) to get an idea for what a changelog entry ought to look
like.

Beyond that the concept looks reasonable.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: regarding transparent data ranges (in tracepoint support)

[Newman, Mark (N-Superior Technical Resource Inc)]

Could you be specific as to what kernel/file this is in?

I am using 2.4.18 and can't find it in kernel/ptrace.c .

                               Mark Newman

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Wednesday, November 19, 2003 3:22 PM
> To: Newman, Mark (N-Superior Technical Resource Inc)
> Cc: ankit thukral; Jim Blandy; gdb@sources.redhat.com
> Subject: Re: regarding transparent data ranges (in tracepoint support)
> 
> 
> On Wed, Nov 19, 2003 at 02:50:29PM -0500, Newman, Mark 
> (N-Superior Technical Resource Inc) wrote:
> > Sorry about the tunnel vision.  When the SUT exits we loose 
> all of the
> > tracepoint data in target memory. Stopping that from 
> happening is the
> > next thing on my list after I finish making interrupt work. 
>  After the
> > program finishes it should not exit without an ok from the engineer.
> > 
> > So Ankit if that is what you are looking to do I agree completely.
> > However can't gdbserver do something more like the restart 
> that occurs
> > with a "w" or "x" status after the putpkt in the case statement in
> > server.c
> 
> For recent Linux kernels see PTRACE_EVENT_EXIT.
> 
> In general, however, there's no easy way to prevent it from exiting
> without that.
> 
> > 
> >                                            Mark
> > 
> > > -----Original Message-----
> > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > Sent: Wednesday, November 19, 2003 2:39 PM
> > > To: Newman, Mark (N-Superior Technical Resource Inc)
> > > Cc: ankit thukral; Jim Blandy; gdb@sources.redhat.com
> > > Subject: Re: regarding transparent data ranges (in 
> tracepoint support)
> > > 
> > > 
> > > On Wed, Nov 19, 2003 at 02:34:49PM -0500, Newman, Mark 
> > > (N-Superior Technical Resource Inc) wrote:
> > > > Guys - again please excuse my ignorance but
> > > > 
> > > > I was assuming that transparent memory would either be
> > > > 
> > > > In ROM
> > > > In a write protected page
> > > > In an unprotected page (for those systems without 
> memory protection)
> > > > Possibly swapped out to the disk (for those system with a disk)
> > > > 
> > > > However definitely readable by "read_inferior_memory".
> > > > 
> > > > Why would the data not be loaded into some form of memory?  
> > > > What kind of data are we talking about?
> > > 
> > > Ankit is talking about reading the transparant tracepoint 
> data after
> > > the program has exited - when its memory isn't there any more.
> > > 
> > > > 
> > > >                              Mark Newman
> > > > 
> > > > > -----Original Message-----
> > > > > From: gdb-owner@sources.redhat.com
> > > > > [mailto:gdb-owner@sources.redhat.com]On Behalf Of Daniel 
> > > Jacobowitz
> > > > > Sent: Wednesday, November 19, 2003 1:56 PM
> > > > > To: ankit thukral
> > > > > Cc: Jim Blandy; gdb@sources.redhat.com
> > > > > Subject: Re: regarding transparent data ranges (in 
> > > tracepoint support)
> > > > > 
> > > > > 
> > > > > On Wed, Nov 19, 2003 at 08:25:37AM -0800, ankit thukral wrote:
> > > > > > 
> > > > > > --- Jim Blandy <jimb@redhat.com> wrote:
> > > > > > > 
> > > > > > > ankit thukral <ankit_plug@yahoo.com> writes:
> > > > > > > 
> > > > > > > > hi all,
> > > > > > > >      i read about the transparent data ranges and
> > > > > > > > learned that data in these ranges are not supposed
> > > > > > > to
> > > > > > > > be collected by the remote stub since they belong
> > > > > > > to
> > > > > > > > read-only segment of the debuggee.my problem is :
> > > > > > > a
> > > > > > > > TSTART would start the debuggee and it may so
> > > > > > > happen
> > > > > > > > that the debuggee finishes executing.at this
> > > > > > > point,if
> > > > > > > > the GDB requests for some data in the transparent
> > > > > > > data
> > > > > > > > range,then how can the remote stub provide it with
> > > > > > > one
> > > > > > > > since the debuggee has exited ?
> > > > > > > 
> > > > > > > If the target is a gdbserver, then it would need to
> > > > > > > read the bytes
> > > > > > > from the executable file.  This is easy to do with
> > > > > > > BFD, but if I
> > > > > > > remember right, gdbserver doesn't use BFD at the
> > > > > > > moment; not sure how
> > > > > > > to get around that.
> > > > > > > 
> > > > > > > If the target is an embedded system, then presumably
> > > > > > > the transparent
> > > > > > > data ranges correspond to ROM regions, so the data
> > > > > > > is still there.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >   how about setting a (internal) breakpoint in the
> > > > > > debuggee which would prevent it from exiting even
> > > > > > though it has finished executing main(),and then
> > > > > > entertain GDB requests for the transparent (or
> > > > > > read-only) memory regions by reading from the memory
> > > > > > of the debuggee???
> > > > > 
> > > > > That would work (but be wasteful).  At least on Linux, 
> > > you could read
> > > > > /proc/pid/maps to find what ranges correspond to where in 
> > > what file,
> > > > > and save that information.
> > > > > 
> > > > > -- 
> > > > > Daniel Jacobowitz
> > > > > MontaVista Software                         Debian 
> > > GNU/Linux Developer
> > > > > 
> > > > 
> > > 
> > > -- 
> > > Daniel Jacobowitz
> > > MontaVista Software                         Debian 
> GNU/Linux Developer
> > > 
> > 
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 

Re: regarding transparent data ranges (in tracepoint support)

[Daniel Jacobowitz]

On Fri, Nov 28, 2003 at 12:19:12PM -0500, Newman, Mark (N-Superior Technical Resource Inc) wrote:
> Could you be specific as to what kernel/file this is in?
> 
> I am using 2.4.18 and can't find it in kernel/ptrace.c .

That's your problem.  It was added around 2.5.38.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: regarding transparent data ranges (in tracepoint support)

[Newman, Mark (N-Superior Technical Resource Inc)]

Ankit 

How is it going?  I am at a point now where I need to start looking at
this if you aren't.

                                         Mark

> -----Original Message-----
> From: ankit thukral [mailto:ankit_plug@yahoo.com]
> Sent: Thursday, November 20, 2003 12:01 AM
> To: Newman, Mark (N-Superior Technical Resource Inc); Daniel 
> Jacobowitz
> Cc: ankit thukral; Jim Blandy; gdb@sources.redhat.com
> Subject: RE: regarding transparent data ranges (in tracepoint support)
> 
> 
> 
> --- "Newman, Mark (N-Superior Technical Resource Inc)"
> <mark.newman@lmco.com> wrote:
> > Sorry about the tunnel vision.  When the SUT exits
> > we loose all of the
> > tracepoint data in target memory. Stopping that from
> > happening is the
> > next thing on my list after I finish making
> > interrupt work.  After the
> > program finishes it should not exit without an ok
> > from the engineer.
> > 
> > So Ankit if that is what you are looking to do I
> > agree completely.
> > However can't gdbserver do something more like the
> > restart that occurs
> > with a "w" or "x" status after the putpkt in the
> > case statement in
> > server.c
> > 
> >                                            Mark
> > 
> 
> 
>    thanks for the solution Mark.restarting the
> debuggee would surely work,just that some overhead may
> be involved.but it sort of gives me a feeling of
> hacking around the solution since the debuggee would
> be run twice,2'nd time just for the transparent data
> ranges. thanks for the solution anyway.
>   any comments on PTRACE_EVENT_EXIT ??
> 
> Ankit.
> 
> __________________________________
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
> 

RE: regarding transparent data ranges (in tracepoint support)

[Newman, Mark (N-Superior Technical Resource Inc)]

Ankit -

I fixed the problem with interrupt and am going to start on the same
thing that you are looking at.

Monday I will post the proposed changes for the "interrupt" command.

I don't want to duplicate what you are doing so how are things going
with what you are doing?

                                       Mark

> -----Original Message-----
> From: ankit thukral [mailto:ankit_plug@yahoo.com]
> Sent: Thursday, November 20, 2003 12:01 AM
> To: Newman, Mark (N-Superior Technical Resource Inc); Daniel 
> Jacobowitz
> Cc: ankit thukral; Jim Blandy; gdb@sources.redhat.com
> Subject: RE: regarding transparent data ranges (in tracepoint support)
> 
> 
> 
> --- "Newman, Mark (N-Superior Technical Resource Inc)"
> <mark.newman@lmco.com> wrote:
> > Sorry about the tunnel vision.  When the SUT exits
> > we loose all of the
> > tracepoint data in target memory. Stopping that from
> > happening is the
> > next thing on my list after I finish making
> > interrupt work.  After the
> > program finishes it should not exit without an ok
> > from the engineer.
> > 
> > So Ankit if that is what you are looking to do I
> > agree completely.
> > However can't gdbserver do something more like the
> > restart that occurs
> > with a "w" or "x" status after the putpkt in the
> > case statement in
> > server.c
> > 
> >                                            Mark
> > 
> 
> 
>    thanks for the solution Mark.restarting the
> debuggee would surely work,just that some overhead may
> be involved.but it sort of gives me a feeling of
> hacking around the solution since the debuggee would
> be run twice,2'nd time just for the transparent data
> ranges. thanks for the solution anyway.
>   any comments on PTRACE_EVENT_EXIT ??
> 
> Ankit.
> 
> __________________________________
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
> 

RE: regarding transparent data ranges (in tracepoint support)

[Newman, Mark (N-Superior Technical Resource Inc)]

Sorry about the tunnel vision.  When the SUT exits we loose all of the
tracepoint data in target memory. Stopping that from happening is the
next thing on my list after I finish making interrupt work.  After the
program finishes it should not exit without an ok from the engineer.

So Ankit if that is what you are looking to do I agree completely.
However can't gdbserver do something more like the restart that occurs
with a "w" or "x" status after the putpkt in the case statement in
server.c

                                           Mark

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Wednesday, November 19, 2003 2:39 PM
> To: Newman, Mark (N-Superior Technical Resource Inc)
> Cc: ankit thukral; Jim Blandy; gdb@sources.redhat.com
> Subject: Re: regarding transparent data ranges (in tracepoint support)
> 
> 
> On Wed, Nov 19, 2003 at 02:34:49PM -0500, Newman, Mark 
> (N-Superior Technical Resource Inc) wrote:
> > Guys - again please excuse my ignorance but
> > 
> > I was assuming that transparent memory would either be
> > 
> > In ROM
> > In a write protected page
> > In an unprotected page (for those systems without memory protection)
> > Possibly swapped out to the disk (for those system with a disk)
> > 
> > However definitely readable by "read_inferior_memory".
> > 
> > Why would the data not be loaded into some form of memory?  
> > What kind of data are we talking about?
> 
> Ankit is talking about reading the transparant tracepoint data after
> the program has exited - when its memory isn't there any more.
> 
> > 
> >                              Mark Newman
> > 
> > > -----Original Message-----
> > > From: gdb-owner@sources.redhat.com
> > > [mailto:gdb-owner@sources.redhat.com]On Behalf Of Daniel 
> Jacobowitz
> > > Sent: Wednesday, November 19, 2003 1:56 PM
> > > To: ankit thukral
> > > Cc: Jim Blandy; gdb@sources.redhat.com
> > > Subject: Re: regarding transparent data ranges (in 
> tracepoint support)
> > > 
> > > 
> > > On Wed, Nov 19, 2003 at 08:25:37AM -0800, ankit thukral wrote:
> > > > 
> > > > --- Jim Blandy <jimb@redhat.com> wrote:
> > > > > 
> > > > > ankit thukral <ankit_plug@yahoo.com> writes:
> > > > > 
> > > > > > hi all,
> > > > > >      i read about the transparent data ranges and
> > > > > > learned that data in these ranges are not supposed
> > > > > to
> > > > > > be collected by the remote stub since they belong
> > > > > to
> > > > > > read-only segment of the debuggee.my problem is :
> > > > > a
> > > > > > TSTART would start the debuggee and it may so
> > > > > happen
> > > > > > that the debuggee finishes executing.at this
> > > > > point,if
> > > > > > the GDB requests for some data in the transparent
> > > > > data
> > > > > > range,then how can the remote stub provide it with
> > > > > one
> > > > > > since the debuggee has exited ?
> > > > > 
> > > > > If the target is a gdbserver, then it would need to
> > > > > read the bytes
> > > > > from the executable file.  This is easy to do with
> > > > > BFD, but if I
> > > > > remember right, gdbserver doesn't use BFD at the
> > > > > moment; not sure how
> > > > > to get around that.
> > > > > 
> > > > > If the target is an embedded system, then presumably
> > > > > the transparent
> > > > > data ranges correspond to ROM regions, so the data
> > > > > is still there.
> > > > 
> > > > 
> > > > 
> > > >   how about setting a (internal) breakpoint in the
> > > > debuggee which would prevent it from exiting even
> > > > though it has finished executing main(),and then
> > > > entertain GDB requests for the transparent (or
> > > > read-only) memory regions by reading from the memory
> > > > of the debuggee???
> > > 
> > > That would work (but be wasteful).  At least on Linux, 
> you could read
> > > /proc/pid/maps to find what ranges correspond to where in 
> what file,
> > > and save that information.
> > > 
> > > -- 
> > > Daniel Jacobowitz
> > > MontaVista Software                         Debian 
> GNU/Linux Developer
> > > 
> > 
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 

Re: regarding transparent data ranges (in tracepoint support)

[Daniel Jacobowitz]

On Wed, Nov 19, 2003 at 02:50:29PM -0500, Newman, Mark (N-Superior Technical Resource Inc) wrote:
> Sorry about the tunnel vision.  When the SUT exits we loose all of the
> tracepoint data in target memory. Stopping that from happening is the
> next thing on my list after I finish making interrupt work.  After the
> program finishes it should not exit without an ok from the engineer.
> 
> So Ankit if that is what you are looking to do I agree completely.
> However can't gdbserver do something more like the restart that occurs
> with a "w" or "x" status after the putpkt in the case statement in
> server.c

For recent Linux kernels see PTRACE_EVENT_EXIT.

In general, however, there's no easy way to prevent it from exiting
without that.

> 
>                                            Mark
> 
> > -----Original Message-----
> > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > Sent: Wednesday, November 19, 2003 2:39 PM
> > To: Newman, Mark (N-Superior Technical Resource Inc)
> > Cc: ankit thukral; Jim Blandy; gdb@sources.redhat.com
> > Subject: Re: regarding transparent data ranges (in tracepoint support)
> > 
> > 
> > On Wed, Nov 19, 2003 at 02:34:49PM -0500, Newman, Mark 
> > (N-Superior Technical Resource Inc) wrote:
> > > Guys - again please excuse my ignorance but
> > > 
> > > I was assuming that transparent memory would either be
> > > 
> > > In ROM
> > > In a write protected page
> > > In an unprotected page (for those systems without memory protection)
> > > Possibly swapped out to the disk (for those system with a disk)
> > > 
> > > However definitely readable by "read_inferior_memory".
> > > 
> > > Why would the data not be loaded into some form of memory?  
> > > What kind of data are we talking about?
> > 
> > Ankit is talking about reading the transparant tracepoint data after
> > the program has exited - when its memory isn't there any more.
> > 
> > > 
> > >                              Mark Newman
> > > 
> > > > -----Original Message-----
> > > > From: gdb-owner@sources.redhat.com
> > > > [mailto:gdb-owner@sources.redhat.com]On Behalf Of Daniel 
> > Jacobowitz
> > > > Sent: Wednesday, November 19, 2003 1:56 PM
> > > > To: ankit thukral
> > > > Cc: Jim Blandy; gdb@sources.redhat.com
> > > > Subject: Re: regarding transparent data ranges (in 
> > tracepoint support)
> > > > 
> > > > 
> > > > On Wed, Nov 19, 2003 at 08:25:37AM -0800, ankit thukral wrote:
> > > > > 
> > > > > --- Jim Blandy <jimb@redhat.com> wrote:
> > > > > > 
> > > > > > ankit thukral <ankit_plug@yahoo.com> writes:
> > > > > > 
> > > > > > > hi all,
> > > > > > >      i read about the transparent data ranges and
> > > > > > > learned that data in these ranges are not supposed
> > > > > > to
> > > > > > > be collected by the remote stub since they belong
> > > > > > to
> > > > > > > read-only segment of the debuggee.my problem is :
> > > > > > a
> > > > > > > TSTART would start the debuggee and it may so
> > > > > > happen
> > > > > > > that the debuggee finishes executing.at this
> > > > > > point,if
> > > > > > > the GDB requests for some data in the transparent
> > > > > > data
> > > > > > > range,then how can the remote stub provide it with
> > > > > > one
> > > > > > > since the debuggee has exited ?
> > > > > > 
> > > > > > If the target is a gdbserver, then it would need to
> > > > > > read the bytes
> > > > > > from the executable file.  This is easy to do with
> > > > > > BFD, but if I
> > > > > > remember right, gdbserver doesn't use BFD at the
> > > > > > moment; not sure how
> > > > > > to get around that.
> > > > > > 
> > > > > > If the target is an embedded system, then presumably
> > > > > > the transparent
> > > > > > data ranges correspond to ROM regions, so the data
> > > > > > is still there.
> > > > > 
> > > > > 
> > > > > 
> > > > >   how about setting a (internal) breakpoint in the
> > > > > debuggee which would prevent it from exiting even
> > > > > though it has finished executing main(),and then
> > > > > entertain GDB requests for the transparent (or
> > > > > read-only) memory regions by reading from the memory
> > > > > of the debuggee???
> > > > 
> > > > That would work (but be wasteful).  At least on Linux, 
> > you could read
> > > > /proc/pid/maps to find what ranges correspond to where in 
> > what file,
> > > > and save that information.
> > > > 
> > > > -- 
> > > > Daniel Jacobowitz
> > > > MontaVista Software                         Debian 
> > GNU/Linux Developer
> > > > 
> > > 
> > 
> > -- 
> > Daniel Jacobowitz
> > MontaVista Software                         Debian GNU/Linux Developer
> > 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: regarding transparent data ranges (in tracepoint support)

[ankit thukral]

--- "Newman, Mark (N-Superior Technical Resource Inc)"
<mark.newman@lmco.com> wrote:
> Sorry about the tunnel vision.  When the SUT exits
> we loose all of the
> tracepoint data in target memory. Stopping that from
> happening is the
> next thing on my list after I finish making
> interrupt work.  After the
> program finishes it should not exit without an ok
> from the engineer.
> 
> So Ankit if that is what you are looking to do I
> agree completely.
> However can't gdbserver do something more like the
> restart that occurs
> with a "w" or "x" status after the putpkt in the
> case statement in
> server.c
> 
>                                            Mark
> 


   thanks for the solution Mark.restarting the
debuggee would surely work,just that some overhead may
be involved.but it sort of gives me a feeling of
hacking around the solution since the debuggee would
be run twice,2'nd time just for the transparent data
ranges. thanks for the solution anyway.
  any comments on PTRACE_EVENT_EXIT ??

Ankit.

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

RE: regarding transparent data ranges (in tracepoint support)

[Newman, Mark (N-Superior Technical Resource Inc)]

Guys - again please excuse my ignorance but

I was assuming that transparent memory would either be

In ROM
In a write protected page
In an unprotected page (for those systems without memory protection)
Possibly swapped out to the disk (for those system with a disk)

However definitely readable by "read_inferior_memory".

Why would the data not be loaded into some form of memory?  
What kind of data are we talking about?

                             Mark Newman

> -----Original Message-----
> From: gdb-owner@sources.redhat.com
> [mailto:gdb-owner@sources.redhat.com]On Behalf Of Daniel Jacobowitz
> Sent: Wednesday, November 19, 2003 1:56 PM
> To: ankit thukral
> Cc: Jim Blandy; gdb@sources.redhat.com
> Subject: Re: regarding transparent data ranges (in tracepoint support)
> 
> 
> On Wed, Nov 19, 2003 at 08:25:37AM -0800, ankit thukral wrote:
> > 
> > --- Jim Blandy <jimb@redhat.com> wrote:
> > > 
> > > ankit thukral <ankit_plug@yahoo.com> writes:
> > > 
> > > > hi all,
> > > >      i read about the transparent data ranges and
> > > > learned that data in these ranges are not supposed
> > > to
> > > > be collected by the remote stub since they belong
> > > to
> > > > read-only segment of the debuggee.my problem is :
> > > a
> > > > TSTART would start the debuggee and it may so
> > > happen
> > > > that the debuggee finishes executing.at this
> > > point,if
> > > > the GDB requests for some data in the transparent
> > > data
> > > > range,then how can the remote stub provide it with
> > > one
> > > > since the debuggee has exited ?
> > > 
> > > If the target is a gdbserver, then it would need to
> > > read the bytes
> > > from the executable file.  This is easy to do with
> > > BFD, but if I
> > > remember right, gdbserver doesn't use BFD at the
> > > moment; not sure how
> > > to get around that.
> > > 
> > > If the target is an embedded system, then presumably
> > > the transparent
> > > data ranges correspond to ROM regions, so the data
> > > is still there.
> > 
> > 
> > 
> >   how about setting a (internal) breakpoint in the
> > debuggee which would prevent it from exiting even
> > though it has finished executing main(),and then
> > entertain GDB requests for the transparent (or
> > read-only) memory regions by reading from the memory
> > of the debuggee???
> 
> That would work (but be wasteful).  At least on Linux, you could read
> /proc/pid/maps to find what ranges correspond to where in what file,
> and save that information.
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 

Re: regarding transparent data ranges (in tracepoint support)

[Daniel Jacobowitz]

On Wed, Nov 19, 2003 at 02:34:49PM -0500, Newman, Mark (N-Superior Technical Resource Inc) wrote:
> Guys - again please excuse my ignorance but
> 
> I was assuming that transparent memory would either be
> 
> In ROM
> In a write protected page
> In an unprotected page (for those systems without memory protection)
> Possibly swapped out to the disk (for those system with a disk)
> 
> However definitely readable by "read_inferior_memory".
> 
> Why would the data not be loaded into some form of memory?  
> What kind of data are we talking about?

Ankit is talking about reading the transparant tracepoint data after
the program has exited - when its memory isn't there any more.

> 
>                              Mark Newman
> 
> > -----Original Message-----
> > From: gdb-owner@sources.redhat.com
> > [mailto:gdb-owner@sources.redhat.com]On Behalf Of Daniel Jacobowitz
> > Sent: Wednesday, November 19, 2003 1:56 PM
> > To: ankit thukral
> > Cc: Jim Blandy; gdb@sources.redhat.com
> > Subject: Re: regarding transparent data ranges (in tracepoint support)
> > 
> > 
> > On Wed, Nov 19, 2003 at 08:25:37AM -0800, ankit thukral wrote:
> > > 
> > > --- Jim Blandy <jimb@redhat.com> wrote:
> > > > 
> > > > ankit thukral <ankit_plug@yahoo.com> writes:
> > > > 
> > > > > hi all,
> > > > >      i read about the transparent data ranges and
> > > > > learned that data in these ranges are not supposed
> > > > to
> > > > > be collected by the remote stub since they belong
> > > > to
> > > > > read-only segment of the debuggee.my problem is :
> > > > a
> > > > > TSTART would start the debuggee and it may so
> > > > happen
> > > > > that the debuggee finishes executing.at this
> > > > point,if
> > > > > the GDB requests for some data in the transparent
> > > > data
> > > > > range,then how can the remote stub provide it with
> > > > one
> > > > > since the debuggee has exited ?
> > > > 
> > > > If the target is a gdbserver, then it would need to
> > > > read the bytes
> > > > from the executable file.  This is easy to do with
> > > > BFD, but if I
> > > > remember right, gdbserver doesn't use BFD at the
> > > > moment; not sure how
> > > > to get around that.
> > > > 
> > > > If the target is an embedded system, then presumably
> > > > the transparent
> > > > data ranges correspond to ROM regions, so the data
> > > > is still there.
> > > 
> > > 
> > > 
> > >   how about setting a (internal) breakpoint in the
> > > debuggee which would prevent it from exiting even
> > > though it has finished executing main(),and then
> > > entertain GDB requests for the transparent (or
> > > read-only) memory regions by reading from the memory
> > > of the debuggee???
> > 
> > That would work (but be wasteful).  At least on Linux, you could read
> > /proc/pid/maps to find what ranges correspond to where in what file,
> > and save that information.
> > 
> > -- 
> > Daniel Jacobowitz
> > MontaVista Software                         Debian GNU/Linux Developer
> > 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

async operation

[Newman, Mark (N-Superior Technical Resource Inc)]

Is there anyway to cleanly stop a remote target manually when in async mode.

I tried using the "stop" command which makes it through the async filtering in top.c - however stop simply says it is not a valid command.  There is logic in here for cleanly stopping when a break occurs (?) but I can't find any to allow the operator to stop the target?

I add'ed "interrupt" to the filtering but it does not clear the target_executing flag.

                                                                   Mark Newman

regarding transparent data ranges (in tracepoint support)

[ankit thukral]

hi all,
     i read about the transparent data ranges and
learned that data in these ranges are not supposed to
be collected by the remote stub since they belong to
read-only segment of the debuggee.my problem is : a
TSTART would start the debuggee and it may so happen
that the debuggee finishes executing.at this point,if
the GDB requests for some data in the transparent data
range,then how can the remote stub provide it with one
since the debuggee has exited ?
      i think the debuggee needs to be stopped after
main() has finished .this may be achieved by setting
an internal breakpoint somewhere (i have no idea
where).or may be something else.
      any ideas or suggestions??


thanks in advance,
ankit.

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: regarding transparent data ranges (in tracepoint support)

[Jim Blandy]

ankit thukral <ankit_plug@yahoo.com> writes:

> hi all,
>      i read about the transparent data ranges and
> learned that data in these ranges are not supposed to
> be collected by the remote stub since they belong to
> read-only segment of the debuggee.my problem is : a
> TSTART would start the debuggee and it may so happen
> that the debuggee finishes executing.at this point,if
> the GDB requests for some data in the transparent data
> range,then how can the remote stub provide it with one
> since the debuggee has exited ?

If the target is a gdbserver, then it would need to read the bytes
from the executable file.  This is easy to do with BFD, but if I
remember right, gdbserver doesn't use BFD at the moment; not sure how
to get around that.

If the target is an embedded system, then presumably the transparent
data ranges correspond to ROM regions, so the data is still there.

Re: regarding transparent data ranges (in tracepoint support)

[ankit thukral]

--- Jim Blandy <jimb@redhat.com> wrote:
> 
> ankit thukral <ankit_plug@yahoo.com> writes:
> 
> > hi all,
> >      i read about the transparent data ranges and
> > learned that data in these ranges are not supposed
> to
> > be collected by the remote stub since they belong
> to
> > read-only segment of the debuggee.my problem is :
> a
> > TSTART would start the debuggee and it may so
> happen
> > that the debuggee finishes executing.at this
> point,if
> > the GDB requests for some data in the transparent
> data
> > range,then how can the remote stub provide it with
> one
> > since the debuggee has exited ?
> 
> If the target is a gdbserver, then it would need to
> read the bytes
> from the executable file.  This is easy to do with
> BFD, but if I
> remember right, gdbserver doesn't use BFD at the
> moment; not sure how
> to get around that.
> 
> If the target is an embedded system, then presumably
> the transparent
> data ranges correspond to ROM regions, so the data
> is still there.



  how about setting a (internal) breakpoint in the
debuggee which would prevent it from exiting even
though it has finished executing main(),and then
entertain GDB requests for the transparent (or
read-only) memory regions by reading from the memory
of the debuggee???




__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: regarding transparent data ranges (in tracepoint support)

[Daniel Jacobowitz]

On Wed, Nov 19, 2003 at 08:25:37AM -0800, ankit thukral wrote:
> 
> --- Jim Blandy <jimb@redhat.com> wrote:
> > 
> > ankit thukral <ankit_plug@yahoo.com> writes:
> > 
> > > hi all,
> > >      i read about the transparent data ranges and
> > > learned that data in these ranges are not supposed
> > to
> > > be collected by the remote stub since they belong
> > to
> > > read-only segment of the debuggee.my problem is :
> > a
> > > TSTART would start the debuggee and it may so
> > happen
> > > that the debuggee finishes executing.at this
> > point,if
> > > the GDB requests for some data in the transparent
> > data
> > > range,then how can the remote stub provide it with
> > one
> > > since the debuggee has exited ?
> > 
> > If the target is a gdbserver, then it would need to
> > read the bytes
> > from the executable file.  This is easy to do with
> > BFD, but if I
> > remember right, gdbserver doesn't use BFD at the
> > moment; not sure how
> > to get around that.
> > 
> > If the target is an embedded system, then presumably
> > the transparent
> > data ranges correspond to ROM regions, so the data
> > is still there.
> 
> 
> 
>   how about setting a (internal) breakpoint in the
> debuggee which would prevent it from exiting even
> though it has finished executing main(),and then
> entertain GDB requests for the transparent (or
> read-only) memory regions by reading from the memory
> of the debuggee???

That would work (but be wasteful).  At least on Linux, you could read
/proc/pid/maps to find what ranges correspond to where in what file,
and save that information.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer