Re: GDB/MI Output Syntax

Re: GDB/MI Output Syntax

[Jim Ingham]

Nah, this works just fine.

The problem is that the sample extension actually adds a command called  
"sha1".  In interactive mode, tcl resolves shortened commands to the  
full name if the resolution is unique.  So if you do:

$ tclsh
% info commands sha*
% package require Tclsha1
0.5
% info commands sha*
sha1
% sha -string hello
aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
% sha1 -string hello
aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d

But in script mode, Tcl doesn't complete commands for you (to better  
catch errors in scripts).  So that's why you were getting the error  
when you tried to use the "sha" command in DejaGnu.  If you used the  
sha1 command, it would work:

inghji:tot-shlib-experiment/build/gdb > make check RUNTESTFLAGS="--D1"
Nothing to be done for all...
rootme=`pwd`; export rootme; \
srcdir=../../../gdb/src/gdb/testsuite ; export srcdir ; \
EXPECT=`if [ -f ${rootme}/../../expect/expect ] ; then echo  
${rootme}/../../expect/expect ; else echo expect ; fi` ; export EXPECT  
; \
EXEEXT= ; export EXEEXT ; \
          
RPATH_ENVVAR=$rootme/../../expect:$rootme/../../libstdc++: 
$rootme/../../tk/unix:$rootme/../../tcl/unix:$rootme/../../bfd: 
$rootme/../../opcodes:$RPATH_ENVVAR; \
export RPATH_ENVVAR; \
if [ -f ${rootme}/../../expect/expect ] ; then  \
   TCL_LIBRARY=${srcdir}/../../tcl/library ; \
   export TCL_LIBRARY ; fi ; \
/Volumes/ThePlayground/Users/jingham/Work/gdb-sources/tot-shlib- 
experiment/gdb/src/gdb/../dejagnu/runtest --D1
1: set frame_version    1.4.2.x

dbg1.0> package require Tclsha1
0.5
dbg1.1> sha1 -string hello
aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d

I actually think that building Bob's parser into a Tcl C extension &  
using that with the DejaGnu testsuite would be brilliant.  Not only  
would it ensure that we keep the output correctly parseable, but it  
would mean that we could solve the problem the current testsuite has  
that when you add a field to some mi command (which should be a  
backwards compatible operation) you have to go fix ALL the test cases.   
If you used the parser to read the MI output into a Tcl array, then the  
tests could just query the array for the elements they wanted to test,  
and not be bothered by elements that they were not concerned with  
testing.

Jim


On Aug 27, 2004, at 9:04 AM, gdb-digest-help@sources.redhat.com wrote:

> From: Michael Chastain <mec.gnu@mindspring.com>
> Date: August 26, 2004 3:16:43 PM PDT
> To: keiths@redhat.com
> Cc: gdb@sources.redhat.com, bob@brasko.net
> Subject: Re: GDB/MI Output Syntax
>
>
> Keith Seitz <keiths@redhat.com> wrote:
>> I've got three letters (okay, words) for you: TEA.
>>
>> Interfacing Tcl and C is TRIVIAL.
>>
>> Keith
>
> I left out a part: it's nontrivial for TCL code that's running in
> a TCL interpreter that's already linked into 'expect', a program
> that we did not build, to interface with a C library.
>
> lib/gdb.exp can load the TEA sample shared object without error, but  
> the
> new commands are not available.
>
>   ERROR: (DejaGnu) proc "sha -string hello" does not exist.
>
> When I run the same 'expect' binary standalone interactively, it can
> load the TEA sample library and the new commands are available.  Go
> figure.
>
> All the parts are there, but we're not currently using them and they
> fail the smoke test.  Multiply by a dozen hosts and that's what I call
> nontrivial.
>
>

Re: GDB/MI Output Syntax

[Michael Chastain]

Jim Ingham <jingham@apple.com> wrote:
> The problem is that the sample extension actually adds a command called  
> "sha1".  In interactive mode, tcl resolves shortened commands to the  
> full name if the resolution is unique.

*bonk* *bonk* *bonk*

That's the sound of me banging my head against the wall.  Stupid me!

> I actually think that building Bob's parser into a Tcl C extension &  
> using that with the DejaGnu testsuite would be brilliant.

New vistas are opening up to me!

It would be much better to use TCL data structures to parse MI rather
than regular expressions.  I had a great experience getting away from
regular expressions with cp_test_ptype_class.

