Treatment of TType encoding in EHT entries

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

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

For static it uses absptr too:

.byte 0 # @TType Encoding = absptr

...

.long _ZTIi # TypeInfo 1

For arm-linux we print

.byte 0 @ @TType Encoding = absptr

.long _ZTIi(target2) @ TypeInfo 1

Not sure what target2 means, but it is from
ARMElfTargetObjectFile::getTTypeGlobalReference.

Cheers,
Rafael

Not sure what target2 means, but it is from
ARMElfTargetObjectFile::getTTypeGlobalReference.

TARGET2 is a special relocation used on ARM for ttype pointers.