[PATCH] D24085: arm: Fix ttype encoding assertion failure.

[Logan Chien via cfe-commits]

logan added inline comments.


> mclow.lists wrote in cxa_personality.cpp:363
> It's not clear to me how this accomplishes what you want.
> You're looking for `00/10/90`, right?  Why not just check for that?
> 
> Why are you anding with 0x0f ?
> Before, this would pass only a single value - `DW_EH_PE_absptr` (aka 0)
> With this change, it passes 32 values: 00, 03, 10, 13, 20, 23, and so on.
> 
> Was that your intent?

`ttypeEncoding` is encoded with following rules:

1. Lower 4 bits stand for the representation of the data, such as `absptr`, `uleb128`, `udata1`, `udata2`, `udata4`, `udata8`, etc.  These bits control the way we extract the bytes from the exception table.

2. Upper 4 bits stand for the post processing action, such as `pcrel`, `indirect`, etc.  For example, if `pcrel` is specified, then we should add the value, which was read in step 1, with the address of the value.

My intention is to weaken the assertion (only assert the essential assumption) so that we don't have to alter the assertion  if there are new configurations that I am not aware of or new compiler which is generating different ttypeEncoding.

Since the upcoming lines (L365) only uses `sizeof(uintptr_t)` to decode the TType pointer, it is not necessary to impose restriction on the upper 4 bits.  That's the reason why I wrote `ttypeEncoding & 0xf`.  For the same reason, both `absptr` and `udata` have the same meaning (4 bytes in the exception table) in this context, thus I am adding extra `(ttypeEncoding & 0x0f) == DW_EH_PE_udata4`.

https://reviews.llvm.org/D24085