Re: arm_addr_bits_remove

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> On Jan 25, 2008 10:49 AM, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> > Regarding symbol tables, I would have to check what the two bits are
> > used for.  What struct/bits?
> 
> Within GDB, the debug info readers call record_line to add each source
> location / pc mapping they find to GDB's internal tables.  The issue
> at hand is that record_line currently calls gdbarch_addr_bits_remove
> on the pc values it's passed before recording them; apparently some
> debug info had extra bits set in the addresses in the line number
> info.  Since this doesn't meet the spec (of either DWARF or STABS),
> it's a bug in the producer; the call to gdbarch_addr_bits_remove is
> meant to work around that bug.  We've been discussing removing that
> call, since it has caused problems recently.

I think the comment is likely wrong.  I can see using the bits in
dwarf or stabs information might cause problems.  Hopefully, this
isn't the case (ie., binutils doesn't need fixing).

It is possible the bits need masking from the relocated unwind or
the HP debug info in the $DEBUG$ space.  The best source of information
for HP debug info is the HP-UX 10.20 run-time architecure document.
I believe this information was dropped from the public HP-UX 11
document.

The bits do arise whenever the program counter is saved on the stack
or copied to a register.  In that case, the bits need to masked.
This probably should be done arlier.

Priority can occur on calls.  This normally only used for system
calls.  There is no support priority changes in GCC.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)