It's still a dozen host arches (actually, a dozen build arches,
TCL runs on build machine).  But we're not debugging a target program
with shared libraries, we're just using one as a host.

Re: GDB/MI Output Syntax

[Bob Rossi]

On Fri, Aug 27, 2004 at 03:12:36PM -0400, Michael Chastain wrote:
> Jim Ingham <jingham@apple.com> wrote:
> > The problem is that the sample extension actually adds a command called  
> > "sha1".  In interactive mode, tcl resolves shortened commands to the  
> > full name if the resolution is unique.
> 
> *bonk* *bonk* *bonk*
> 
> That's the sound of me banging my head against the wall.  Stupid me!
> 
> > I actually think that building Bob's parser into a Tcl C extension &  
> > using that with the DejaGnu testsuite would be brilliant.
> 
> New vistas are opening up to me!
> 
> It would be much better to use TCL data structures to parse MI rather
> than regular expressions.  I had a great experience getting away from
> regular expressions with cp_test_ptype_class.
> 
> It's still a dozen host arches (actually, a dozen build arches,
> TCL runs on build machine).  But we're not debugging a target program
> with shared libraries, we're just using one as a host.

Hey, has anything ever evolved out of this? 

Here is my road map for developing an MI parser for CGDB.
   
   1. Create a grammar that is easily translated into LR(1)
   2. Generate the parser with flex and bison
   3. Have the parser test the output of the GDB MI testsuite
      (Don't know how to do this)
   4. Have the parser verify the semantics of GDB's output.

I basically believe I'm done with step 1 and 2, besides bugs and other
stuff. After I'm done with step 3, I plan on adding the parser into CGDB. I may
even wait until after step 4.

My questions are, 
   1. will the grammar and bison syntax be good to document so that others can see it?
   2. Can anyone help me put the parser into the testsuite ( It could
   take me forever since I know nothing about TCL, Excpect, ... )
   3. Would a patch like this be acceptable even if it was accomplished?

Thanks,
Bob Rossi

Re: GDB/MI Output Syntax

[Eli Zaretskii]

> Date: Wed, 5 Jan 2005 18:26:57 -0500
> From: Bob Rossi <bob@brasko.net>
> Cc: jingham@apple.com, gdb@sources.redhat.com
> 
>    1. will the grammar and bison syntax be good to document so that others can see it?

I think it's enough to point to the grammar definition file in the MI
docs.  There's no need to do more in the docs; the grammar should
document itself.

>    3. Would a patch like this be acceptable even if it was accomplished?

Why not?

Re: GDB/MI Output Syntax

[Bob Rossi]

On Thu, Jan 06, 2005 at 06:45:33AM +0200, Eli Zaretskii wrote:
> > Date: Wed, 5 Jan 2005 18:26:57 -0500
> > From: Bob Rossi <bob@brasko.net>
> > Cc: jingham@apple.com, gdb@sources.redhat.com
> > 
> >    1. will the grammar and bison syntax be good to document so that others can see it?
> 
> I think it's enough to point to the grammar definition file in the MI
> docs.  There's no need to do more in the docs; the grammar should
> document itself.
> 
> >    3. Would a patch like this be acceptable even if it was accomplished?
> 
> Why not?

It's just that nothing like that is being done now, and I didn't know if
it would be OK.

I can't seem to get a response from Jim or Michael, so I'm trying to
figure this out on my own.

At this point, I don't even know what would invoke this parser.
Would the TCL do it? for instance, would I have to do something like
catch a MI output command in the TCL by grabbing the regular expression
up to the "(gdb)" and then literally pass that string into my parser?

That would en tale modifying all of the .exp files, which would really
stink.

I don't even know were to start. :(
Any help would be appreciated.

Thanks,
Bob Rossi

Re: GDB/MI Output Syntax

[Jim Ingham]

Sorry for not responding, we're really busy here right now.

I don't think there is any way to use your parser that won't involve 
changing the testsuite files.  After all, they are just passing regular 
expressions, and unless you are ALSO willing to write a parser that 
turns the mi testsuite regular expressions into some sensible form (not 
something I would suggest) you are going to have to rewrite these 
tests.

I was more thinking of this as a project that you would use to write 
new tests, and then any time a change in the mi output broke a test 
case, you could rewrite it using the new form - since you are going to 
have to rewrite it anyway...

The way that I was thinking to use the parser, is to write a command 
like: "gdb_mi_parse_output" that would take the mi output, run your 
parser on it, and turn the result into some Tcl data structure. This 
would be a C based command, so we would have to build a little Tcl 
extension to do this, and include it with gdb when we ran the test 
suite.

The mi output is all basically just nested lists, so you could probably 
express it as a nested list pretty easily.  I'd have to think a bit 
about how to design this well.  Anyway, then you could rewrite the test 
suite cases to just pull fields out of the Tcl data structure, and see 
if the values were what was expected.

  Unfortunately, I am definitely not going to have any time to work on 
this in the next little while, however.

Jim

On Jan 6, 2005, at 3:31 PM, Bob Rossi wrote:



> On Thu, Jan 06, 2005 at 06:45:33AM +0200, Eli Zaretskii wrote:
>
>>> Date: Wed, 5 Jan 2005 18:26:57 -0500
>>> From: Bob Rossi <bob@brasko.net>
>>> Cc: jingham@apple.com, gdb@sources.redhat.com
>>>
>>>    1. will the grammar and bison syntax be good to document so that 
>>> others can see it?
>>>
>>
>> I think it's enough to point to the grammar definition file in the MI
>> docs.  There's no need to do more in the docs; the grammar should
>> document itself.
>>
>>
>>>    3. Would a patch like this be acceptable even if it was 
>>> accomplished?
>>>
>>
>> Why not?
>>
>
> It's just that nothing like that is being done now, and I didn't know 
> if
> it would be OK.
>
> I can't seem to get a response from Jim or Michael, so I'm trying to
> figure this out on my own.
>
> At this point, I don't even know what would invoke this parser.
> Would the TCL do it? for instance, would I have to do something like
> catch a MI output command in the TCL by grabbing the regular expression
> up to the "(gdb)" and then literally pass that string into my parser?
>
> That would en tale modifying all of the .exp files, which would really
> stink.
>
> I don't even know were to start. :(
> Any help would be appreciated.
>
> Thanks,
> Bob Rossi
>

Re: GDB/MI Output Syntax

[Bob Rossi]

On Thu, Jan 06, 2005 at 04:36:13PM -0800, Jim Ingham wrote:
> Sorry for not responding, we're really busy here right now.
> 
> I don't think there is any way to use your parser that won't involve 
> changing the testsuite files.  After all, they are just passing regular 
> expressions, and unless you are ALSO willing to write a parser that 
> turns the mi testsuite regular expressions into some sensible form (not 
> something I would suggest) you are going to have to rewrite these 
> tests.

OK, so rewriting the tests is fine. They are not very complicated.

> I was more thinking of this as a project that you would use to write 
> new tests, and then any time a change in the mi output broke a test 
> case, you could rewrite it using the new form - since you are going to 
> have to rewrite it anyway...

That's sounds OK. However, I would like to rewrite a few of them now, so
that I can test that the parser is working.

> The way that I was thinking to use the parser, is to write a command 
> like: "gdb_mi_parse_output" that would take the mi output, run your 
> parser on it, and turn the result into some Tcl data structure. This 
> would be a C based command, so we would have to build a little Tcl 
> extension to do this, and include it with gdb when we ran the test 
> suite.

Here's the deal, I already have the C function that takes an MI output
command, parses it, and returns a tree that represents the command. 

   int gdbmi_parser_parse_string ( 
       gdbmi_parser_ptr parser, /* a gdbmi parser context */
       const char *mi_command,  /* command the parser should parse */
       gdbmi_output_ptr *pt );  /* The parse tree */

If Tcl is like C (struct, enum's, union's) I could easily put the parse
tree declaration in some common file and generate both the C and the Tcl
data structures. This part could be done in just a few days if I could
get some guidance on how Tcl works.

> The mi output is all basically just nested lists, so you could probably 
> express it as a nested list pretty easily.  I'd have to think a bit 
> about how to design this well.  Anyway, then you could rewrite the test 
> suite cases to just pull fields out of the Tcl data structure, and see 
> if the values were what was expected.

This part I could do also. In fact, I need to do essentially this to
make my front end work. It's all the same code. I think taking this step
would do a lot in the sense of standardizing the output of GDB/MI.

>  Unfortunately, I am definitely not going to have any time to work on 
> this in the next little while, however.

If you could help me with some technical details, I'd be happy to do the
rest of the work. Is this possible or are you just to maxed out?

Thanks,
Bob Rossi

Re: GDB/MI Output Syntax

[Russell Shaw]

Bob Rossi wrote:
...
> If Tcl is like C (struct, enum's, union's) I could easily put the parse
> tree declaration in some common file and generate both the C and the Tcl
> data structures. This part could be done in just a few days if I could
> get some guidance on how Tcl works.

TCL really means "command line language".

Everything in TCL is a command line eg: <command> <arg1 <arg2> <arg3> etc.

You can nest commands so that one command can be expanded and executed so
that its output supplies args for its parent, using [] brackets:

<command1> <arg11> [ <command2> <arg21> <arg22> ] <arg12> <arg13>...

TCL is all about string expansion of command lines.

A very comprehensive book: Pactical Programming in Tcl and Tk.
Another book that explains TCL and also Expect (probably of more
immediate use): Exploring Expect. Expect also has a large man page.

C and TCL is like comparing chalk and cheese. TCL is interpreted too.

Re: GDB/MI Output Syntax

[Bob Rossi]

On Fri, Jan 07, 2005 at 02:16:29PM +1100, Russell Shaw wrote:
> Bob Rossi wrote:
> ...
> >If Tcl is like C (struct, enum's, union's) I could easily put the parse
> >tree declaration in some common file and generate both the C and the Tcl
> >data structures. This part could be done in just a few days if I could
> >get some guidance on how Tcl works.
> 
> A very comprehensive book: Pactical Programming in Tcl and Tk.
> Another book that explains TCL and also Expect (probably of more
> immediate use): Exploring Expect. Expect also has a large man page.
> 
> C and TCL is like comparing chalk and cheese. TCL is interpreted too.

Thanks for the info, I looked at "Practical Programming" and it helped me
out a lot!

So, here is my initial design, can I get any feedback?

Basically, I have a parser that I generated using flex/bison. That
parser is capable of parsing an MI output command and putting it into a
syntax tree. This is all done in C.

To get the data into Tcl for the testsuite I had to write a Tcl
extension. The design I chose from the Tcl side is something like this.

Here is part of the parse tree on the C side,
   /**
    * This is the root of a parsed GDB/MI Output command.
    */
   struct gdbmi_output {
       /**
        * Every output command has a list of optional oob_record's.
        * This will be the head of the list, otherwise NULL.
        */
       gdbmi_oob_record_ptr oob_record;

       /**
        * Every output command has an optional result_record.
        * list, otherwise NULL.
        */
       gdbmi_result_record_ptr result_record;

       /** A pointer to the next output */
       gdbmi_output_ptr next;
   };
   
This is the Tcl side which understands how to access this data.

# ------------ 'struct gdbmi_output' documentation

#   This function will parse an MI output command and return a
#   reference to the syntax tree created.
#
# Arguments:
#   mi_output_command is the string representing the MI output
#   command that should be parsed and returned.
#
# Results:
#   The string representing the gdbmi_output record. This in itself
#   is not very useful, but can be operated on by the gdbmi_* commands.
#
proc gdbmi_parse_output_record {mi_output_command}

#   This function takes in a parse tree and get's the gdbmi_oob_record
#   from the parse tree context.
#
# Arguments:
#   gdbmi_output is the gdbmi_output command that came from
#   gdbmi_parse_output_record
#
# Results:
#   A string representing an gdbmi_oob_record record
#
proc gdbmi_get_oob_record {gdbmi_output}

#   This function takes in a parse tree and get's the gdbmi_result_record
#   from the parse tree context.
#
# Arguments:
#   gdbmi_output is the gdbmi_output command that came from
#   gdbmi_parse_output_record
#
# Results:
#   A string representing a gdbmi_result_record record
#
proc gdbmi_get_result_record {gdbmi_output}


From this, I think it would be possible to query the syntax tree in the
Tcl. This would allow the testsuite to verify the syntax and possible the
semantics of the gdb/mi output commands.

This is the approach I'm working towards. Any comments or suggestions?

In the end, it would also be possible to have the parser parse the
output command and then write another tcl command that fills in a data
structure for the specific command under test. This way the scripts do
not have to deal with the syntax tree directly, but an in memory
representation of the MI output command. That would look something like
this,
   set mi_output_command [gdbmi_parse $mi_output_command]
   set mi_break_output [gdbmi_get_breakoutput $mi_output_command]
 
The downside to this approach is creating in memory representations of
the specific MI commands, the upside to this is not making the
testcase's deal with the syntax tree directly. Also, front ends' could
link to the C parser and get the in memory representation.

Thanks,
Bob Rossi

Re: GDB/MI Output Syntax

[Bob Rossi]

Hi,

Any feedback? Either everyone's really busy, no one cares, or everyone
love's this approach. At least we're all agreeing. :)

