From: Luis Machado <lgustavo@codesourcery.com>
To: "'gdb-patches@sourceware.org'" <gdb-patches@sourceware.org>
Subject: Re: [PATCH, testsuite] Fix gdb.cp/nsalias.exp issues
Date: Wed, 18 Jun 2014 11:37:00 -0000 [thread overview]
Message-ID: <53A179E6.8060701@codesourcery.com> (raw)
In-Reply-To: <53A15242.2070105@codesourcery.com>
[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]
On 06/18/2014 09:48 AM, Luis Machado wrote:
> Hi,
>
> I've been chasing failures on gdb.cp/nsalias.exp for MIPS, but the
> strange thing is that the failures only reproduced with a GDB built
> without optimization.
>
> Upon further investigation, i noticed the testcase was generating
> DW_AT_high_pc and DW_AT_low_pc entries with type DW_FORM_string, which
> is wrong.
>
> GDB was using that information to load data as strings, and then
> proceeded to use the string pointers as addresses.
>
> Even then, the test was passing just fine, because we were lucky enough
> to have the low_pc string pointer smaller than the high_pc string pointer.
>
> The following patch fixes two issues. The first one is the
> DW_FORM_string type. The second one is adjusting the addresses so that
> they are non-zero, since GDB doesn't like seeing 0 in these fields due
> to a check contained in dwarf2_get_pc_bounds:
>
> if (low == 0 && !dwarf2_per_objfile->has_section_at_zero)
> return 0;
>
> With both fixes, the testcase passes deterministically, and the failures
> i saw for the MIPS case were bad luck with the pointer comparisons.
>
> OK?
Updated patch without the spurious whitespaces before the closing brackets.
[-- Attachment #2: nsalias.diff --]
[-- Type: text/x-patch, Size: 876 bytes --]
2014-06-18 Luis Machado <lgustavo@codesourcery.com>
* gdb.cp/nsalias.exp: Set type of low_pc and high_pc entries
to DW_FORM_addr and use non-zero addresses.
diff --git a/gdb/testsuite/gdb.cp/nsalias.exp b/gdb/testsuite/gdb.cp/nsalias.exp
index f99b609..1179c1c 100644
--- a/gdb/testsuite/gdb.cp/nsalias.exp
+++ b/gdb/testsuite/gdb.cp/nsalias.exp
@@ -153,20 +153,20 @@ Dwarf::assemble $asm_file {
subprogram {
{specification :$im_foo_label}
- {low_pc 0x0}
- {high_pc 0x1}
+ {low_pc 0x1 DW_FORM_addr}
+ {high_pc 0x2 DW_FORM_addr}
}
subprogram {
{specification :$i_foo_label}
- {low_pc 0x2}
- {high_pc 0x3}
+ {low_pc 0x3 DW_FORM_addr}
+ {high_pc 0x4 DW_FORM_addr}
}
subprogram {
{specification :$o_foo_label}
- {low_pc 0x4}
- {high_pc 0x5}
+ {low_pc 0x5 DW_FORM_addr}
+ {high_pc 0x6 DW_FORM_addr}
}
}
}
next prev parent reply other threads:[~2014-06-18 11:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-18 8:48 Luis Machado
2014-06-18 11:37 ` Luis Machado [this message]
2014-06-18 14:31 ` Tom Tromey
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=53A179E6.8060701@codesourcery.com \
--to=lgustavo@codesourcery.com \
--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