From: "J. Johnston" <jjohnstn@redhat.com>
To: Jason Molenda <jmolenda@apple.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 23:07:00 -0000 [thread overview]
Message-ID: <3FE23319.9000009@redhat.com> (raw)
In-Reply-To: <4C0916E8-31A7-11D8-BFBD-000393D457E2@apple.com>
Jason Molenda wrote:
> 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
>
Works fine. I like the revision you made. I don't know if the powers-that-be
will review this patch before the New Year.
-- Jeff J.
next prev parent reply other threads:[~2003-12-18 23:07 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
2003-12-18 23:07 ` J. Johnston [this message]
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=3FE23319.9000009@redhat.com \
--to=jjohnstn@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jmolenda@apple.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