Since I haven't received any feedback, I'm going to write it this way. I
should have something workable within a week. Although, I don't know how
to load this into expect yet. I'm assuming I'll have to recompile expect
and link in tcl as a shared library, along with my extension.

Thanks,
Bob Rossi

On Tue, Jan 11, 2005 at 02:35:26PM -0500, Bob Rossi wrote:
> On Fri, Jan 07, 2005 at 02:16:29PM +1100, Russell Shaw wrote:
> > Bob Rossi wrote:
> > ...
> > >If Tcl is like C (struct, enum's, union's) I could easily put the parse
> > >tree declaration in some common file and generate both the C and the Tcl
> > >data structures. This part could be done in just a few days if I could
> > >get some guidance on how Tcl works.
> > 
> > A very comprehensive book: Pactical Programming in Tcl and Tk.
> > Another book that explains TCL and also Expect (probably of more
> > immediate use): Exploring Expect. Expect also has a large man page.
> > 
> > C and TCL is like comparing chalk and cheese. TCL is interpreted too.
> 
> Thanks for the info, I looked at "Practical Programming" and it helped me
> out a lot!
> 
> So, here is my initial design, can I get any feedback?
> 
> Basically, I have a parser that I generated using flex/bison. That
> parser is capable of parsing an MI output command and putting it into a
> syntax tree. This is all done in C.
> 
> To get the data into Tcl for the testsuite I had to write a Tcl
> extension. The design I chose from the Tcl side is something like this.
> 
> Here is part of the parse tree on the C side,
>    /**
>     * This is the root of a parsed GDB/MI Output command.
>     */
>    struct gdbmi_output {
>        /**
>         * Every output command has a list of optional oob_record's.
>         * This will be the head of the list, otherwise NULL.
>         */
>        gdbmi_oob_record_ptr oob_record;
> 
>        /**
>         * Every output command has an optional result_record.
>         * list, otherwise NULL.
>         */
>        gdbmi_result_record_ptr result_record;
> 
>        /** A pointer to the next output */
>        gdbmi_output_ptr next;
>    };
>    
> This is the Tcl side which understands how to access this data.
> 
> # ------------ 'struct gdbmi_output' documentation
> 
> #   This function will parse an MI output command and return a
> #   reference to the syntax tree created.
> #
> # Arguments:
> #   mi_output_command is the string representing the MI output
> #   command that should be parsed and returned.
> #
> # Results:
> #   The string representing the gdbmi_output record. This in itself
> #   is not very useful, but can be operated on by the gdbmi_* commands.
> #
> proc gdbmi_parse_output_record {mi_output_command}
> 
> #   This function takes in a parse tree and get's the gdbmi_oob_record
> #   from the parse tree context.
> #
> # Arguments:
> #   gdbmi_output is the gdbmi_output command that came from
> #   gdbmi_parse_output_record
> #
> # Results:
> #   A string representing an gdbmi_oob_record record
> #
> proc gdbmi_get_oob_record {gdbmi_output}
> 
> #   This function takes in a parse tree and get's the gdbmi_result_record
> #   from the parse tree context.
> #
> # Arguments:
> #   gdbmi_output is the gdbmi_output command that came from
> #   gdbmi_parse_output_record
> #
> # Results:
> #   A string representing a gdbmi_result_record record
> #
> proc gdbmi_get_result_record {gdbmi_output}
> 
> 
> >From this, I think it would be possible to query the syntax tree in the
> Tcl. This would allow the testsuite to verify the syntax and possible the
> semantics of the gdb/mi output commands.
> 
> This is the approach I'm working towards. Any comments or suggestions?
> 
> In the end, it would also be possible to have the parser parse the
> output command and then write another tcl command that fills in a data
> structure for the specific command under test. This way the scripts do
> not have to deal with the syntax tree directly, but an in memory
> representation of the MI output command. That would look something like
> this,
>    set mi_output_command [gdbmi_parse $mi_output_command]
>    set mi_break_output [gdbmi_get_breakoutput $mi_output_command]
>  
> The downside to this approach is creating in memory representations of
> the specific MI commands, the upside to this is not making the
> testcase's deal with the syntax tree directly. Also, front ends' could
> link to the C parser and get the in memory representation.
> 
> Thanks,
> Bob Rossi

