Pedro Alves | 1 Apr 2008 02:18

Re: cleanup mi error message handling

A Monday 31 March 2008 01:45:18, Nick Roberts wrote:
>  > The only thing from you I can find is:
>  >
>  >   At other times duplicated error messages are desirable, e.g.,
>  >
>  >   -exec-continue
>  >   ^running
>  >   (gdb)
>  >   &"The program is not being run.\n"
>  >   ^error,msg="The program is not being run."
>  >
>  >   because the first goes to the console for the user to see, the second
>  > to the frontend to be handled as appropriate.
>  >
>  > You still did not say why showing the error message is console is
>  > desirable. If -exec-continue itself is now show in the console, the
>  > error message makes no sense. If -exec-continue is shown, then the error
>  > message is not necessary. Where the flaw in this logic.
>
> I can't understand these sentences.  The command -exec-continue won't
> appear in the console but "The program is not being run." will.  These
> `errors' and other similar ones like "No stack." are reported through error
> () and are normal Gdb output for the user to see.  Currently the console
> can display such messages by reading LOG-STREAM-OUTPUT.
>
> Other errors like:
>
> (gdb)
> -interpreter-exec
> ^error,msg="mi_cmd_interpreter_exec: Usage: -interpreter-exec interp
(Continue reading)

Nick Roberts | 1 Apr 2008 03:59
Picon

[RFC] Using bt command in async mode


This patch allows the bt to be executed in async mode while the inferior is
executing.  The idea being that the frontend can get a snapshot of what the
inferior is doing and update the UI.  It's just a proof of concept, so I've
used linux_nat_async_events and my_waitpid directly but eventually these could
be made into target methods, of course.

If the general idea is agreeable, I would like to extend it to other commands
like "info locals", "info threads" etc.

An example session looks like this:

 
    (gdb) maintenance set linux-async on
    (gdb) r&
    Starting program: /home/nickrob/donowt 
    (gdb) bt
    #0  0x080483c9 in mysub1 () at donowt.c:12
    #1  0x080483f7 in mysub () at donowt.c:22
    #2  0x0804840f in main () at donowt.c:28
    (gdb) interrupt
    (gdb) 
    Program received signal SIGINT, Interrupt.
    0x080483c9 in mysub1 () at donowt.c:12
    12            if (i == 5)

    (gdb) quit
    The program is running.  Quit anyway (and kill it)? (y or n) y
    nickrob <at> kahikatea:~$ 

(Continue reading)

Nick Roberts | 1 Apr 2008 04:08
Picon

Re: cleanup mi error message handling

 > > Other errors like:
 > >
 > > (gdb)
 > > -interpreter-exec
 > > ^error,msg="mi_cmd_interpreter_exec: Usage: -interpreter-exec interp
 > > command" (gdb)
 > >
 > > would be due to a frontend error, so I think it would be probably be best
 > > to display them elsewhare, e.g., status bar.
 > >
 > 
 > I think the screen should flash and beep three times, and an email
 > should be automatically sent the the frontend author :-)  Seriously,
 > the status bar doesn't feel right for this.  This is not status.

Please don't take the status bar example too literally, it was just the first
place I thought of, and is not the focus of my message.

To get a meaningful report probably requires full logging of all the
transactions anyway, which is what I do for Emacs.

In any case I've already surrendered on this issue.

Please redirect any frontend errors using Gdb in Emacs reported on this list to
emacs-devel ;-)

Thanks.

--

-- 
Nick                                           http://www.inet.net.nz/~nickrob
(Continue reading)

Eli Zaretskii | 1 Apr 2008 05:27
Picon

Re: [RFC 2/5] Frame unwinding using struct value

> Date: Mon, 31 Mar 2008 18:10:24 -0400
> From: Daniel Jacobowitz <drow <at> false.org>
> 
> 2008-03-31  Daniel Jacobowitz  <dan <at> codesourcery.com>
> 
> 	* gdbint.texinfo (Stack Frames): New chapter.
> 	(Algorithms): Move Frames text to the new chapter.
> 	(Target Conditionals): Delete SAVE_DUMMY_FRAME_TOS.  Document
> 	gdbarch_dummy_id instead of gdbarch_unwind_dummy_id.

Thanks, this part is approved, but I have some comments:

> + <at> node Stack Frames
> + <at> chapter Stack Frames
> +
> + <at> cindex frame
> + <at> cindex call stack frame
> +A frame is a construct that  <at> value{GDBN} uses to keep track of calling
> +and called functions.
> +
> + <at> cindex frame, unwind

It is not useful to have several index entries that begin with the
same string and point to the same page.  So I suggest to replace the
last one with " <at> cindex unwind frame".

> +Developers wishing to learn more about unwinders, are encouraged to
> +read the  <at> sc{dwarf} specification.

How about a pointer to the DWARF Spec here?
(Continue reading)

André Pönitz | 1 Apr 2008 15:17

Re: -var-update <at>

On Thursday 27 March 2008 21:58:09 Nick Roberts wrote:
>  > DSF only updates varObj that are visible on screen.  So currently, it always
>  > uses -var-update with a single varObj name (never use *).
> 
> Which must mean that there is a round trip to the target for each variable
> object that needs to be updated.

One usually can issue all commands at once without waiting for the results
to show up first. So depending on circumstances asking $n questions might 
take considerably less time than $n "full roundtrips".

Having said that, roundtrip times are indeed reducing the utility of
the current mi interface: One needs simply too much 'real' roundtrips to
get a screenfull of information. 

As an example I don't need the 'intermediate level' of public/protected/private
information for C++ objects, since I do not want to display that anyway.
Yet I have to ask for --all-children, wait for the response, parse it, only to
discover that it cointains a, say, private and a public block, and ask again
for the 'real' children now. So that's two full roundtrips for what could be one...

Regards,
Andre'

Marc Khouzam | 1 Apr 2008 15:23
Picon
Favicon
Gravatar

RE: -var-update <at>


> As an example I don't need the 'intermediate level' of public/protected/private
> information for C++ objects, since I do not want to display that anyway.
> Yet I have to ask for --all-children, wait for the response, parse it, only to
> discover that it cointains a, say, private and a public block, and ask again
> for the 'real' children now. So that's two full roundtrips for what could be one...

That is good example of something that would be nice to improve.
Maybe having a -depth option to the var-list-children command?
In DSF, we always go to a full depth, so we have no real use for having to
separately query at each level of children.

Marc

Daniel Jacobowitz | 1 Apr 2008 15:37

Re: linux native async mode support

On Sun, Mar 23, 2008 at 10:05:42AM +1200, Nick Roberts wrote:
> Attached below.  I've added [board_info gdb_protocol] == "async" since
> "target async" works after Vladimir's changes.

> # This currently only works with native linux and the async remote protocol.
> if { !([isnative] && [istarget *-linux*]) \
>      && [board_info gdb_protocol] != "async" } then {
>   return
> }

It has to be [board_info target gdb_protocol] or [target_info
gdb_protocol].  Actually, this:

if { !([isnative] && [istarget *-linux*]) \
     && (![target_info exists gdb_protocol] \
         || [target_info gdb_protocol] != "async") } then {

> # The plan is for async mode to become the default but toggle for now.
> set saved_gdbflags $GDBFLAGS
> set GDBFLAGS "-ex \"maint set linux-async on\""

Please append to GDBFLAGS instead of setting it; otherwise you'll lose
-nx and it will read $HOME/.gdbinit.

> #if [istarget "i386-*-linux-gnu"] then {
>     linux_async_tests
> #}

Remove the commented out lines.

(Continue reading)

Marc Khouzam | 1 Apr 2008 15:56
Picon
Favicon
Gravatar

[Patch] mi-var-display regression failures fix

Hi,

There are a couple of new unexpected failures in MI regressions.
I believe that an xfail marker was removed by mistake, which makes a couple of tests seem to fail.

Instead of putting back the xfail, I thought that fixing the error may be even better :-)
This patch fixes those two testcases by having the test program run until variable are initialized.

BTW, you should have my Copyright Assignment on file now, and my sourceforge account is setup, 
so I can commit this if I get approval.

Thanks

--

-- 
Marc Khouzam

Changelog:

2008-04-01  Marc Khouzam  <marc.khouzam <at> ericsson.com>

	* gdb.mi/mi-var-display.exp: Stop at end of do_special_tests
	instead of beginning to make an extra test pass.
	* gdb.mi/mi2-var-display.exp: Likewise.

Index: gdb/testsuite/gdb.mi/mi-var-display.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-var-display.exp,v
retrieving revision 1.23
diff -u -r1.23 mi-var-display.exp
--- gdb/testsuite/gdb.mi/mi-var-display.exp     26 Mar 2008 13:36:51 -0000      1.23
(Continue reading)

Daniel Jacobowitz | 1 Apr 2008 15:59

Re: [RFA] Fix breakpoint condition that use member variables.

Eli's raised a valid concern, but I think it's unrelated to this
change, so I will review this patch independently of it.

On Sat, Mar 22, 2008 at 12:40:15PM +0300, Vladimir Prus wrote:
> -    /* If this is non-NULL, lookup_symbol will do the 'field_of_this'
> -       check, using this function to find the value of this.  */
> +    /* If this is non-NULL, specifies the name that of the implicit
> +       local variable that refers to the current object instance.  */

Drop "that" in the first line.

> diff --git a/gdb/m2-lang.c b/gdb/m2-lang.c
> index 6b51fd5..400338e 100644
> --- a/gdb/m2-lang.c
> +++ b/gdb/m2-lang.c
>  <at>  <at>  -375,7 +375,7  <at>  <at>  const struct language_defn m2_language_defn =
>    m2_val_print,			/* Print a value using appropriate syntax */
>    c_value_print,		/* Print a top-level value */
>    NULL,				/* Language specific skip_trampoline */
> -  value_of_this,		/* value_of_this */
> +  "this",		        /* name_of_this */
>    basic_lookup_symbol_nonlocal,	/* lookup_symbol_nonlocal */
>    basic_lookup_transparent_type,/* lookup_transparent_type */
>    NULL,				/* Language specific symbol demangler */

This can be NULL.

> diff --git a/gdb/symtab.c b/gdb/symtab.c
> index ddd2310..7d9b4ea 100644
> --- a/gdb/symtab.c
(Continue reading)

Daniel Jacobowitz | 1 Apr 2008 16:04

Re: per-thread variable objects

On Mon, Mar 24, 2008 at 08:46:06PM +0300, Vladimir Prus wrote:
>  <at>  <at>  -66,6 +67,10  <at>  <at>  print_varobj (struct varobj *var, enum p
>        xfree (type);
>      }
>  
> +  thread_id = varobj_get_thread_id (var);
> +  if (thread_id > 0)
> +    ui_out_field_int (uiout, "thread-id", thread_id);
> +
>    if (varobj_get_frozen (var))
>      ui_out_field_int (uiout, "frozen", 1);
>  }

Please add this field to the manual.

--

-- 
Daniel Jacobowitz
CodeSourcery


Gmane