maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/COFF/pdb-debug-f.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

28 lines
826 B
ArmAsm
Raw Normal View History

[COFF] Add missing Requires x86 to fix buildbot Add REQUIRES: x86 to pdb-debug-f.s as this is causing the Arm and AArch64 buildbots to fail as they do not have the x86 backend. Differential Revision: https://reviews.llvm.org/D52606 llvm-svn: 343196
2018-09-27 20:07:47 +08:00
# REQUIRES: x86
[PDB] Emit old fpo data to the PDB file. r342003 added support for emitting FPO data from the DEBUG_S_FRAMEDATA subsection of the .debug$S section to the PDB file. However, that is not the end of the story. FPO can end up in two different destinations in a PDB, each corresponding to a different FPO data source. The case handled by r342003 involves copying data from the DEBUG_S_FRAMEDATA subsection of the .debug$S section to the "New FPO" stream in the PDB, which is then referred to by the DBI stream. The case handled by this patch involves copying records from the .debug$F section of an object file to the "FPO" stream (or perhaps more aptly, the "Old FPO" stream) in the PDB file, which is also referred to by the DBI stream. The formats are largely similar, and the difference is mostly only visible in masm generated object files, such as some of the low-level CRT object files like memcpy. MASM doesn't appear to support writing the DEBUG_S_FRAMEDATA subsection, and instead just writes these records to the .debug$F section. Although clang-cl does not emit a .debug$F section ever, lld still needs to support it so we have good debugging for CRT functions. Differential Revision: https://reviews.llvm.org/D51958 llvm-svn: 342080
2018-09-13 05:02:01 +08:00
# RUN: llvm-mc -triple=i386-pc-win32 -filetype=obj -o %t.obj %s
[COFF] Implement /safeseh:no and check @feat.00 flags by default Summary: Fixes PR41828. Before this, LLD always emitted SafeSEH chunks and defined __safe_se_handler_table & size. Now, /safeseh:no leaves those undefined. Additionally, we were checking for the safeseh @feat.00 flag in two places: once to emit errors, and once during safeseh table construction. The error was set up to be off by default, but safeseh is supposed to be on by default. I combined the two checks, so now LLD emits an error if an input object lacks @feat.00 and safeseh is enabled. This caused the majority of 32-bit LLD tests to fail, since many test input object files lack @feat.00 symbols. I explicitly added -safeseh:no to those tests to preserve behavior. Finally, LLD no longer sets IMAGE_DLL_CHARACTERISTICS_NO_SEH if any input file wasn't compiled for safeseh. Reviewers: mstorsjo, ruiu, thakis Reviewed By: ruiu, thakis Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63570 llvm-svn: 366238
2019-07-17 02:17:33 +08:00
# RUN: lld-link -safeseh:no /subsystem:console /debug /nodefaultlib /entry:foo /out:%t.exe /pdb:%t.pdb %t.obj
[PDB] Emit old fpo data to the PDB file. r342003 added support for emitting FPO data from the DEBUG_S_FRAMEDATA subsection of the .debug$S section to the PDB file. However, that is not the end of the story. FPO can end up in two different destinations in a PDB, each corresponding to a different FPO data source. The case handled by r342003 involves copying data from the DEBUG_S_FRAMEDATA subsection of the .debug$S section to the "New FPO" stream in the PDB, which is then referred to by the DBI stream. The case handled by this patch involves copying records from the .debug$F section of an object file to the "FPO" stream (or perhaps more aptly, the "Old FPO" stream) in the PDB file, which is also referred to by the DBI stream. The formats are largely similar, and the difference is mostly only visible in masm generated object files, such as some of the low-level CRT object files like memcpy. MASM doesn't appear to support writing the DEBUG_S_FRAMEDATA subsection, and instead just writes these records to the .debug$F section. Although clang-cl does not emit a .debug$F section ever, lld still needs to support it so we have good debugging for CRT functions. Differential Revision: https://reviews.llvm.org/D51958 llvm-svn: 342080
2018-09-13 05:02:01 +08:00
# RUN: llvm-pdbutil dump -fpo %t.pdb | FileCheck %s
# CHECK: Old FPO Data
# CHECK-NEXT: ============================================================
# CHECK-NEXT: RVA | Code | Locals | Params | Prolog | Saved Regs | Use BP | Has SEH | Frame Type
# CHECK-NEXT: 00001002 | 1 | 2 | 3 | 4 | 0 | false | false | FPO
.text
_foo:
ret
.global _foo
.section .debug$F,"dr"
.long _foo@IMGREL+2
.long 1 # cbProc
.long 2 # cdwLocals;
.short 3 # cdwParams;
.short 4 # flags
# cbProlog : 8;
# cbRegs : 3;
# fHasSEH : 1;
# fUseBP : 1;
# reserved : 1;
# cbFrame : 2;