Intrusive GDB Symbol Lookup when debugging remotely

[David Steven Trollope]

Hello!

I'm trying to determine if there exists an alternative solution, or a 
patch for the following problem, or if someone familiar with the GDB 
source can estimate how much work it would be to implement a patch. Any 
advice would be welcome and appreciated.


Configuration:

GDB running on a Sun Solaris machine.
GDBServer running on a PowerPC Linux machine
The application is running on the target in GDBServer and GDB is 
connected to the target using "target remote x.x.x.x:y"

Problem:

While the target is running, I don't think it is possible to examine the 
symbol table from within gdb without sending an interrupt signal to GDB. 
This is a problem because users (and frontends) don't seem to be able to 
look up symbols in the symbol table in GDB without interrupting the target.

In theory, it would be possible to stop the interrupt being propogated 
to the server and hence the target could remain running without 
interruption. One possible way of solving this would be to use a 
different signal as a "Non-intrusive interrupt" or "Local Interrupt". 
The symbol lookup can occur, and then gdb resumes. This would imply gdb 
would need to know if its running in "Local" or "Remote" mode to prevent 
operations trying to access the target.

An alternative mechanism could be to have a separate thread that runs 
and is signalled for non-intrusive operations.

You might ask why not just run a separate gdb instance to do this kind 
of look up? However, I am dealing with large executables where loading 
separate instances for the sake of a symbol lookup is neither efficient, 
timely or practical.

