From: Pedro Alves <pedro_alves@portugalmail.pt>
To: gdb-patches@sourceware.org
Subject: Re: TUI + gdbserver broken?
Date: Tue, 20 Mar 2007 00:39:00 -0000 [thread overview]
Message-ID: <45FF2D16.6030501@portugalmail.pt> (raw)
In-Reply-To: <20070319234141.GA29137@caradoc.them.org>
[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]
Daniel Jacobowitz escreveu:
> On Mon, Mar 19, 2007 at 10:57:53PM +0000, Pedro Alves wrote:
>
>> That has exactly the same effect as it was before the your select frame
>> changes.
>> That is, only try to get the selected frame when there is one. Maybe there
>> should
>> still be a function like this in frame.c ?
>>
>
>
>> struct frame_info *
>> deprecated_get_selected_frame ()
>> {
>> return selected_frame;
>> }
>>
>
>
Neither this, or your (level >= 0), worked - they both make tui enter
some kind of loop,
that I can't get a trace. Perhaps in some other host it would be
easier (I'm on Cygwin). Bummer.
>> (or perhaps call it get_selected_frame_if_any)
>>
>
> The problem is that when we reinitialize the frame cache, the selected
> frame is indeterminate - the selected_frame global may randomly be
> initialized or NULL depending on what else has been called since we
> last did reinit_frame_cache.
>
Maybe that has something to do with the hangs I see.
How about the attached? Move the selected_frame creation logic
to select_frame.
It fixes both the remote debugging problem, and the repainting
problems - probably caused by the get_selected_frame calling
select_frame generating extra spurious events.
It would need a testsuite run and a bit of cleanup, since the
get_selected_frame would lose the parameter.
Cheers,
Pedro Alves
[-- Attachment #2: tui_frame3.diff --]
[-- Type: text/plain, Size: 1911 bytes --]
gdb/ChangeLog
* frame.c (get_selected_frame): Move selected frame
to current frame mapping to ...
(select_frame): ... here.
---
gdb/frame.c | 28 +++++++++++++++-------------
1 file changed, 15 insertions(+), 13 deletions(-)
Index: src/gdb/frame.c
===================================================================
--- src.orig/gdb/frame.c 2007-03-18 23:22:10.000000000 +0000
+++ src/gdb/frame.c 2007-03-20 00:29:42.000000000 +0000
@@ -953,19 +953,6 @@ static struct frame_info *selected_frame
struct frame_info *
get_selected_frame (const char *message)
{
- if (selected_frame == NULL)
- {
- if (message != NULL && (!target_has_registers
- || !target_has_stack
- || !target_has_memory))
- error (("%s"), message);
- /* Hey! Don't trust this. It should really be re-finding the
- last selected frame of the currently selected thread. This,
- though, is better than nothing. */
- select_frame (get_current_frame ());
- }
- /* There is always a frame. */
- gdb_assert (selected_frame != NULL);
return selected_frame;
}
@@ -994,6 +981,21 @@ select_frame (struct frame_info *fi)
if (deprecated_selected_frame_level_changed_hook)
deprecated_selected_frame_level_changed_hook (frame_relative_level (fi));
+ if (fi == NULL)
+ {
+ if (!target_has_registers
+ || !target_has_stack
+ || !target_has_memory)
+ return;
+
+ /* Hey! Don't trust this. It should really be re-finding the
+ last selected frame of the currently selected thread. This,
+ though, is better than nothing. */
+ selected_frame = get_current_frame ();
+ }
+ /* There is always a frame. */
+ gdb_assert (selected_frame != NULL);
+
/* FIXME: kseitz/2002-08-28: It would be nice to call
selected_frame_level_changed_event() right here, but due to limitations
in the current interfaces, we would end up flooding UIs with events
next prev parent reply other threads:[~2007-03-20 0:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-19 1:53 Pedro Alves
2007-03-19 2:11 ` Daniel Jacobowitz
2007-03-19 15:58 ` Denis PILAT
2007-03-27 20:09 ` Daniel Jacobowitz
2007-04-17 15:48 ` [RFA] TUI is broken under Solaris Denis PILAT
2007-04-17 15:51 ` Daniel Jacobowitz
2007-04-18 8:24 ` Denis PILAT
2007-03-19 21:43 ` TUI + gdbserver broken? Pedro Alves
2007-03-19 22:14 ` Daniel Jacobowitz
2007-03-19 23:31 ` Pedro Alves
2007-03-19 23:41 ` Daniel Jacobowitz
2007-03-20 0:39 ` Pedro Alves [this message]
2007-03-20 2:56 ` Daniel Jacobowitz
2007-03-20 9:05 ` Pedro Alves
2007-03-20 23:21 ` Pedro Alves
2007-03-22 2:51 ` Pedro Alves
2007-03-27 20:15 ` Daniel Jacobowitz
2007-03-29 2:26 ` Pedro Alves
2007-03-29 18:55 ` Daniel Jacobowitz
[not found] <45F7480C.5010207@portugalmail.pt>
2007-03-14 8:29 ` Denis PILAT
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45FF2D16.6030501@portugalmail.pt \
--to=pedro_alves@portugalmail.pt \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox