wip correct unwinding for JIT frames

[carnaval]

No description provided.

[yuyichao]

Ref #12380 ... I guess I finally understand what that PR was for after going through these ourselves. It looks like ORCJIT might not have the problem with 32bit offset? (although the function we tested with was also very small). There also seems to be another (local only) mechanism that support larger offset.

[maleadt]

Maybe add some comments on what the code does?

[carnaval]

@yuyichao oh man. I knew I saw this somewhere. arg. Well all this time we spent reading libunwind source was somewhat instructive anyway. I'll see if we can use the "nice" local version today to avoid parsing the sections ourselves.

@maleadt yup at least before merging. This is just clerical work because the feature of libunwind we use to register new unwinding info dynamically for JIT code was not meant to register whole ELF objects at once so we have to do a little manual work (split the relevant section into pieces).

[carnaval]

I don't think the local format allows larger offsets though since as I remember it it just fills the same table of (int32,int32) in the end.

As for the ugly code, it may make sense to just patch libunwind anyway to have a proper register_elf_image_buffer() or something, but in the meantime that will do.

[carnaval]

(or just write an unwinder in julia =))

[tkelman]

Keno probably has a repo for that somewhere

[yuyichao]

I'll see if we can use the "nice" local version today to avoid parsing the sections ourselves.

IIRC all the functions that contains section names are called on a file so probably not without patching.

I remember it it just fills the same table of (int32,int32) in the end.

You are right, I thought the list is stored in a slightly different format (since I remember there's no pointer cast). Turns out they just use struct table_entry * but didn't define it in the header.....

patch libunwind anyway to have a proper register_elf_image_buffer() or something

Seems that libunwind also only look for debug_frame but not eh_frame. That might need to be fixed too...

or just write an unwinder in julia =)

Unfortunately not really when we are in signal context.

[carnaval]

let's use #12380 instead, it's cleaner and together with the libunwind patch handles the 32 bit overflow condition Keno found with mcjit.

[yuyichao]

Agree. I've just been using this patch since it's easier to rebase and test =P.