Re: arm_addr_bits_remove

["Jim Blandy" <jimb@red-bean.com>]

On Jan 23, 2008 6:44 AM, Pedro Alves <pedro_alves@portugalmail.pt> wrote:
> 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 guess the thought was that if there is no symbol covering an
address, but there is a symbol whose range ends at that address, it's
a safe bet the address is some sort of endpoint (as it is in the case
at hand), and should be treated like the other addresses within the
range.

But you're right, it's a heuristic.

> 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.  :-)

So the heuristic I suggested will often be wrong.  :(  I guess you're
right that one should be subtracting one from the address somewhere
earlier in the call stack.

Looking into this a bit more, I got even more confused.  (I don't want
to get in the way of getting a bug fixed, so take this if it's helpful
and ignore it if it's not.)  Why are we calling
gdbarch_addr_bits_remove in record_line at all?  Who sets the thumb
bit in line number info?  The thumb bit is only meaningful in ELF
symbols, and values derived from those.

It seems like the use of gdbarch_addr_bits_remove originated in 2001:

2001-04-06  Fernando Nasser  <fnasser@redhat.com>

	* buildsym.c (record_line): Turn off unused addr bits.

Could we try simply removing this?