From: Jason Molenda <jmolenda@apple.com>
To: Jeff Johnston <jjohnstn@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Fix for do_mixed_source_and_assembly in disasm.c
Date: Thu, 18 Dec 2003 22:12:00 -0000 [thread overview]
Message-ID: <4C0916E8-31A7-11D8-BFBD-000393D457E2@apple.com> (raw)
In-Reply-To: <3FE0C778.8010606@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]
Hi Jeff,
On Dec 17, 2003, at 1:15 PM, Jeff Johnston wrote:
> There are a few bugs in do_mixed_source_and_assembly() when dealing
> with the ia64.
I hit one of the two bugs you're fixing last week, namely the double
call to close off the list/tuple. My first fix looked like yours, but
I think a slight reworking of the loop is very desirable here. Right
now this loop looks approximately like this:
Set close_list to 1 (the list/tuple will be closed at the end of
this loop)
First entry of a new source line number:
Start a "src_and_asm_line" tuple, print the source line.
Start a "line_asm_insn" list where instructions will be emitted.
If we're not at the end of the mle array, and the next mle entry's
source line number is not greater than the current source line entry,
DON'T close off the list (close_list = 0)
Print the assembly instructions for the current address range.
If close_list is 1, close the tuple/list.
Which is a very convoluted way of writing a loop, and more importantly,
this only works correctly for one or two assembly ranges for a single
source line. If you have a third, on the 2nd iter the tuple/list are
closed and then on the 3rd you close them again.
Instead, this is more clear:
First entry of a new source line number:
Start a "src_and_asm_line" tuple, print the source line.
Start a "line_asm_insn" list where instructions will be emitted.
Print the assembly instructions for the current address range.
If we're at the end of the mle array or the next entry in the array
is a new source line, close off the list and tuple.
I also took the opportunity to combine two conditional statements - I
won't push hard for that part of the change, but the rest is a clear
improvement IMHO.
We only had this code path executed when we were using a compiler with
a bug in it internally, so it's not too easy for me to reproduce/test
this. I've tried to combine my patch and yours against the current FSF
TOT. What do you think of my suggested additional change? Can you try
it on the IA64 test case you have?
Jason
[-- Attachment #2: pa.txt --]
[-- Type: text/plain, Size: 1992 bytes --]
Index: disasm.c
===================================================================
RCS file: /cvs/src/src/gdb/disasm.c,v
retrieving revision 1.17
diff -u -p -r1.17 disasm.c
--- disasm.c 24 Oct 2003 17:37:03 -0000 1.17
+++ disasm.c 18 Dec 2003 22:05:20 -0000
@@ -164,6 +164,8 @@ do_mixed_source_and_assembly (struct ui_
CORE_ADDR pc;
int num_displayed = 0;
struct cleanup *ui_out_chain;
+ struct cleanup *ui_out_tuple_chain = NULL;
+ struct cleanup *ui_out_list_chain = NULL;
mle = (struct dis_line_entry *) alloca (nlines
* sizeof (struct dis_line_entry));
@@ -221,10 +223,6 @@ do_mixed_source_and_assembly (struct ui_
for (i = 0; i < newlines; i++)
{
- struct cleanup *ui_out_tuple_chain = NULL;
- struct cleanup *ui_out_list_chain = NULL;
- int close_list = 1;
-
/* Print out everything from next_line to the current line. */
if (mle[i].line >= next_line)
{
@@ -275,22 +273,22 @@ do_mixed_source_and_assembly (struct ui_
next_line = mle[i].line + 1;
ui_out_list_chain
= make_cleanup_ui_out_list_begin_end (uiout, "line_asm_insn");
- /* Don't close the list if the lines are not in order. */
- if (i < (newlines - 1) && mle[i + 1].line <= mle[i].line)
- close_list = 0;
}
num_displayed += dump_insns (uiout, di, mle[i].start_pc, mle[i].end_pc,
how_many, stb);
- if (close_list)
+
+ /* When we've reached the end of the mle array, or we've seen the last
+ assembly range for this source line, close out the list/tuple. */
+ if (i == (newlines - 1) || mle[i + 1].line > mle[i].line)
{
do_cleanups (ui_out_list_chain);
do_cleanups (ui_out_tuple_chain);
+ ui_out_tuple_chain = NULL;
+ ui_out_list_chain = NULL;
ui_out_text (uiout, "\n");
- close_list = 0;
}
- if (how_many >= 0)
- if (num_displayed >= how_many)
+ if (how_many >= 0 && num_displayed >= how_many)
break;
}
do_cleanups (ui_out_chain);
next prev parent reply other threads:[~2003-12-18 22:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-17 21:15 Jeff Johnston
2003-12-18 22:12 ` Jason Molenda [this message]
2003-12-18 23:07 ` J. Johnston
2004-01-02 16:13 ` Andrew Cagney
2004-01-06 19:11 ` J. Johnston
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=4C0916E8-31A7-11D8-BFBD-000393D457E2@apple.com \
--to=jmolenda@apple.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jjohnstn@redhat.com \
/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