- User Since
- May 26 2014, 12:49 PM (229 w, 1 d)
Mon, Oct 15
Fri, Oct 12
Thu, Oct 11
I think the SymbolContext should have enough information. As long as you can find the PDBSymbolFunction for the current frame, that gives you the range of the function, and the IDiaSymbol for the variable should give you the important info like register, offset, etc.
Why is FileCheck missing in the first place?
Is the thread I'm referring to.
See the other email thread. The bots have been broken since September, all
of them complain about missing FileCheck executable
Wed, Oct 10
I can try to get some timings from my machine. How do we handle crash
recovery in the case where we don't spawn a child process? I thought the
whole reason for spawning the cc1 driver as a separate process was so that
we could collect and report crash information in a nice way. Not having
that seems like a heavy price to pay.
If you plan to invest in more substantial changes in ObjectFilePECOFF, it might worth considering a complete re-write in terms of llvm::object::coff. It has pretty comprehensive support for the PE/COFF spec, so it's just a matter of implementing ObjectFilePECOFF on top of it.
Nice find, thanks
You didn't include it here, but I notice the test file just writes clang-cl /Zi. Should we be passing -m32 or -m64? Currently, the test just runs with whatever architecture happens to be set via the VS command prompt. The behavior here is different on x86 and x64 so perhaps it requires separate tests.
By the way, what do you think, how can we make LLDB support aligned stacks? As far as I know, similar alignment problems are reproducible on non-Windows too.
Tue, Oct 9
Use lldbassert. The main reason I didn't use this originally is because it didn't used to be a hard assert. But since it seems like it is now, I've no problem standardizing on this.
Addressed suggestions from Leonard.
@lemo Thanks for the detailed review! I'll fix the suggestions and upload a new patch in a bit.
BTW, sorry this took so long for anyone to review. I think partly it's because nobody here really taken the time to understand in detail how MS precompiled headers works, so we were all hoping someone else would review it. :-/
Addressed all issues pointed out by various people, and added a few more tests. There's only a limited amount of stuff we can do without a running process, so I'll probably have to resort to lldb-test soon to be able to print more detailed information.
How big are the object files?
It was actually failing for a different reason first (malformed run line
due to backquote), which is the failure in the bot you linked. But I fixed
that and it never went green due to the new issue which you mentioned,
which does seem to be endianness related. Either way, it doesn't change
your point that the bots have been red for a long time. Do you have any
suggestions on how I can diagnose this? I don't have a big endian machine.
Mon, Oct 8
Fix the test. I accidentally clang-formatted it which messed up the check lines. Turn clang-format off for this file.
It's not enough to just set _HAS_EXCEPTIONS=1, it has to match whatever the value of /EH is passed to the compiler. So if we need to be able to throw catch exceptions, then you should pass /EHsc and not touch _HAS_EXCEPTIONS (technically you could set it to 1 but that's the default). And if we don't need to be able to throw or catch exceptions, then we pass /EHs-c- (which is what we do today) and also set _HAS_EXCEPTIONS=0. But the two should agree with each other.
_HAS_EXCEPTIONS=0 is an undocumented STL specific thing that the library
implementation uses to mean "don't write code that does throw X;, do
something else instead".
Sun, Oct 7
I never got around to getting this committed, but incidentally I built a new machine over the weekend and ran into the same problem *plus* an additional problem which is that with Python 3, git apply doesn't like it when universal_newlines is set to true. Without this additional changes, it is impossible to push anything using the following configuration:
Thu, Oct 4
To be clear, I never suggested we should treat cmd.exe as a valid choice of
external shell. What I meant was that the two supported configurations
I agree magic environment variables are bad, but without it we don’t
address the only current actual use we have for this, which is making the
vs integration print filenames. Detecting compiler version from inside the
integration is hard, but with an environment variable it’s very easy to
Wed, Oct 3
I personally think we should never use bash on Windows (wsl being the
exception but that won’t identify as Windows anyway). There’s value in
consistency and in my ideal world the lit shell would be feature rich
enough that we wouldn’t have to use bash *anywhere*. In any case right now
the configuration matrix is Windows (lit shell) and non Windows (bash). I
don’t think we should grow this by supporting Windows (bash)
Tue, Oct 2
Ahh I see. You need to say "Differential Revision:
https://reviews.llvm.org/D50404" in the commit message. just the URL is
not sufficient to trigger the magic auto-close.
It would be great if we could land this soon-ish. I have a lot of people complaining that lld-link rejects /DEBUG:FASTLINK when using the VS extension. Is there any work left to be done or can we land this?