RE: System calls debugging

RE: System calls debugging

[Kotian, Deepak]

Will strace command for you ?


-----Original Message-----
From: MuthuKumar-Hotpop [mailto:kmuthu_linux@HotPOP.com]
Sent: Wednesday, February 11, 2004 9:19 AM
Cc: gdb@sources.redhat.com
Subject: System calls debugging



Hello deBUGies,

        Is there any way to debug what are all the "system calls" usage and process happening over on the program.

        I have written a simple program which gets the a string.I have made it to wait for the input and using that process-id,
        I have attached the process with gdb.Now the "where" command gives the stackframes about the system calls information.
        To find the processings of other system calls what is the way.  
             
Regards,
Muthu.

Re: System calls debugging

[Andrew Cagney]

> Will strace command for you ?

BTW, a wish-list item is for GDB to directly include strace support.

enjoy,
Andrew


> -----Original Message-----
> From: MuthuKumar-Hotpop [mailto:kmuthu_linux@HotPOP.com]
> Sent: Wednesday, February 11, 2004 9:19 AM
> Cc: gdb@sources.redhat.com
> Subject: System calls debugging
> 
> 
> 
> Hello deBUGies,
> 
>         Is there any way to debug what are all the "system calls" usage and process happening over on the program.
> 
>         I have written a simple program which gets the a string.I have made it to wait for the input and using that process-id,
>         I have attached the process with gdb.Now the "where" command gives the stackframes about the system calls information.
>         To find the processings of other system calls what is the way.  
>              
> Regards,
> Muthu.
> 
> 
> 

Re: System calls debugging

[Kip Macy]

What would that look like?
Would you just type
(gdb) strace <args>

and have it print out what strace does now while it runs,
or do you have something more in mind?


		-Kip

On Wed, 11 Feb 2004, Andrew Cagney wrote:

> > Will strace command for you ?
>
> BTW, a wish-list item is for GDB to directly include strace support.
>
> enjoy,
> Andrew
>
>
> > -----Original Message-----
> > From: MuthuKumar-Hotpop [mailto:kmuthu_linux@HotPOP.com]
> > Sent: Wednesday, February 11, 2004 9:19 AM
> > Cc: gdb@sources.redhat.com
> > Subject: System calls debugging
> >
> >
> >
> > Hello deBUGies,
> >
> >         Is there any way to debug what are all the "system calls" usage and process happening over on the program.
> >
> >         I have written a simple program which gets the a string.I have made it to wait for the input and using that process-id,
> >         I have attached the process with gdb.Now the "where" command gives the stackframes about the system calls information.
> >         To find the processings of other system calls what is the way.
> >
> > Regards,
> > Muthu.
> >
> >
> >
>
>
>

Re: System calls debugging

[Andrew Cagney]

> ld you just type
> (gdb) strace <args>
> 
> and have it print out what strace does now while it runs,
> or do you have something more in mind?

who knows, something like:

(gdb) {set,show} strace <see help handle>

or

(gdb) catch syscall all
Catch point 5 created
(gdb) commands 5
silent
backtrace
continue
end
(gdb)

