I’m not not-trusting that you know what you’re doing. I’m trying to understand it for myself, so that I can make the necessary changes to get it working on Windows.
On the other hand, Windows does have plenty of different rules and assumptions when it comes to how it generates code. So while I’m confident that you guys have thought about it and made something that works well within the context of non-Windows, it’s a given that some of the functionality is going to be broken when the assumptions change. Not because you didn’t know what you were doing, but because the code wasn’t designed with these assumptions in mind. Otherwise it would have just already worked and this thread would have never been created
So it’s not enough for me to just say “I have to trust that it works, therefore I must be doing something wrong”, but I also need to understand the architecture and the details well enough to be able figure out if it doesn’t work because of some fundamental differences in Windows vs. non-Windows, or if it doesn’t work because I have a bug somewhere in my process plugin, or something else.
One of the questions I keep asking myself is: Why, when using one of the native Windows debuggers such as MSVC or WinDbg, if I step over a call, does it always work even if the called function has no debug info, no unwind info, and uses FPO?
Maybe it’s related to them having better function bounds in their COFF parser, as you suggested. I’m going to look into that, but I just want to re-emphasize that none of my posts, including this one, are intended to second guess anyone’s decisions. But at the same time it’s only natural to expect that since many of the assumptions were made without Windows in mind, they may prove to be slightly wrong.
There’s not very many detailed design documents about how things work, and in certain areas code documentation is sparse. So the purpose of me asking is simply to understand how it works.
Hope this makes sense.