This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: arm_addr_bits_remove


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'?


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.

If you start talking about addresses, and symbol tables, you wander into the realm of function addresses and official procedure descriptors (OPD).

On 32-bit hppa-linux-gnu the address of a function may point to the function or the official procedure descriptor (On 64-bit you always have an OPD). The OPD address has bit 2 set, and bit 1 is reserved (See pg 31 of the 32-bit SOM Runtime). The OPD is a struct { ELF32 ip; ELF32 gp}. If (<function symbol> & 3) is true you have a function address, otherwise an OPD. To read the OPD you strip the bottom 2 bits, cast to a struct, and use ip and gp.

Might the writer of the comment gotten confused?

I guess that compiler would be HP's.  If the symbols had the bits set,
so could the line info.

Right. That's why I mentioned the fact that part of my toolchain was from GNU tools.

Do we still support HP's object format and debug info ?

Not sure.

HP's 32-bit HP-PARISC object format is SOM.


Dave, binutils still has SOM support?

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

Cheers,
Carlos.
--
Carlos O'Donell
CodeSourcery
carlos@codesourcery.com
(650) 331-3385 x716


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]