bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/628] gas emits duplicate line-number info for each instruction


From: wilson at specifixinc dot com
Subject: [Bug gas/628] gas emits duplicate line-number info for each instruction
Date: 4 Jan 2005 03:37:04 -0000

------- Additional Comments From wilson at specifixinc dot com  2005-01-04 
03:37 -------
Subject: Re:  gas emits duplicate line-number info for each
        instruction

On Thu, 2004-12-30 at 18:10, davidm at hpl dot hp dot com wrote:
> This proposed patch fixes the bug by handling the .loc directive the same way
> as tc-xtends.c does.

I get 247 gdb failures without this patch, and 962 gdb failures with the
patch.

The idea is sound, but the implementation needs a little work.  Because
we read up to 4 instructions at a time before emitting a bundle, we
actually need 4 loc_directive_seen bits, one for each pending
instruction.  We can do this by moving the bit inside struct slot.  This
is to ensure that we call dwarf2_gen_line_info for the instruction that
actually had the .loc directive.  You can see that the results with your
patch are a little screwy, as all line numbers are now associated with
bundle start addresses, which is so unlikely that it can't be correct. 
With this trivial fix, I now get non-bundle aligned addresses associated
with line numbers as before, and gdb results look better.  I need to
rebuild from scratch to be sure, but my hacked rebuild got 230 gdb
failures, so it is looking good so far.

On the downside, the fixed patch doesn't eliminate as many line numbers
as your patch does, but then your patch was eliminating a few too many
of them.  Your testcase now has 15 line number opcodes instead of the 12
that you got.  But this is still better than the unpatched 28.

I also need to check that I am setting the loc_directive_seen bit for
the right slots, which I haven't done yet.


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=628

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]