Help! DW function pointer encoding for PA

Help! DW function pointer encoding for PA

[John David Anglin]

In trying to get dwarf2 exceptions and unwinding working under hppa-linux,
I have run into a problem that I don't know how to solve.  The
stdexceptions.cc test program seg faults when linked with shared
libstdc++ and libgcc_s when _Unwind_RaiseException does an indirect call
to the personality function because the call doesn't use a PLABEL.  A
PLABEL is required because the call goes from one library to another
and pic offset table register must be set.  In order for $$dyncall
to recognize the function pointer as a PLABEL pointer, the 'L' bit
in the pointer must be set.  We also need a PLABEL for the function.

There seem to be a number of issues.  I have tried using indirect
encoding for pic global function pointers and munging the encoded address.
Indirect doesn't yield a plabel constructor for the function reference.
I get

        .hidden DW.ref.__gxx_personality_v0
	.weak   DW.ref.__gxx_personality_v0
	.section        .gnu.linkonce.d.DW.ref.__gxx_personality_v0,"aw",@progbits
	.align 4
	.type   DW.ref.__gxx_personality_v0,@object
	.size   DW.ref.__gxx_personality_v0,4
DW.ref.__gxx_personality_v0:
	.word   __gxx_personality_v0

Maybe a special version of "dw2_force_const_mem" is needed?

When I munge the address in ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX to make it
look like a plabel, then the FDE search fails.  So, it seems that even
if I managed to create a plabel for the function address, and a pointer
to the plabel with the 'L' bit set in the pointer, it's still unlikely
that the search will work because of the 'L' bit.  Maybe, the best
solution is a port dependent method to fix function pointers that are
used for calls?

This is most serious for the personality function because it is called
directly.  The jumps to the exception landing pads can be handled
although I think there are some minor issues with the priority level
of code which ideally needs to be inserted into the return pointer from
the context state.

Any thoughts on how to get this working with shared libraries?

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

Re: Help! DW function pointer encoding for PA

[Richard Henderson]

On Thu, Feb 21, 2002 at 02:34:16AM -0500, John David Anglin wrote:
> When I munge the address in ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX to make it
> look like a plabel, then the FDE search fails.

] @findex ASM_PREFERRED_EH_DATA_FORMAT
] @item ASM_PREFERRED_EH_DATA_FORMAT(@var{code}, @var{global})
] This macro chooses the encoding of pointers embedded in the exception
] handling sections.  If at all possible, this should be defined such
] that the exception handling section will not require dynamic relocations,
] and so may be read-only.
] 
] @var{code} is 0 for data, 1 for code labels, 2 for function pointers.
] @var{global} is true if the symbol may be affected by dynamic relocations.
] The macro should return a combination of the @code{DW_EH_PE_*} defines
] as found in @file{dwarf2.h}.

Note CODE==1 vs CODE==2.  You should be able to distinguish your
two cases based on this.  If absolutely necessary, pass type information
from ASM_PREFERRED_EH_DATA_FORMAT to ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX
via bits >= 0x100, ie bits that won't appear in the output file.

Note that ia64 has the same sort of function descriptor vs FDE
code label sorts of issues.


r~

Re: Help! DW function pointer encoding for PA

[John David Anglin]

> Note CODE==1 vs CODE==2.  You should be able to distinguish your
> two cases based on this.  If absolutely necessary, pass type information

That's in fact what I was trying to use.

> from ASM_PREFERRED_EH_DATA_FORMAT to ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX
> via bits >= 0x100, ie bits that won't appear in the output file.
> 
> Note that ia64 has the same sort of function descriptor vs FDE
> code label sorts of issues.

I'll have to look more carefully at the ia64.  I think I see what
ia64_expand_call is doing to handle the function descriptor vs FDE
issue:

      dest = force_reg (DImode, gen_rtx_MEM (DImode, addr));
      emit_move_insn (pic_offset_table_rtx,
		      gen_rtx_MEM (DImode, plus_constant (addr, 8)));

So, it explicitly loads the pic_offset_table_rtx.  I think we can do
the same.  I beginning to think indirect calls from one shared library
to another may never have worked on the PA.

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

Re: Help! DW function pointer encoding for PA

[John David Anglin]

> I'll have to look more carefully at the ia64.  I think I see what
> ia64_expand_call is doing to handle the function descriptor vs FDE
> issue:

It appears that the PA has a serious problem in its handling of function
descriptors.  This small test program demonstrates the problem:

int f (int (*func)(void)) { func(); }
int main (void);
int (*i)(void) = &main;
int main() { f (i); f (main); }

This is the assembly output showing how the plabels for the two calls
in main are treated:

	addil LR'i-$global$,%r27
	ldw RR'i-$global$(%r1),%r26
	.CALL ARGW0=GR
	bl f,%r2
	nop
	ldil LR'L$C0000,%r19
	ldw RR'L$C0000(%r19),%r26
	.CALL ARGW0=GR
	bl f,%r2
	nop

As can be seen, the call using  plabel "i" is handled correctly.  However,
for the plabel L$C0000 used in the second call, we are in fact loading the
address of the function from the descriptor rather than the address of the
descriptor.  Thus, indirect calls where the pic register changes value won't
work.  I don't know how this went unnoticed for so long.

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

Re: Help! DW function pointer encoding for PA

[David Edelsohn]

	As a point of comparison, the AIX and powerpc64-linux
configurations (which also uses function descriptors) do the right thing
for your testcase.

David