I would very much appreciate discussion on this topic with regard to 
feasibility, if its been done already or how much effort it would be to 
implement this type of functionality.

Cheers
Dave Trollope

-- 
                 Dave Trollope
              Lucent Technologies
            Tel/Fax: +1 630 713 9110
           mailto:trollope@lucent.com

Re: Intrusive GDB Symbol Lookup when debugging remotely

[Dave Trollope]

Hello,

No-one responded to this, but I'm sure someone on this list understands 
how difficult it would be to implement a new handler for a signal to run 
gdb in a "Local" mode when connected to a gdbserver. I'd really 
appreciate an estimate of how much effort this would be, or where in the 
code to start looking.

Cheers
Dave
David Steven Trollope wrote:

> Hello!
>
> I'm trying to determine if there exists an alternative solution, or a 
> patch for the following problem, or if someone familiar with the GDB 
> source can estimate how much work it would be to implement a patch. 
> Any advice would be welcome and appreciated.
>
>
> Configuration:
>
> GDB running on a Sun Solaris machine.
> GDBServer running on a PowerPC Linux machine
> The application is running on the target in GDBServer and GDB is 
> connected to the target using "target remote x.x.x.x:y"
>
> Problem:
>
> While the target is running, I don't think it is possible to examine 
> the symbol table from within gdb without sending an interrupt signal 
> to GDB. This is a problem because users (and frontends) don't seem to 
> be able to look up symbols in the symbol table in GDB without 
> interrupting the target.
>
> In theory, it would be possible to stop the interrupt being propogated 
> to the server and hence the target could remain running without 
> interruption. One possible way of solving this would be to use a 
> different signal as a "Non-intrusive interrupt" or "Local Interrupt". 
> The symbol lookup can occur, and then gdb resumes. This would imply 
> gdb would need to know if its running in "Local" or "Remote" mode to 
> prevent operations trying to access the target.
>
> An alternative mechanism could be to have a separate thread that runs 
> and is signalled for non-intrusive operations.
>
> You might ask why not just run a separate gdb instance to do this kind 
> of look up? However, I am dealing with large executables where loading 
> separate instances for the sake of a symbol lookup is neither 
> efficient, timely or practical.
>
> I would very much appreciate discussion on this topic with regard to 
> feasibility, if its been done already or how much effort it would be 
> to implement this type of functionality.
>
> Cheers
> Dave Trollope
>

