From: Pedro Alves <pedro_alves@portugalmail.pt>
To: Jim Blandy <jimb@red-bean.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: arm_addr_bits_remove
Date: Wed, 23 Jan 2008 14:45:00 -0000 [thread overview]
Message-ID: <479752C8.8030201@portugalmail.pt> (raw)
In-Reply-To: <8f2776cb0801221525w1d26661dgf6452f876197a591@mail.gmail.com>
Jim Blandy wrote:
> I'm not an ARM expert by any means, so I don't object to the patch,
> but I wonder if allowing arm_pc_is_thumb to return the wrong answer
> for the first address beyond the end of a function will cause other
> problems elsewhere.
>
[FWIW, I'm not an ARM expert either]
> If it is valuable to make arm_pc_is_thumb accurate in this case, when
> it can't find a minsym at memaddr, and memaddr > 0, would it make
> sense to look for a minsym at memaddr - 1, and see if MSYMBOL_SIZE (m)
> != 0 && SYMBOL_VALUE_ADDRESS (m) + MSYMBOL_SIZE (m) == memaddr, and
> use m if so?
>
With that you'll be certain that there is a symbol *before* the
address you want to check, and you'll be sure about it's mode,
and I'm sure that most of the times that mode will be the same as
the mode of memaddr, but you can't be sure, can you?
I'd say that relying on the mode of first address beyond the end
of a function to infer something about the function itself is broken.
In those cases the '- 1' should be applied explicitly on the
call to arm_pc_is_thumb (or earlier on the call stack).
The case I stumbled on the bug is a bit different from that
case you mentioned, because the line info doesn't refer to a possible
function which includes memaddr or ends before memaddr. There was no
real code at the address the lookup was being performed, because
it refers to the end of the object file, where padding is being
performed, but real code in a different mode could be there. If
there was code there, then the correct mode for it could be
inferred, and it could be different from memaddr-1 -- at
least that's my understanding. I could be wrong though. :-)
An earlier version of the patch changed arm_addr_bits_remove to
call a new function arm_mode_at_pc that returned arm, thumb or
unknown. Only if that returned arm, I'd strip bit 1. But then,
if that bit is not used for any encoding (unlike bit 0), we can
just never strip it, and save us the min sym lookup to begin with.
That is, the patch removes one usage of arm_pc_is_thumb when
it can't always provide a correct answer.
--
Pedro Alves
next prev parent reply other threads:[~2008-01-23 14:45 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-22 21:17 arm_addr_bits_remove Pedro Alves
2008-01-22 23:26 ` arm_addr_bits_remove Jim Blandy
2008-01-23 14:45 ` Pedro Alves [this message]
2008-01-23 19:22 ` arm_addr_bits_remove Jim Blandy
2008-01-23 19:29 ` arm_addr_bits_remove Daniel Jacobowitz
2008-01-23 21:12 ` arm_addr_bits_remove Jim Blandy
2008-01-24 4:54 ` arm_addr_bits_remove Pedro Alves
2008-01-24 7:35 ` arm_addr_bits_remove Jim Blandy
2008-01-24 6:30 ` arm_addr_bits_remove Jim Blandy
2008-01-24 13:39 ` arm_addr_bits_remove Pedro Alves
2008-01-24 14:45 ` arm_addr_bits_remove Daniel Jacobowitz
2008-01-24 14:56 ` arm_addr_bits_remove Pedro Alves
2008-01-24 16:53 ` arm_addr_bits_remove Jim Blandy
2008-01-24 17:01 ` arm_addr_bits_remove Pedro Alves
2008-01-24 22:19 ` arm_addr_bits_remove Joel Brobecker
2008-01-25 0:11 ` arm_addr_bits_remove Pedro Alves
2008-01-25 4:13 ` arm_addr_bits_remove Joel Brobecker
2008-01-25 9:56 ` arm_addr_bits_remove Carlos O'Donell
2008-01-25 21:24 ` arm_addr_bits_remove John David Anglin
2008-01-25 22:14 ` arm_addr_bits_remove Jim Blandy
2008-01-26 13:57 ` arm_addr_bits_remove John David Anglin
2008-02-04 10:16 ` arm_addr_bits_remove Maciej W. Rozycki
2008-02-04 13:41 ` arm_addr_bits_remove Daniel Jacobowitz
2008-02-04 14:45 ` arm_addr_bits_remove Maciej W. Rozycki
2008-02-04 14:51 ` arm_addr_bits_remove Daniel Jacobowitz
2008-02-04 15:20 ` arm_addr_bits_remove Maciej W. Rozycki
2008-01-24 17:18 ` arm_addr_bits_remove Mark Kettenis
2008-01-24 17:50 ` arm_addr_bits_remove Joel Brobecker
2008-01-24 21:33 ` arm_addr_bits_remove Jim Blandy
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=479752C8.8030201@portugalmail.pt \
--to=pedro_alves@portugalmail.pt \
--cc=gdb-patches@sourceware.org \
--cc=jimb@red-bean.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