On 18/10/13 22:14, Ian Lance Taylor wrote: > What is generating the exception frames? That is, the data that > appears in the .eh_frame and (possibly) .gcc_except sections? I'm using the standard LLVM frame generation via their landingpad and addClause function. It creates .eh_func sections and .gcc_except_table functions. I'll walk through the encoding in the assembler file. > Or, are you sure that you are handling the LSDA encoding correctly? > If you are seeing DW_EH_PE_absptr then you should see an address > there. But if the LSDA encoding is DW_EH_PE_textrel then you need to > add in the text segment offset yourself. I can't be sure I am doing this correctly, since it isn't working. I got the code from another individual who is using it successfully. I also compared to the LSDA parsing in GCC's personality and it appears to be effectively the same. I definitely have code that creates addresses relative to textrel, but I don't seem to get those encoding bits. I did nothing something though, in the GCC personality the type table (TType) doesn't appear to actually be used. It simply parses it, then looks for an action record. If it finds any action record it installs the context and returns. Presumably since C++ has to do the expensive type comparison checkes in the landing anyway, there may have been no reason to do it in the handler. That is, it wouldn't matter if the TType pointer was invalid, it wouldn't notice...? -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Sign: Please digitally sign your emails. Encrypt: I'm also happy to receive encrypted mail.
Attachment:
signature.asc
Description: OpenPGP digital signature
