Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Wielaard <mjw@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA/DWARF] constant class of DW_AT_high_pc is offset for version >=4 only.
Date: Sun, 16 Feb 2014 19:19:00 -0000	[thread overview]
Message-ID: <1392578342.21975.12.camel@bordewijk.wildebeest.org> (raw)
In-Reply-To: <1392478818-30320-1-git-send-email-brobecker@adacore.com>

Hi Joel,

On Sat, 2014-02-15 at 19:40 +0400, Joel Brobecker wrote:
> Starting with DWARF version 4, the description of the DW_AT_high_pc
> attribute was amended to say:
> 
>    if it is of class constant, the value is an unsigned integer offset
>    which when added to the low PC gives the address of the first
>    location past the last instruction associated with the entity.
> 
> A change was made in Apr 27th, 2012 to reflect that change:
> 
>   | commit 91da14142c0171e58a91ad58a32fd010b700e761
>   | Author: Mark Wielaard <mjw@redhat.com>
>   | Date:   Fri Apr 27 18:55:19 2012 +0000
>   |
>   |     * dwarf2read.c (dwarf2_get_pc_bounds): Check DW_AT_high_pc form to
>   |     see whether it is an address or a constant offset from DW_AT_low_pc.
>   |     (dwarf2_record_block_ranges): Likewise.
>   |     (read_partial_die): Likewise.
> 
> Unfortunately, this new interpretation is now used regardless of
> the CU's DWARF version. It turns out that one of WindRiver's compilers
> (FTR: Diabdata 4.4) is generating DWARF version 2 info with
> DW_AT_high_pc attributes using the data4 form. Because of that,
> we miscompute all high PCs incorrectly.

Sorry about that. I read the spec as disallowing anything except
DW_FORM_addr to encode class address. And since before DWARF4
DW_AT_high_pc only allowed class address it hadn't occurred to me that
it could have been encoded differently. I do think this really is a bug
in the compiler that generated this.

> This patch fixes it by ammending a bit the changes from the commit
> mentioned above to use the new interpretation of a relative address
> only when the CU's DWARF version is 4 or greater.

That should work fine. GCC at least doesn't generate DW_AT_high_pc
attributes as offsets (constant class) unless it generates DWARF4+.

Cheers,

Mark



  reply	other threads:[~2014-02-16 19:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-15 15:40 Joel Brobecker
2014-02-16 19:19 ` Mark Wielaard [this message]
2014-02-17  9:19   ` Joel Brobecker
2014-02-18 13:30 ` Joel Brobecker
2014-02-18 16:03   ` Mark Wielaard
2014-02-18 18:49     ` Joel Brobecker
2014-02-18 20:29       ` Doug Evans
2014-02-18 21:52       ` Mark Wielaard
2014-02-19  7:23         ` Joel Brobecker
2014-02-19 13:44           ` Mark Wielaard
2014-02-21 18:42             ` Joel Brobecker
2014-02-26 10:53               ` Mark Wielaard
2014-02-26 19:45               ` pushed: " Joel Brobecker

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=1392578342.21975.12.camel@bordewijk.wildebeest.org \
    --to=mjw@redhat.com \
    --cc=brobecker@adacore.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