Re: Intrusive GDB Symbol Lookup when debugging remotely

[Andrew Cagney]

Dave Trollope wrote:
> Hello,
> 
> No-one responded to this, but I'm sure someone on this list understands 
> how difficult it would be to implement a new handler for a signal to run 
> gdb in a "Local" mode when connected to a gdbserver. I'd really 
> appreciate an estimate of how much effort this would be, or where in the 
> code to start looking.

In theory, "target async-remote" does what you're looking for - it runs 
the inferior in the background letting you interact with the local 
symbol table.

In reality though, that code hasn't been tested in years .....  We need 
something like native GNU/Linux being made async giving us a mainstream 
async target.

Andrew

Re: Intrusive GDB Symbol Lookup when debugging remotely

[David Steven Trollope]

Hi Andrew

Thanks very much for responding. This is a great lead. We will take a
look at this option and see how it works today on our system.

Cheers!
Dave
On 01/24/05 13:47, Andrew Cagney wrote:

>Dave Trollope wrote:
>  
>
>>Hello,
>>
>>No-one responded to this, but I'm sure someone on this list understands 
>>how difficult it would be to implement a new handler for a signal to run 
>>gdb in a "Local" mode when connected to a gdbserver. I'd really 
>>appreciate an estimate of how much effort this would be, or where in the 
>>code to start looking.
>>    
>>
>
>In theory, "target async-remote" does what you're looking for - it runs 
>the inferior in the background letting you interact with the local 
>symbol table.
>
>In reality though, that code hasn't been tested in years .....  We need 
>something like native GNU/Linux being made async giving us a mainstream 
>async target.
>
>Andrew
>  
>

