RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-24 19:52:54 +01:00
Code Issues Projects Releases Wiki Activity
b5ee38a511
llvm-mirror/test/tools/llvm-objdump/win64-unwind-data.test

108 lines
3.6 KiB
Plaintext
Raw Normal View History

Re-submit r191472 with a fix for big endian. llvm-objdump: Dump COFF import table if -private-headers option is given. llvm-svn: 191557
2013-09-27 23:04:00 +02:00
// This test checks that the unwind data is dumped by llvm-objdump.
llvm-objdump: Print x64 unwind info in executable. The original code does not work correctly on executable files because the code is written in such a way that only object files are assumed to be given to llvm-objdump. Contents of RuntimeFunction are different between executables and objects. In executables, fields in RuntimeFunction have actual addresses to unwind info structures. On the other hand, in object files, the fields have zero value, but instead there are relocations pointing to the fields, so that Linker will fill them at link-time. So, when we are reading an object file, we need to use relocation info to find the location of unwind info. When executable, we should just look at the values in RuntimeFunction. llvm-svn: 202785
2014-03-04 05:00:55 +01:00
// RUN: llvm-objdump -u %p/Inputs/win64-unwind.exe.coff-x86_64.obj \
// RUN: | FileCheck -check-prefix=OBJ %s
// RUN: llvm-objdump -u %p/Inputs/win64-unwind.exe.coff-x86_64.exe \
// RUN: | FileCheck -check-prefix=EXE %s
Re-submit r191472 with a fix for big endian. llvm-objdump: Dump COFF import table if -private-headers option is given. llvm-svn: 191557
2013-09-27 23:04:00 +02:00
llvm-objdump: Print x64 unwind info in executable. The original code does not work correctly on executable files because the code is written in such a way that only object files are assumed to be given to llvm-objdump. Contents of RuntimeFunction are different between executables and objects. In executables, fields in RuntimeFunction have actual addresses to unwind info structures. On the other hand, in object files, the fields have zero value, but instead there are relocations pointing to the fields, so that Linker will fill them at link-time. So, when we are reading an object file, we need to use relocation info to find the location of unwind info. When executable, we should just look at the values in RuntimeFunction. llvm-svn: 202785
2014-03-04 05:00:55 +01:00
OBJ: Unwind info:
OBJ: Function Table:
OBJ-NEXT: Start Address: func
OBJ-NEXT: End Address: func + 0x001b
OBJ-NEXT: Unwind Info Address: .xdata
llvm-objdump: Indent unwind info contents. Unwind info contents were indented at the same level as function table contents. That's a bit confusing because the unwind info is pointed by function table. In other places we usually increment indentation depth by one when dereferncing a pointer. This patch also removes extraneous newlines between function tables. llvm-svn: 202879
2014-03-04 20:23:56 +01:00
OBJ-NEXT: Version: 1
OBJ-NEXT: Flags: 1 UNW_ExceptionHandler
OBJ-NEXT: Size of prolog: 18
OBJ-NEXT: Number of Codes: 8
OBJ-NEXT: Frame register: RBX
OBJ-NEXT: Frame offset: 0
OBJ-NEXT: Unwind Codes:
OBJ-NEXT: 0x12: UOP_SetFPReg
OBJ-NEXT: 0x0f: UOP_PushNonVol RBX
OBJ-NEXT: 0x0e: UOP_SaveXMM128 XMM8 [0x0000]
OBJ-NEXT: 0x09: UOP_SaveNonVol RSI [0x0010]
OBJ-NEXT: 0x04: UOP_AllocSmall 24
OBJ-NEXT: 0x00: UOP_PushMachFrame w/o error code
llvm-objdump: Print x64 unwind info in executable. The original code does not work correctly on executable files because the code is written in such a way that only object files are assumed to be given to llvm-objdump. Contents of RuntimeFunction are different between executables and objects. In executables, fields in RuntimeFunction have actual addresses to unwind info structures. On the other hand, in object files, the fields have zero value, but instead there are relocations pointing to the fields, so that Linker will fill them at link-time. So, when we are reading an object file, we need to use relocation info to find the location of unwind info. When executable, we should just look at the values in RuntimeFunction. llvm-svn: 202785
2014-03-04 05:00:55 +01:00
OBJ: Function Table:
OBJ-NEXT: Start Address: func + 0x0012
OBJ-NEXT: End Address: func + 0x0012
OBJ-NEXT: Unwind Info Address: .xdata + 0x001c
llvm-objdump: Indent unwind info contents. Unwind info contents were indented at the same level as function table contents. That's a bit confusing because the unwind info is pointed by function table. In other places we usually increment indentation depth by one when dereferncing a pointer. This patch also removes extraneous newlines between function tables. llvm-svn: 202879
2014-03-04 20:23:56 +01:00
OBJ-NEXT: Version: 1
OBJ-NEXT: Flags: 4 UNW_ChainInfo
OBJ-NEXT: Size of prolog: 0
OBJ-NEXT: Number of Codes: 0
OBJ-NEXT: No frame pointer used
llvm-objdump: Print x64 unwind info in executable. The original code does not work correctly on executable files because the code is written in such a way that only object files are assumed to be given to llvm-objdump. Contents of RuntimeFunction are different between executables and objects. In executables, fields in RuntimeFunction have actual addresses to unwind info structures. On the other hand, in object files, the fields have zero value, but instead there are relocations pointing to the fields, so that Linker will fill them at link-time. So, when we are reading an object file, we need to use relocation info to find the location of unwind info. When executable, we should just look at the values in RuntimeFunction. llvm-svn: 202785
2014-03-04 05:00:55 +01:00
OBJ: Function Table:
OBJ-NEXT: Start Address: smallFunc
OBJ-NEXT: End Address: smallFunc + 0x0001
OBJ-NEXT: Unwind Info Address: .xdata + 0x002c
llvm-objdump: Indent unwind info contents. Unwind info contents were indented at the same level as function table contents. That's a bit confusing because the unwind info is pointed by function table. In other places we usually increment indentation depth by one when dereferncing a pointer. This patch also removes extraneous newlines between function tables. llvm-svn: 202879
2014-03-04 20:23:56 +01:00
OBJ-NEXT: Version: 1
OBJ-NEXT: Flags: 0
OBJ-NEXT: Size of prolog: 0
OBJ-NEXT: Number of Codes: 0
OBJ-NEXT: No frame pointer used
llvm-objdump: Print x64 unwind info in executable. The original code does not work correctly on executable files because the code is written in such a way that only object files are assumed to be given to llvm-objdump. Contents of RuntimeFunction are different between executables and objects. In executables, fields in RuntimeFunction have actual addresses to unwind info structures. On the other hand, in object files, the fields have zero value, but instead there are relocations pointing to the fields, so that Linker will fill them at link-time. So, when we are reading an object file, we need to use relocation info to find the location of unwind info. When executable, we should just look at the values in RuntimeFunction. llvm-svn: 202785
2014-03-04 05:00:55 +01:00
OBJ: Function Table:
OBJ-NEXT: Start Address: allocFunc
OBJ-NEXT: End Address: allocFunc + 0x001d
OBJ-NEXT: Unwind Info Address: .xdata + 0x0034
llvm-objdump: Indent unwind info contents. Unwind info contents were indented at the same level as function table contents. That's a bit confusing because the unwind info is pointed by function table. In other places we usually increment indentation depth by one when dereferncing a pointer. This patch also removes extraneous newlines between function tables. llvm-svn: 202879
2014-03-04 20:23:56 +01:00
OBJ-NEXT: Version: 1
OBJ-NEXT: Flags: 0
OBJ-NEXT: Size of prolog: 14
OBJ-NEXT: Number of Codes: 6
OBJ-NEXT: No frame pointer used
OBJ-NEXT: Unwind Codes:
OBJ-NEXT: 0x0e: UOP_AllocLarge 8454128
OBJ-NEXT: 0x07: UOP_AllocLarge 8190
OBJ-NEXT: 0x00: UOP_PushMachFrame w/o error code
llvm-objdump: Print x64 unwind info in executable. The original code does not work correctly on executable files because the code is written in such a way that only object files are assumed to be given to llvm-objdump. Contents of RuntimeFunction are different between executables and objects. In executables, fields in RuntimeFunction have actual addresses to unwind info structures. On the other hand, in object files, the fields have zero value, but instead there are relocations pointing to the fields, so that Linker will fill them at link-time. So, when we are reading an object file, we need to use relocation info to find the location of unwind info. When executable, we should just look at the values in RuntimeFunction. llvm-svn: 202785
2014-03-04 05:00:55 +01:00
llvm-objdump: Indent unwind info contents. Unwind info contents were indented at the same level as function table contents. That's a bit confusing because the unwind info is pointed by function table. In other places we usually increment indentation depth by one when dereferncing a pointer. This patch also removes extraneous newlines between function tables. llvm-svn: 202879
2014-03-04 20:23:56 +01:00
EXE: Function Table:
EXE-NEXT: Start Address: 0x1000
EXE-NEXT: End Address: 0x101b
EXE-NEXT: Unwind Info Address: 0x2000
EXE-NEXT: Version: 1
EXE-NEXT: Flags: 1 UNW_ExceptionHandler
EXE-NEXT: Size of prolog: 18
EXE-NEXT: Number of Codes: 8
EXE-NEXT: Frame register: RBX
EXE-NEXT: Frame offset: 0
EXE-NEXT: Unwind Codes:
EXE-NEXT: 0x12: UOP_SetFPReg
EXE-NEXT: 0x0f: UOP_PushNonVol RBX
EXE-NEXT: 0x0e: UOP_SaveXMM128 XMM8 [0x0000]
EXE-NEXT: 0x09: UOP_SaveNonVol RSI [0x0010]
EXE-NEXT: 0x04: UOP_AllocSmall 24
EXE-NEXT: 0x00: UOP_PushMachFrame w/o error code
llvm-objdump: Print x64 unwind info in executable. The original code does not work correctly on executable files because the code is written in such a way that only object files are assumed to be given to llvm-objdump. Contents of RuntimeFunction are different between executables and objects. In executables, fields in RuntimeFunction have actual addresses to unwind info structures. On the other hand, in object files, the fields have zero value, but instead there are relocations pointing to the fields, so that Linker will fill them at link-time. So, when we are reading an object file, we need to use relocation info to find the location of unwind info. When executable, we should just look at the values in RuntimeFunction. llvm-svn: 202785
2014-03-04 05:00:55 +01:00
llvm-objdump: Indent unwind info contents. Unwind info contents were indented at the same level as function table contents. That's a bit confusing because the unwind info is pointed by function table. In other places we usually increment indentation depth by one when dereferncing a pointer. This patch also removes extraneous newlines between function tables. llvm-svn: 202879
2014-03-04 20:23:56 +01:00
EXE: Function Table:
EXE-NEXT: Start Address: 0x1012
EXE-NEXT: End Address: 0x1012
EXE-NEXT: Unwind Info Address: 0x201c
EXE-NEXT: Version: 1
EXE-NEXT: Flags: 4 UNW_ChainInfo
EXE-NEXT: Size of prolog: 0
EXE-NEXT: Number of Codes: 0
EXE-NEXT: No frame pointer used
llvm-objdump: Print x64 unwind info in executable. The original code does not work correctly on executable files because the code is written in such a way that only object files are assumed to be given to llvm-objdump. Contents of RuntimeFunction are different between executables and objects. In executables, fields in RuntimeFunction have actual addresses to unwind info structures. On the other hand, in object files, the fields have zero value, but instead there are relocations pointing to the fields, so that Linker will fill them at link-time. So, when we are reading an object file, we need to use relocation info to find the location of unwind info. When executable, we should just look at the values in RuntimeFunction. llvm-svn: 202785
2014-03-04 05:00:55 +01:00
llvm-objdump: Indent unwind info contents. Unwind info contents were indented at the same level as function table contents. That's a bit confusing because the unwind info is pointed by function table. In other places we usually increment indentation depth by one when dereferncing a pointer. This patch also removes extraneous newlines between function tables. llvm-svn: 202879
2014-03-04 20:23:56 +01:00
EXE: Function Table:
EXE-NEXT: Start Address: 0x101b
EXE-NEXT: End Address: 0x101c
EXE-NEXT: Unwind Info Address: 0x202c
EXE-NEXT: Version: 1
EXE-NEXT: Flags: 0
EXE-NEXT: Size of prolog: 0
EXE-NEXT: Number of Codes: 0
EXE-NEXT: No frame pointer used
llvm-objdump: Print x64 unwind info in executable. The original code does not work correctly on executable files because the code is written in such a way that only object files are assumed to be given to llvm-objdump. Contents of RuntimeFunction are different between executables and objects. In executables, fields in RuntimeFunction have actual addresses to unwind info structures. On the other hand, in object files, the fields have zero value, but instead there are relocations pointing to the fields, so that Linker will fill them at link-time. So, when we are reading an object file, we need to use relocation info to find the location of unwind info. When executable, we should just look at the values in RuntimeFunction. llvm-svn: 202785
2014-03-04 05:00:55 +01:00
llvm-objdump: Indent unwind info contents. Unwind info contents were indented at the same level as function table contents. That's a bit confusing because the unwind info is pointed by function table. In other places we usually increment indentation depth by one when dereferncing a pointer. This patch also removes extraneous newlines between function tables. llvm-svn: 202879
2014-03-04 20:23:56 +01:00
EXE: Function Table:
EXE-NEXT: Start Address: 0x101c
EXE-NEXT: End Address: 0x1039
EXE-NEXT: Unwind Info Address: 0x2034
EXE-NEXT: Version: 1
EXE-NEXT: Flags: 0
EXE-NEXT: Size of prolog: 14
EXE-NEXT: Number of Codes: 6
EXE-NEXT: No frame pointer used
EXE-NEXT: Unwind Codes:
EXE-NEXT: 0x0e: UOP_AllocLarge 8454128
EXE-NEXT: 0x07: UOP_AllocLarge 8190
EXE-NEXT: 0x00: UOP_PushMachFrame w/o error code
Reference in New Issue Copy Permalink