(and don't get me started about that "silent" "feature" :-)

Andrew

Re: System calls debugging

[Muthukumar]

Hai all,

Regarding to the system calls debuggin,in linux using the process id 
of the debugging file with strace we can find.

In HP-UNIX ,how we can trace the system calls with the GDB support.

Regards,
Muthu.

RE: System calls debugging

[Kotian, Deepak]

Please try tusc command, not sure if it is there by default.

-----Original Message-----
From: Muthukumar [mailto:kmuthu_linux@HotPOP.com]
Sent: Thursday, February 12, 2004 4:58 PM
To: Andrew Cagney; Kip Macy
Cc: gdb@sources.redhat.com
Subject: Re: System calls debugging



Hai all,

Regarding to the system calls debuggin,in linux using the process id 
of the debugging file with strace we can find.

In HP-UNIX ,how we can trace the system calls with the GDB support.

Regards,
Muthu.

Pending breakpoints and scripts

[Andrew Cagney]

Anyone noticed this?

(top-gdb) run testsuite/gdb.base/advance
Starting program: ...
Setting up the environment for debugging gdb.
Function "internal_error" not defined.
Breakpoint 1 (internal_error) pending.
Function "info_command" not defined.
Breakpoint 2 (info_command) pending.
(top-gdb)

It's caused by this:

           if (!query ("Make breakpoint pending on future shared library 
load? ")
)
             return rc;

The old behavior was: when in batch mode, throw an error (and hence 
abandon the script) if the breakpoint insert fails.

The new behavior is: when in batch mode, always insert the breakpoint. 
when not in batch mode never throw an error.

For the existing behavior to be restored the query's logic would need to 
be reversed (ask the oposite question) and then re-throw the error.  A 
/pending qualifier could then be added.

Thoughts?
Andrew

Re: Pending breakpoints and scripts

[Daniel Jacobowitz]

On Mon, Feb 09, 2004 at 03:02:19PM -0500, Andrew Cagney wrote:
> Anyone noticed this?
> 
> (top-gdb) run testsuite/gdb.base/advance
> Starting program: ...
> Setting up the environment for debugging gdb.
> Function "internal_error" not defined.
> Breakpoint 1 (internal_error) pending.
> Function "info_command" not defined.
> Breakpoint 2 (info_command) pending.
> (top-gdb)
> 
> It's caused by this:
> 
>           if (!query ("Make breakpoint pending on future shared library 
> load? ")
> )
>             return rc;
> 
> The old behavior was: when in batch mode, throw an error (and hence 
> abandon the script) if the breakpoint insert fails.
> 
> The new behavior is: when in batch mode, always insert the breakpoint. 
> when not in batch mode never throw an error.
> 
> For the existing behavior to be restored the query's logic would need to 
> be reversed (ask the oposite question) and then re-throw the error.  A 
> /pending qualifier could then be added.
> 
> Thoughts?

I'd rather not reverse the question.  We could check from_tty at the
call site, and not set pending breakpoints if no tty...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Pending breakpoints and scripts

[Andrew Cagney]

> On Mon, Feb 09, 2004 at 03:02:19PM -0500, Andrew Cagney wrote:
> 
>> Anyone noticed this?
>> 
>> (top-gdb) run testsuite/gdb.base/advance
>> Starting program: ...
>> Setting up the environment for debugging gdb.
>> Function "internal_error" not defined.
>> Breakpoint 1 (internal_error) pending.
>> Function "info_command" not defined.
>> Breakpoint 2 (info_command) pending.
>> (top-gdb)
>> 
>> It's caused by this:
>> 
>>           if (!query ("Make breakpoint pending on future shared library 
>> load? ")
>> )
>>             return rc;
>> 
>> The old behavior was: when in batch mode, throw an error (and hence 
>> abandon the script) if the breakpoint insert fails.
>> 
>> The new behavior is: when in batch mode, always insert the breakpoint. 
>> when not in batch mode never throw an error.
>> 
>> For the existing behavior to be restored the query's logic would need to 
>> be reversed (ask the oposite question) and then re-throw the error.  A 
>> /pending qualifier could then be added.
>> 
>> Thoughts?
> 
> 
> I'd rather not reverse the question.  We could check from_tty at the
> call site, and not set pending breakpoints if no tty...

Why?

Re: Pending breakpoints and scripts

[Daniel Jacobowitz]

On Tue, Feb 10, 2004 at 04:22:41PM -0500, Andrew Cagney wrote:
> >On Mon, Feb 09, 2004 at 03:02:19PM -0500, Andrew Cagney wrote:
> >
> >>Anyone noticed this?
> >>
> >>(top-gdb) run testsuite/gdb.base/advance
> >>Starting program: ...
> >>Setting up the environment for debugging gdb.
> >>Function "internal_error" not defined.
> >>Breakpoint 1 (internal_error) pending.
> >>Function "info_command" not defined.
> >>Breakpoint 2 (info_command) pending.
> >>(top-gdb)
> >>
> >>It's caused by this:
> >>
> >>          if (!query ("Make breakpoint pending on future shared library 
> >>load? ")
> >>)
> >>            return rc;
> >>
> >>The old behavior was: when in batch mode, throw an error (and hence 
> >>abandon the script) if the breakpoint insert fails.
> >>
> >>The new behavior is: when in batch mode, always insert the breakpoint. 
> >>when not in batch mode never throw an error.
> >>
> >>For the existing behavior to be restored the query's logic would need to 
> >>be reversed (ask the oposite question) and then re-throw the error.  A 
> >>/pending qualifier could then be added.
> >>
> >>Thoughts?
> >
> >
> >I'd rather not reverse the question.  We could check from_tty at the
> >call site, and not set pending breakpoints if no tty...
> 
> Why?

Well, how would you word it?  It makes more intuitive sense to me to
answer 'y' to create something special and 'n' to do nothing, than the
other way around.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

System calls debugging

[MuthuKumar-Hotpop]

Hello deBUGies,

        Is there any way to debug what are all the "system calls" usage and process happening over on the program.

        I have written a simple program which gets the a string.I have made it to wait for the input and using that process-id,
        I have attached the process with gdb.Now the "where" command gives the stackframes about the system calls information.
        To find the processings of other system calls what is the way.  
             
Regards,
Muthu.