-- 
                 Dave Trollope
        HTML: mailto:trollope@lucent.com
    Tel: +1 630 713 9110 Fax: +1 630 713 6087
   WWW: http://nwswww.ih.lucent.com/~dtrollop/
WWW: http://www.geocities.com/SiliconValley/7499/

Linux Realtime Scheduling Option

[David Steven Trollope]

Hello!

I'm working on a project that uses Linux 2.4 on a PowerPC processor with 
real time scheduling.

One of the issues we've encountered is that when the application being 
debugged is running real time and gdb/gdbserver is not, scheduling 
problems occur.

I'm wondering if its possible to have an option added to gdb and the 
.gdbinit file which specifies the realtime priority which gdb/gdbserver 
should run at.

I searched the mailing list and do not find anything related to this in 
the past.

Has anyone got experience in this area? Do patches already exist?

Cheers
Dave


-- 
                 Dave Trollope
            Tel/Fax: +1 630 713 9110
           mailto:trollope@lucent.com
     http://nwswww.ih.lucent.com/~dtrollop/
  http://www.geocities.com/SiliconValley/7499/

Re: Linux Realtime Scheduling Option

[Daniel Jacobowitz]

On Fri, Mar 18, 2005 at 10:29:32AM -0600, David Steven Trollope wrote:
> Hello!
> 
> I'm working on a project that uses Linux 2.4 on a PowerPC processor with 
> real time scheduling.
> 
> One of the issues we've encountered is that when the application being 
> debugged is running real time and gdb/gdbserver is not, scheduling 
> problems occur.
> 
> I'm wondering if its possible to have an option added to gdb and the 
> .gdbinit file which specifies the realtime priority which gdb/gdbserver 
> should run at.
> 
> I searched the mailing list and do not find anything related to this in 
> the past.
> 
> Has anyone got experience in this area? Do patches already exist?

This is not a good idea.  There are existing Linux tools to change the
realtime priority of a process; why can't you use them to change the
priority of the debugger?  You can even do this after starting the
inferior process if it isn't smart enough to reset its own priority.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Linux Realtime Scheduling Option

[David Steven Trollope]

Hi Daniel,

Our application does change its own priority, but I was concerned with 
the priority of gdbserver/gdb. Which Linux tools are you referring to? 
I'll go take a look at them.

In our environment gdb/gdbserver should always run realtime at a set 
priority. Help me understand why is it not a good idea to have 
gdb/gdbserver set its own priority based on an option in .gdbinit?

Thanks much!
Dave

Daniel Jacobowitz wrote:

>On Fri, Mar 18, 2005 at 10:29:32AM -0600, David Steven Trollope wrote:
>  
>
>>Hello!
>>
>>I'm working on a project that uses Linux 2.4 on a PowerPC processor with 
>>real time scheduling.
>>
>>One of the issues we've encountered is that when the application being 
>>debugged is running real time and gdb/gdbserver is not, scheduling 
>>problems occur.
>>
>>I'm wondering if its possible to have an option added to gdb and the 
>>.gdbinit file which specifies the realtime priority which gdb/gdbserver 
>>should run at.
>>
>>I searched the mailing list and do not find anything related to this in 
>>the past.
>>
>>Has anyone got experience in this area? Do patches already exist?
>>    
>>
>
>This is not a good idea.  There are existing Linux tools to change the
>realtime priority of a process; why can't you use them to change the
>priority of the debugger?  You can even do this after starting the
>inferior process if it isn't smart enough to reset its own priority.
>
>  
>

