[LLVMdev] Treatment of TType encoding in EHT entries (original) (raw)

Mathias Bauer mathias_bauer at gmx.net
Mon Mar 17 04:34:56 PDT 2014

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

More information about the llvm-dev mailing list