search for: unwind_info

...ed code using a manual process to populate data for RtlAddFunctionTable but I'm ultimately not interested in JIT code generation. I've managed to intercept data destined for the .pdata and .xdata COFF sections, but it seems to be garbage. All functions claim to begin at offset 0x0 and the UNWIND_INFO offsets are all 0-based instead of pointing into any relevant part of the image. Given a day or so I could provide a small example that generates this useless data, but before I go to that extent - am I just doing something dumb/forgetting a step/etc. when it comes to generating stack walk metada...

...ot;canonical" name [2]. - Otherwise: - Rename to "<segment name>.<section name>" (the separator is `.' not `,') - If the segment name does not start with `_', prefix it with `LC_SEGMENT.' For example, __TEXT,__text is renamed to .text and __TEXT,__unwind_info is renamed to __TEXT.__unwind_info. For that reason, specifying a section in command line options is rather nonintuitive: WRONG: objcopy --only-secton=__TEXT,__text a.out WRONG: objcopy --only-secton=__TEXT.__text a.out OK: objcopy --only-secton=.text a.out WRONG: objcopy --only-secton=__TEXT,__u...

...that’s basically the proposal here. So while not ideal, it’s certainly familiar. How will people use llvm-objcopy when the segment and section names legitimately contain “.” or “,” characters? Will these be escapable? The rest of the behavior, especially around “__TEXT.__text is bad but __TEXT.__unwind_info is good”, is pretty confusing. Can we define our own “canonical names” for canonical sections such as __unwind_info? > > Thanks, > > James > > On Thu, 23 May 2019 at 05:43, Seiya Nuta <nuta at seiya.me <mailto:nuta at seiya.me>> wrote: > Hi, > > I'm...

...DE (etext = .); + .rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) } + .rodata1 : { *(.rodata1) } + .sdata2 : + { + *(.sdata2 .sdata2.* .gnu.linkonce.s2.*) + } + .sbss2 : { *(.sbss2 .sbss2.* .gnu.linkonce.sb2.*) } + .opd : { *(.opd) } + .IA_64.unwind_info : { KEEP(*(.IA_64.unwind_info* .gnu.linkonce.ia64unwi.*)) } + .IA_64.unwind : { KEEP(*(.IA_64.unwind* .gnu.linkonce.ia64unw.*)) } + .eh_frame_hdr : { *(.eh_frame_hdr) *(.eh_frame_entry .eh_frame_entry.*) } + .eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) *(.eh_frame.*) } + .gcc_except_t...

...DE (etext = .); + .rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) } + .rodata1 : { *(.rodata1) } + .sdata2 : + { + *(.sdata2 .sdata2.* .gnu.linkonce.s2.*) + } + .sbss2 : { *(.sbss2 .sbss2.* .gnu.linkonce.sb2.*) } + .opd : { *(.opd) } + .IA_64.unwind_info : { KEEP(*(.IA_64.unwind_info* .gnu.linkonce.ia64unwi.*)) } + .IA_64.unwind : { KEEP(*(.IA_64.unwind* .gnu.linkonce.ia64unw.*)) } + .eh_frame_hdr : { *(.eh_frame_hdr) *(.eh_frame_entry .eh_frame_entry.*) } + .eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) *(.eh_frame.*) } + .gcc_except_t...

...ects/libunwind/src/libunwind.cpp:237 237 co->getInfo(info); (gdb) print info $1 = (unw_proc_info_t *) 0x7fffffffd520 (gdb) print *info $2 = {start_ip = 140737343503848, end_ip = 140733193388033, lsda = 4223808, handler = 140737488344512, gp = 0, flags = 140737354131160, format = 4194368, unwind_info_size = 0, unwind_info = 9, extra = 8} Checking recent logs didn't reveal anything obvious so I'd be happy if you guys have any ideas about this. This is on a Linux x86-64 host. Regards, ismail

On 12/18/2014 06:58 PM, Kevin Modzelewski wrote: > I'd be interested in that, though would it be an issue if it doesn't > have an in-tree user? Quite possibly. It would bit rot if nothing else. At minimum, we need a dumper tool - possibly an option to an existing one - which produces human readable output and a bunch of lit tests to ensure it's not broken by other changes.

...RtlAddFunctionTable but I'm >> ultimately not interested in JIT code generation. >> >> >> I've managed to intercept data destined for the .pdata and .xdata COFF >> sections, but it seems to be garbage. All functions claim to begin at offset >> 0x0 and the UNWIND_INFO offsets are all 0-based instead of pointing into any >> relevant part of the image. >> >> >> Given a day or so I could provide a small example that generates this >> useless data, but before I go to that extent - am I just doing something >> dumb/forgetting a ste...

This patchset is for more paravirtualization on ia64/pv_ops. - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S) by multi compile - support save/restore For this purpose, the followings needs to be paravirtualized - ar.itc instruction - sched_clock() This is because timer may changed before/after saving/restoring. For convenience the working full

This patchset is for more paravirtualization on ia64/pv_ops. - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S) by multi compile - support save/restore For this purpose, the followings needs to be paravirtualized - ar.itc instruction - sched_clock() This is because timer may changed before/after saving/restoring. For convenience the working full

This patchset is for more paravirtualization on ia64/xen domU. - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S) by multi compile - support save/restore For this purpose, the followings needs to be paravirtualized - ar.itc instruction - sched_clock() This is because timer may changed before/after saving/restoring. For convenience the working full

This patchset is for more paravirtualization on ia64/xen domU. - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S) by multi compile - support save/restore For this purpose, the followings needs to be paravirtualized - ar.itc instruction - sched_clock() This is because timer may changed before/after saving/restoring. For convenience the working full

That's encouraging. Assuming that all access to the JITted code is going to be done through a function pointer, and all JIT code is ephemeral, why is the object container format important? In fact, why is it even needed? I found it somewhat odd that MCJIT generates an object file for even the JIT case. To answer my own question, could it be that advanced JIT's may need/want to use things

This patch set is for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for more paravirtualization on ia64/xen domU. This patch set does - remove existing warnings - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S) by multi

This patch set is for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for more paravirtualization on ia64/xen domU. This patch set does - remove existing warnings - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S) by multi

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for more paravirtualization on ia64/xen domU. This patch set does - remove existing warnings - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S)

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for more paravirtualization on ia64/xen domU. This patch set does - remove existing warnings - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S)

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for more paravirtualization on ia64/xen domU. This patch set does - remove existing warnings - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S)

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for more paravirtualization on ia64/xen domU. This patch set does - remove existing warnings - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S)