Re: arm_addr_bits_remove

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

> Joel Brobecker wrote:
> >>   /* The low two bits of the PC on the PA contain the privilege level.
> >>      Some genius implementing a (non-GCC) compiler apparently decided
> >>      this means that "addresses" in a text section therefore include a
> >>      privilege level, and thus symbol tables should contain these bits.
> >>      This seems like a bonehead thing to do--anyway, it seems to work
> >>      for our purposes to just ignore those bits.  */
> > 
> > I just love the comment :). I'm so happy I'm not the HP genius
> > in question :-). Seriously, I think we should be careful not to
> > add more sarcastic comments like this in the future, it's not
> > very serious nor very useful. That being said, I love sarcasm,
> > so I had a good laugh.
> 
> What do they mean by `"addresses" in a text section'?

Memory addresses are the same everywhere.  In the PA 1.x architecture,
there are four qudrants (i.e., the architecture is segmented) each which
can address 4 GB of memory.  In the hpux and linux runtimes, the addressing
is restricted to 1 GB for efficiency.  Linux has a flat addressess space
(the upper four segment registers for a process are all equivalent).
The segments in hpux aren't flat.  As a result, calling stubs are more
elaborate.

The hardware has no concept of "text".  Text may be placed anywhere
in physical memory.  HP-UX typically places text in one quadrant,
data in another and shared text in another.  Howver, code can execute
from anywhere.  The text quadrant in HP-UX is readonly.  Code can
read it and we do this for jump tables in GCC.

You have to be aware that instructions can only execute from a
four byte aligned location and mask the two least least significant
bits when doing arithmetic involving the pc.  Other than that, user
code isn't really aware of the priority bits and the associated
access restrictions.

Regarding symbol tables, I would have to check what the two bits are
used for.  What struct/bits?

> The only thing that should have a privilege level (PL) is the PC (IAOQ) 
> at runtime, and it should match the PL of the executing instruction.
> 
> HP's 32-bit HP-PARISC object format is SOM.
> 
> Dave, binutils still has SOM support?

Yes.

> We still generate some HP debug info, namely .PARISC.unwind sections, 
> and AFAIK gdb uses them (readelf shows them correctly)?

GCC uses the .stabs format.  The .unwind sections are used by gdb,
Ada and probably other code that has unwind support.  Recent versions
of GCC use dwarf2 unwind info in the data section for exception
support.  I posted a patch a year or so ago to add dwarf2 debug support
but nobody commented on it.  There is a bit of support that needs
to be added to binutils that's not done yet.

Other than the unwind sections, HP debug info is only useful for
debugging applications compiled with HP tools.  HP has provided
wdb for years to do this.

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