Re: update dwarf2 asm unwind info [hppa64-*-* failures]

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

> Before I do that maybe you or David could help me understand something I
> see when running 'readelf -wf'.  If I compile my test, link static, and
> run readelf -wf on 'old' code.  I see a single .eh_frame section, with
> the changed code I see two .eh_frame sections in the object file.  Is
> that OK?  Is it expected?  It doesn't seem right to have two .eh_frame
> sections but I am not an ELF expert.

I don't recall ever seeing two .eh_frame sections.  Look at the file
with readelf -a.  It might be some section flags, etc, are preventing
the two from being merged.

Also, I was not able to get pc-relative relocations to work on this target.
It is some time ago that I tried but the summary as to why this didn't work is:

  Although the HP-UX 64-bit ELF linker can handle unaligned pc-relative
  fixups, the runtime doesn't have a consistent relationship between
  text and data for dynamically loaded objects.  Thus, it's not possible
  to use pc-relative encoding for pointers on this target.

When I tested this, I emitted "+8-$PIC_pcrel$0 directly in GCC.  I believe
this avoids the assembler issue that Richard's patch fixes.

Essentially, I found it impossible to use pc-relative relocations when
the relocation in a data section references a text symbol.  The linker
doesn't complain.  However, no dynamic relocations are generated to handle
the inconsistent relationship between text and data.  This has to do with
the segmented memory architecture.  Using pc-relative relocations works
on hppa-linux because it has a non-segmented memory architecture (all
segments use the same space register value) and the dynamic loader
preserves the relationship between text and data when it loads a program.
This doesn't happen on hppa64-hpux.

So, if one of the .eh_frame sections is readonly, it will be placed in
the text quadrant.  The other section that you are seeing might be in the
data quadrant.  Any data that requires dynamic relocation must be in a
writeable section.

The personality function is the major problem.  Since this function has
to be called, either the .eh_frame data has to contain a plabel for it
or a pointer to the plabel.  The plabel has to be in a data section.
So, if the .eh_frame section lies in the data quadrant, there is a problem
in using pc-relative relocations to determine code addresses.  If the
.eh_frame section is in the text quadrant, there is a problem accessing
the plabel.  Possibly, there is some tricky way to do this through
the DLT but I haven't figured out how.

That's why I used DW_EH_PE_aligned and DW_EH_PE_absptr.  These are
handled by the linker and dynamic loader.

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