- User Since
- May 9 2013, 11:10 AM (244 w, 6 d)
It would be awesome to have static analysis rules to help identify *where* to put these intrinsics. Is somebody working on that? Or did I miss it?
The DWARF spec says: "If the variant part has a discriminant, the discriminant is represented by a separate debugging information entry which is a child of the variant part entry. This entry has the form of a structure data member entry. The variant part entry will have a DW_AT_descr attribute whose value is a reference to the member entry for the discriminant."
Tue, Jan 16
As I poke around the web looking for how a Rust enum-with-value works, it appears that Rust has what in Pascal would be a tagged variant record with no invariant part and no default variant. It's the web, of course, so it might be lying to me, but that's what I see, and it's about 90% of what you need for Pascal. The DWARF spec does not provide an example of a variant record, but I would expect to see something along these lines in the final DWARF:
DW_TAG_struct_type // type entry for the enum-with-fields DW_TAG_variant_part // because DWARF says variant_part is owned by the struct_type DW_AT_discr // reference to the discriminator field DW_TAG_member // this is the discriminator field, where the enum value is stored DW_TAG_variant // wrapper for the first variant DW_AT_discr_value // first discriminant value DW_TAG_member ... // member(s) for the first variant DW_TAG_variant // wrapper for the second variant DW_AT_discr_value // second discriminant value DW_TAG_member ... // member(s) for the second variant // etc
Is that what you are trying to produce?
DWARF discriminated unions were likely designed to support Pascal variant records, which do allow multiple fields per variant. If we're going to support discriminated unions (which seems reasonable) then it ought to be general enough to handle the Pascal case.
Fri, Jan 12
There's a medium-term goal of migrating to git, so an svn-based script seems like the wrong direction.
I've been using the experimental git mono-repo for a while and I'm finding it pretty convenient. A sample configuration script for setting up a useful subset of projects and canonical CMake parameters seems like a good helpful starting point.
Thu, Jan 11
Thanks! I'll commit this tomorrow.
Simplify a bit, making assumptions the verifier will check for us.
So, I just posted a review without specifying the Repository for the diff, but I did put it on the review, and it auto-subscribed llvm-commits.
I suspect there's no real reason to put it on a diff, and we shouldn't tell people to do that.
See D41965 for verifier change.
And there are no subscribers on this review...
Thinking about the Desired Visible Effect, the auto-subscription would be on the Revision and not on the Diff, assuming that it's the subscriber list on the Revision that determines where the emails go.
But that would be sensible from the end-user's point of view, which doesn't mean it's actually how the software works. :-)
So, the checksum will come in from the front-end as a string in DIFile. It wants to be binary in the .o file. What happens in-between is maybe not optimal, but has to address a couple of considerations.
First, where is it stored and who owns the memory? As a StringRef it's not clear, but as an MD5Result it really ought to be owned by MCContext (the CodeView path does the same thing). AsmPrinter does this allocation and conversion.
Second, from AsmPrinter it goes to "the streamer" which might be emitting an object file or might be emitting a text file, but AsmPrinter (despite its name) doesn't know which. For type and memory safety I chose to have the MC API take an MD5Result* instead of yet another StringRef. For emitting a text file, MCAsmStreamer converts it back to text, and then the AsmParser reads the text and converts it back to binary before passing it to "the (object-file) streamer." AsmParser needs to validate the string when it does this conversion. Then the object-file streamer has binary data and just emits it to the object file without any further fuss. For emitting an object-file directly, AsmPrinter passes it along as binary data and there are no additional conversions in the path.
Wed, Jan 10
I'm scared to actually approve it, but I can see the clear parallel with the AND case just afterwards, so it seems like the right thing to do.
the dagcombine rule (zext (truncate x)) -> (zext (truncate x)).
Tue, Jan 9
Committed in rL322134. (Forgot to put the Differential Revision tag in the commit message.)
Address review feedback.
Mon, Jan 8
Fri, Jan 5
See inline comment. I think that makes it clear enough where to look for details about what values to use for the MAXSIZE/DIR parameters.
I know off-list I had suggested not bothering with detailed descriptions of LLVM_CCACHE_SIZE and LLVM_CCACHE_DIR, but now I am not so sure. If those variables map directly to ccache command-line arguments, we should say that here, and people can figure out how to set them by looking at the appropriate help. If the variables are more complicated, we should add separate entries for them in this doc.
Thu, Jan 4
Wed, Jan 3
Should the lower bound also become an expression? My FORTRAN days are long gone but my impression is that the lower bound isn't necessarily fixed at compile-time, in more modern editions of the language.
Thu, Dec 28
In a real object file it should never be zero. There are a bunch of places in the unittests where I construct one with version and addrsize both zero; those would have to be fixed if we wanted to have a check somewhere other than for a form that actually cares about that stuff.
Tue, Dec 26
Sorry, missed this somehow... I didn't really look at the second layer, but I have a suggestion for the initial tree walk.
Thu, Dec 21
Wed, Dec 20
With the GDB test results and LLDB able to handle it, this LGTM.
Carlos, do you have commit access?
Dec 18 2017
Dec 15 2017
Dec 14 2017
Dec 13 2017
Philosophically, mangled names and DWARF information serve different purposes, and I don't think you will find one true solution where both of them can yield the same name that everyone will be happy with. Mangled names exist to provide unique and reproducible identifiers for the "same" entity across compilation units. They are carefully specified (for example) to allow a linker to associate a reference in one object file to a definition in a different object file, and be guaranteed that the association is correct. A demangled name is a necessarily context-free translation of the mangled name into something that has a closer relationship to how a human would think of or write the name of the thing, but isn't necessarily the only way to write the name of the thing.
Dec 11 2017
I should note we've had at least one request to make this specifiable per-function, which would mean defining an attribute to control the emission of the fake-use intrinsics. Doing the feature that way would be consistent with 'optnone'.
Dec 8 2017
The title says "Add cc1 option..." which to me implies a "cc1 only" option. What you're actually doing is adding a driver option. Please update the title.
Dec 7 2017
LGTM then, so @mgrang can proceed with the (IMO rather valuable) iteration order work. And redoing aranges can go on "the list."
+rjmccall for the codegen bits.
Well... I'm not fully convinced that the stable_sort isn't just papering over some other problem, but it seems to be producing the correct final result. If @echristo is okay with it, I'm okay with it.
Dec 6 2017
Ah, thanks for the help Davide! Looks like you can do this:
if (context.getObjectFileInfo()->getTargetTriple().isOSDarwin()) LineTableVersion = 2;
and that should take care of it.
Let me see if I can find a way to force version 2 for Darwin only. I really don't want to revert again, it took months to get Chrome to fix their tools and reverting would block further work.
Dec 5 2017
Dec 4 2017
Dec 1 2017
Yeah, I copy-pasted the old code and then hacked on it for the v5 format. I should have looked at it all as new code.
Range-base for loops; tidy up commentary.
@echristo does it make sense to emit aranges without the symbols being emitted yet?