-- 
                 Dave Trollope
            Tel/Fax: +1 630 713 9110
           mailto:trollope@lucent.com
     http://nwswww.ih.lucent.com/~dtrollop/
  http://www.geocities.com/SiliconValley/7499/

Re: Linux Realtime Scheduling Option

[Daniel Jacobowitz]

On Mon, Mar 21, 2005 at 01:20:02PM -0600, David Steven Trollope wrote:
> Hi Daniel,
> 
> Our application does change its own priority, but I was concerned with 
> the priority of gdbserver/gdb. Which Linux tools are you referring to? 
> I'll go take a look at them.

Search for 'rt' or 'chrt'; I do not recall which one is current.  I
believe they are in the 'schedutils' distribution.

> In our environment gdb/gdbserver should always run realtime at a set 
> priority. Help me understand why is it not a good idea to have 
> gdb/gdbserver set its own priority based on an option in .gdbinit?

First of all, gdbserver doesn't parse an init file.  You would have to
add a Linux-specific packet type to the remote protocol for GDB to
communicate this to gdbserver.

Secondly, because there are standalone tools to handle the problem.
gdbserver is supposed to be simple; I don't want to add code specific
to a particular, fairly uncommon debugging environment when existing
tools handle it perfectly well.

If you can come up with a reason why the standalone tools can not be
used to solve the problem, then we can rediscuss :-)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Linux Realtime Scheduling Option

[Dave Trollope]

Hi Daniel,

Daniel Jacobowitz wrote:

>On Mon, Mar 21, 2005 at 01:20:02PM -0600, David Steven Trollope wrote:
>  
>
>>Hi Daniel,
>>
>>Our application does change its own priority, but I was concerned with 
>>the priority of gdbserver/gdb. Which Linux tools are you referring to? 
>>I'll go take a look at them.
>>    
>>
>
>Search for 'rt' or 'chrt'; I do not recall which one is current.  I
>believe they are in the 'schedutils' distribution.
>  
>
I'll take a look.

>>In our environment gdb/gdbserver should always run realtime at a set 
>>priority. Help me understand why is it not a good idea to have 
>>gdb/gdbserver set its own priority based on an option in .gdbinit?
>>    
>>
>
>First of all, gdbserver doesn't parse an init file.  You would have to
>add a Linux-specific packet type to the remote protocol for GDB to
>communicate this to gdbserver.
>  
>
I wasn't thinking this was Linux specific. Doesn't Solaris also have 
realtime extensions that this would apply to?

I can certainly see that its not generic enough to be worthy of adding 
to the remote protocol.


>Secondly, because there are standalone tools to handle the problem.
>gdbserver is supposed to be simple; I don't want to add code specific
>to a particular, fairly uncommon debugging environment when existing
>tools handle it perfectly well.
>
>If you can come up with a reason why the standalone tools can not be
>used to solve the problem, then we can rediscuss :-)
>  
>
Its not a gdbserver specific issue. If you run gdb on any Linux machine 
while loading an application that sets its own real time priority 
problems will likely occur from the mismatch. I don't know if Solaris 
suffers from the same issue, but I would expect it to.

I think its really applicable to any unix variant where realtime 
extentions allow an application to change its own priority.

Perhaps gdb/gdbserver could have a command line option (instead of 
.gdbinit) that registers itself realtime, as the highest priority? Its 
likely you want the debugger to run at the highest priority to catch 
tight loops etc. This would also map to non-unix OSs like VxWorks.

Does this strategy sound more appealing?

I appreciate your time.

Cheers
Dave

Re: Linux Realtime Scheduling Option

[Daniel Jacobowitz]

On Mon, Mar 21, 2005 at 09:03:35PM -0600, Dave Trollope wrote:
> Perhaps gdb/gdbserver could have a command line option (instead of 
> .gdbinit) that registers itself realtime, as the highest priority? Its 
> likely you want the debugger to run at the highest priority to catch 
> tight loops etc. This would also map to non-unix OSs like VxWorks.
> 
> Does this strategy sound more appealing?

No, because this is exactly what you would accomplish by using rt/chrt.
Please, look at them before we continue this conversation.

-- 
Daniel Jacobowitz
CodeSourcery, LLC