Windows missing pdata for $ss22_ContiguousArrayBufferV19firstElementAddressSpyxGvgyp_Tg5

[jaykrell]

Stepping through hello world on Windows with cdb I see missing pdata.
I build codeview and have a pdb, but that isn't relevant. pdata is a runtime non-optional feature for stackwalk, independent of symbols.

C:\s\sw1>more sw1.swift
print("hello")

0:000> .fnent .
No function entry for 00007ffd`1cf987c6
0:000> k
Child-SP          RetAddr               Call Site
00000058`c618f830 00000000`00000000     swiftSwiftOnoneSupport!$ss22_ContiguousArrayBufferV19firstElementAddressSpyxGvgyp_Tg5+0x16

The problem is not universal by far. Many other functions I stepped through do have pdata and xdata.

[AnthonyLatsis]

What's the Swift version?

[jaykrell]

I had just downloaded the current binaries within a day. Sorry that isn’t precise, yet, more later.

[al45tair]

Is this x86-64 or ARM Windows?

[al45tair]

This isn't a runtime bug; it's to do with whether the compiler generated Windows unwind information for a given function. It looks like it might actually be an LLVM issue, but to confirm I think we should hand this to IRGen folks so they can check.

[al45tair]

Hmmm. Checking the Microsoft documentation, it says:

Leaf functions are functions that don't change any non-volatile registers. A non-leaf function may change non-volatile RSP, for example, by calling a function. Or, it could change RSP by allocating additional stack space for local variables. To recover non-volatile registers when an exception is handled, non-leaf functions are annotated with static data.

(emphasis mine).

It seems to me that Swift._ContiguousArrayBuffer.firstElementAddress is a leaf function, so I wouldn't expect it to have pdata or xdata. Closing as I don't think this is a bug.

[AnthonyLatsis]

@al45tair Thanks for helping out with the triage! This area isn’t my forte.

[jaykrell]

If you so much as push, then you change rsp, then you are not a leaf.
pdata/xdata is all about recovering nonvolatile registers and return addresses and stack.

Things are specified, such that, stackwalk works from any instruction.

It doesn't work here.

This function is not a leaf, and lacks pdata/xdata.

0:000> k9
Child-SP          RetAddr               Call Site
00000077`b92ff7a8 00007ffd`2b4414fa     swiftSwiftOnoneSupport!$ss22_ContiguousArrayBufferV19firstElementAddressSpyxGvgyp_Tg5+0x10
00000077`b92ff7b0 00007ff7`0f1216ef     swiftSwiftOnoneSupport!$ss27_allocateUninitializedArrayySayxG_BptBwlFyp_Tg5+0x1a
00000077`b92ff820 00007ff7`0f122bfc     sw1!sw1::main+0xf
(Inline Function) --------`--------     sw1!invoke_main+0x22
00000077`b92ff880 00007ffd`5c4d26ad     sw1!__scrt_common_main_seh+0x10c
00000077`b92ff8c0 00007ffd`5d22aa68     KERNEL32!BaseThreadInitThunk+0x1d
00000077`b92ff8f0 00000000`00000000     ntdll!RtlUserThreadStart+0x28
0:000> .fnent .
No function entry for 00007ffd`2b4587c0
0:000> u .
swiftSwiftOnoneSupport!$ss22_ContiguousArrayBufferV19firstElementAddressSpyxGvgyp_Tg5+0x10:
00007ffd`2b4587c0 55              push    rbp
00007ffd`2b4587c1 56              push    rsi
00007ffd`2b4587c2 4883ec28        sub     rsp,28h

0:000> t
swiftSwiftOnoneSupport!$ss22_ContiguousArrayBufferV19firstElementAddressSpyxGvgyp_Tg5+0x11:
00007ffd`2b4587c1 56              push    rsi
0:000> k
Child-SP          RetAddr               Call Site
00000077`b92ff7a0 00000000`00000000     swiftSwiftOnoneSupport!$ss22_ContiguousArrayBufferV19firstElementAddressSpyxGvgyp_Tg5+0x11

[jaykrell]

This is definitely a bug. Maybe it is LLVM and not Swift, but it is a bug.

[jaykrell]

Some versions of the Microsoft documentation have confused leaf and non-leaf. I have tried to get it corrected and clarified, but it is possible things only got more confusing.

[jaykrell]

C:\s\sw1>swiftc --version
Swift version 5.9.1 (swift-5.9.1-RELEASE)
Target: x86_64-unknown-windows-msvc

[jaykrell]

ps: I have seen esp. assembly programmers get this wrong repeatedly.
Even memcpy in the C runtime had it wrong, but it got fixed.
Specifically, people think that a "leaf" function is one that doesn't call.
They think only about the callgraph/tree.
But that isn't what a leaf vs. non-leaf. A leaf function is one that does not ever change any nonvolatile registers, including rsp. Using call does make a non-leaf, but other operations do too.

[al45tair]

Microsoft does say

Leaf functions are functions that don't change any non-volatile registers.

and they clearly give the example of rsp right after as well. So I think maybe you are right, but in that case it would be an LLVM bug (since it's LLVM that's making this decision, not Swift).

It's a bit unhelpful of them to define leaf function this way, because that isn't the usual definition (normally it's a function that doesn't call anything). I can well imagine that someone might also argue that since the function doesn't call anything and doesn't itself throw any exceptions, there's no reason to provide unwind data for it — but of course that will affect debugging, which is what you're complaining about here.