[LLVMdev] Treatment of TType encoding in EHT entries

[Mathias Bauer]

Hi,

I ran into a crash using Objective-C with llvm/clang on ARM-Linux. The 
crash happens while unwinding the stack from pthread_exit as soon as the 
first call frame is reached that belongs to a function that uses the 
personality routine from libobjc2.

This function is in a shared library (libgnustepbase), and here's the 
start of its entry in the execption table:

GCC_except_table20:
.Lexception20:
         .byte   255                     @ @LPStart Encoding = omit
         .byte   0                       @ @TType Encoding = absptr
         .ascii  "\314\001"              @ @TType base offset

So it definitely uses DW_EH_PE_absptr as TType encoding.

The personality routine in the Objective-C runtime library reads the 
type table record and interpretes the data in it as an absolute pointer 
that is used without any further adjustment - but obviously the value 
isn't a valid pointer, so this leads to a crash.

Now I wonder: does that mean that the runtime treats DW_EH_PE_absptr 
wrong or does that mean that the EHT entry or the data in the types 
table is wrong? I could not find any documentation about treating 
DW_EH_PE_absptr in any other way than interpreting the data as an 
absolute pointer, and other PRs that I have checked seemed to apply the 
same treatment. But then what sense does it make to use absptr encoding 
in a shared library?

On X86 the generated EHT has DW_EH_PE_pcrel as TType encoding, BTW.

Any help would be most welcome.

Regards,
Mathias