Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@codesourcery.com>
To: gdb-patches@sourceware.org
Subject: Re: [rfc] Work around ARM RV compiler unwind info
Date: Tue, 19 Dec 2006 20:33:00 -0000	[thread overview]
Message-ID: <m3odpz7hgs.fsf@codesourcery.com> (raw)
In-Reply-To: <20061218215900.GA22892@nevyn.them.org> (Daniel Jacobowitz's message of "Mon, 18 Dec 2006 16:59:00 -0500")


Daniel Jacobowitz <drow@false.org> writes:
> ARM's compilers generate, overall, very good debug info.  It's poorly
> supported by GDB, for various reasons: a few places where the debug info is
> in fact wrong, and a number where it is so very right that GDB can't handle
> it (since we rely on less correct information typically output by GCC).
> Unfortunately this is one of the former cases, but it's one that I think is
> tentatively worth supporting in GDB.
>
> The compilers have two problems.  Both have been fixed, but the fixes are
> conditionalized, for maximum compatibility with other ARM tools that made
> the same assumptions.
>
>   - When generating DWARF2, with the version field in .debug_frame set to
>     1, they assume that DW_CFA_def_cfa and DW_CFA_def_cfa_offset take
>     factored offsets instead of unfactored.  Using --dwarf3 makes this
>     problem go away; the first ARM compilers to generate DWARF3 were
>     released after this bug was found.
>
>   - When generating either DWARF2 or DWARF3 (CIE version 1 or 3), they
>     assume that a reg_offset rule for the CFA is REG - OFFSET instead of
>     REG + OFFSET.  RVCT 3.0 has this problem.  RVCT 3.0 SP1 does not;
>     but it marks the output with an "armcc+" augmentation to indicate
>     that it has the standard DWARF meaning, again for compatibility
>     with other versions of ARM tools.
>
> These aren't reverse engineered fixes, by the way - I spoke with the ARM
> compiler team about the proper checks.  I only turn on either of the fixes
> if the file also has .debug_info, so that we can find a producer string that
> unambiguously indicates that the ARM compiler was used.
>
> What do you think?  Useful?  Too ugly?

It's hard for me to guess how much benefit these will provide to
users, but it seems like the burden this patch places on GDB
developers is pretty minor; given the task, I think it's pretty clean.
Since we want to grow GDB's user base, I'm in favor of this patch.


  reply	other threads:[~2006-12-19 20:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-18 21:59 Daniel Jacobowitz
2006-12-19 20:33 ` Jim Blandy [this message]
2007-01-04 20:25   ` Daniel Jacobowitz

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=m3odpz7hgs.fsf@codesourcery.com \
    --to=jimb@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