On Tue, Sep 23, 2014 at 2:24 PM, Robinson, Paul < paul_robin...@playstation.sony.com> wrote:
> > One of the issues is that there's only /so/ different we can be from > > > GCC here before types/declarations/definitions won't match up in GDB. > > > > I think this might get to the nub of it: I agree that GCC/GDB matters, I > disagree that GCC/GDB is what matters. GCC/GDB compatibility may be an > important use-case but it is not the Reference Implementation of DWARF, and > in particular GCC/GDB compatibility is completely irrelevant to my > environment. My environment is 100% Clang, > What do you use as a debugger? (or other DWARF consumers that might care about whether two bits of DWARF describe the same type in the same sense that the C++ language defines) > and we care more about what the DWARF spec says than we do about whatever > GCC/GDB might choose to do for one reason or another. So, if GCC/GDB > compatibility means diverging so noticeably from what the spec says (i.e., > that the name is as it is in the source program) maybe this is a point > worth identifying as one where a divergence occurs, and make the choice > target-dependent. > Certainly it's possible to make this target-dependent - see DWARF2 support for Darwin, etc. > In a way it feels somewhat analogous to choices in supporting > extensions/dialects of C++. For practical purposes it's very worthwhile to > the community to support things that GCC supports, but that doesn't mean > that GCC defines the standard. In the case at hand, Clang has strayed from > the letter of the DWARF spec, and we'd really like to see a way back toward > it. > The DWARF spec doesn't really describe the world of templates in a complete and useful manner. I think it's problematic to try to wedge the wording into saying "DWARF says this is the one way to encode this info" - DWARF makes some general suggestions about how certain constructs could be mapped, but until there's a document like the C++ ABI that says "this is the required lowering from C++ to DWARF" (and there's buy-in to conform to this from both DWARF producers and consumers) a lot of this is going to come down to "what do consumers and producers agree to". > We're entirely willing to do work toward getting things realigned > (admittedly I personally have been mostly MIA for the past year, but I am > seeing an occasional photon from down the far end of my current tunnel) > given that the primary contributor and code owner are willing to go along > with it. > > Thanks, > > --paulr > > > > *From:* David Blaikie [mailto:dblai...@gmail.com] > *Sent:* Monday, September 22, 2014 3:47 PM > *To:* Nick Lewycky > *Cc:* Robinson, Paul; lldb-dev@cs.uiuc.edu; llvm-comm...@cs.uiuc.edu > *Subject:* Re: [lldb-dev] [RFC][PATCH] Keep un-canonicalized template > types in the debug information > > > > > > > > On Mon, Sep 22, 2014 at 3:40 PM, Nick Lewycky <nicho...@mxc.ca> wrote: > > Robinson, Paul wrote: > > I think it comes down to how the information is planning to be used. A > consumer with the dwarf information today could, in fact, get to the > S<int> type from a user who types S<A> pretty easily right? > > If the typedef actually appears in the DWARF, the consumer could figure > out what the user meant by typing S<A>, yes. In my experiments the > typedef is not always present, which leaves the user up a creek with no > paddle. > > How the debugger presents the types of things is also a consideration, > however. This is more evident with a less trivial example, such as the > vector typedef I described previously. It is clearly a step backward in > the end-user debugging experience if people are used to seeing > > S<int4> > > which the debugger has been displaying all along, but suddenly they > start seeing instead > > S<int __attribute__((ext_vector_type(4)))> > > which is what has started happening. Especially if 'int4' no longer > appears as a typedef at all, this is Just Wrong. > > > In clang, ConvertTypeToDiagnosticString deals with vectors specially. The > rationale, I think, is to prevent the compiler from showing the internal > implementation detail of how float4 and friends are defined. I think that > this is the wrong approach and would have preferred a second attribute. > Does attribute nodebug on a typedef have any meaning yet? Could we > repurpose it to mean that you shouldn't look through this typedef for > compiler diagnostics nor debug info? Any any case, our behaviour on > diagnostics and debug info should probably match here. > > > > One of the issues is that there's only /so/ different we can be from GCC > here before types/declarations/definitions won't match up in GDB. I believe > GCC has some smarts to tolerate differences like S<0> versus S<0u> or > S<'\0'> I think... at least some of those, but I don't know how it'll go > with: > > S<__attribute__((__vector_size__(4 * sizeof(int)))) int> > > V > > S<__vector(4) int> > > (using a GCC-compatible syntax, vector_size(sizeof(int) * 4) rather than > the ext_vector_type which isn't supported by GCC) > > Huh... apparently GDB ignores the entire adornment and allows > func(S<__vector(4) int>) to be called with a variable of type > S<__attribute__((__vector_size__(5 * sizeof(int)))) int> even... not sure > what to make of any of that. > > > > > Nick > > Wolfgang did some bisection and traced this change to r205447, and the > intent of that change was centered on default template arguments. This > de-referencing of typedefs appears to have been an *unintended side > effect* of that patch. > > I want my typedef'd template parameters back please… > > --paulr > > *From:*Eric Christopher [mailto:echri...@gmail.com] > *Sent:* Thursday, September 18, 2014 10:07 PM > *To:* Robinson, Paul > *Cc:* David Blaikie; lldb-dev@cs.uiuc.edu; llvm-comm...@cs.uiuc.edu; > Frédéric Riss > *Subject:* Re: [lldb-dev] [RFC][PATCH] Keep un-canonicalized template > types in the debug information > > On Thu, Sep 18, 2014 at 5:57 PM, Robinson, Paul > <paul_robin...@playstation.sony.com > > <mailto:paul_robin...@playstation.sony.com>> wrote: > > The (limited) feedback I've had from the committee is along these lines. > > If the program uses the type name "S<A>" for something, the DWARF > should fully describe the type named "S<A>" because that's the name > as-in-the-source-program. If you use both S<A> and S<int> in the > program in different places, then you need to describe both in the > DWARF. There is sadly no standard way to associate the two as > aliases. Yes in C++ they are the same; in standard DWARF they are not. > > Yeah, I'm not sure I agree with this. I've seen the thread and I'm not > sure I like the logic. > > The typedef S<A> => S<int> hack might work [if the debugger can > tolerate that]. It is obviously not a real typedef. You could mark > it artificial as an indication that something funny is going on > (artificial typedefs being highly atypical). > > The DW_AT_specification hack is just wrong, because neither S<A> nor > S<int> is completing the other. > > I need to step back from the typedef hack. I believe our debugger > throws away the <brackets> on the theory that it can reconstruct > them from template-parameter children; that is, the <bracket> part > of the name is redundant. The typedef hack does not provide those > children, and the <brackets> are not redundant, so this is likely to > be a problem for us. Feh. I'd forgotten about that detail when I > started liking the typedef hack. Yes, this means I don't have a > suggestion, apart from emitting things redundantly as needed to > preserve as-in-the-source-program. > > Here's a bizarre data point. Going back to at least 3.2, Clang has > emitted S<int> instead of S<A>. But with my vector example, it used > to use the typedef name up through 3.4. That changed in 3.5, where > the type name 'int4' has entirely disappeared from the DWARF. > Clearly that's a bug; the type name needs to be in there somewhere. > > One more thing: > > it'd be good to figure out how to deal with all possible names for > the type, even the ones the user hasn't written (eg: typedef int A; > typedef int B; and make sure that the debugger can handle S<int>, > S<A> and S<B> in their code, even though the user only wrote one of > those in the source). > > The answer to this "how to deal" question is with debugger smarts, > not more complicated DWARF. DWARF is about the program as-written > and as-compiled, not about > anything-the-user-might-conceivably-try-to-write-in-the-debugger. > Handling this in DWARF is a combinatorial nightmare, for completely > speculative purposes. Not gonna happen. > > I think it comes down to how the information is planning to be used. A > consumer with the dwarf information today could, in fact, get to the > S<int> type from a user who types S<A> pretty easily right? Now if you'd > like a way to print out the textual representation of every type as it > was used in the program that's likely to be less possible without some > serious duplication of dwarf. You could use an unnamed type for the base > and then use DW_AT_specification with just a bare DW_AT_name to avoid > some of the unpleasantness of the specification hack, but then you come > to the problem of template arguments etc. It's fairly crazy to consider, > but a user could quite easily write: > > new std::vector<int, allocator>() > > with some allocator that was never used in the program with vector and > expect the code to be generated at run time and the rest of the type to > be found. > > Anyhow, I think the best bet is for the most general type to be left in > the debug information and then the typedefs etc to be their own DIEs. > Unless we have some use that we're not talking about here? > > -eric > > --paulr > > *From:*David Blaikie [mailto:dblai...@gmail.com > <mailto:dblai...@gmail.com>] > *Sent:* Thursday, September 18, 2014 4:03 PM > > > *To:* Robinson, Paul > *Cc:* llvm-comm...@cs.uiuc.edu <mailto:llvm-comm...@cs.uiuc.edu>; > Greg Clayton; Frédéric Riss; lldb-dev@cs.uiuc.edu > <mailto:lldb-dev@cs.uiuc.edu>; jing...@apple.com > <mailto:jing...@apple.com> > *Subject:* Re: [lldb-dev] [RFC][PATCH] Keep un-canonicalized > template types in the debug information > > On Thu, Sep 18, 2014 at 2:40 PM, Robinson, Paul > <paul_robin...@playstation.sony.com > > <mailto:paul_robin...@playstation.sony.com>> wrote: > > David, > > Sorry, thought you were protesting the typedef idea as interfering > with deduplication or type-unit commonality. > > So to recap, if we have source like this: > > typedef int A; > > template<typename T> struct S { T member; }; > > S<A> s_a; > > then we'll get > > DW_TAG_typedef > > DW_AT_name "A" > > DW_AT_type -> int > > DW_TAG_structure_type > > DW_AT_name "S<A>" > > DW_TAG_member > > DW_AT_name "member" > > DW_AT_type -> int // or the typedef for "A" ? > > DW_TAG_template_type_parameter > > DW_AT_name "T" > > DW_AT_type -> (the typedef for "A") > > Are you suggesting putting the rest of S<int> here too? Or how would > S<A> refer to S<int> for the rest of the implementation? > > DW_TAG_variable > > DW_AT_name "s_a" > > DW_AT_type -> (the above structure_type) > > Ah, no - just a typedef of the template: > > 1: DW_TAG_structure_type // the debug info we already produce today > (S<int>) > ... > > 2: DW_TAG_typedef > DW_AT_name "S<A>" > DW_AT_type (1) > > And honestly, the variable would still be of type (1). > > Duplicating the entire type for each way of naming the same type is, > I'm fairly sure, not going to work for debuggers today. If someone > wants to propose a way of encoding this that will need new > code/support from debuggers, etc, then I feel the right venue to > discuss that is the DWARF committee - because you'll need buy-in > from producers and consumers. Without having that discussion, I > believe just providing a typedef of the template specialization is > probably a benefit to users. > > If we want to talk about a 'right' representation of this for DWARF > that would necessitate more substantial changes to both DWARF > producers and consumers... I think it'll be a bit more involved than > even what you're proposing. If we're going to deal with that, it'd > be good to figure out how to deal with all possible names for the > type, even the ones the user hasn't written (eg: typedef int A; > typedef int B; and make sure that the debugger can handle S<int>, > S<A> and S<B> in their code, even though the user only wrote one of > those in the source). > > Yes? > > --paulr > > *From:*David Blaikie [mailto:dblai...@gmail.com > <mailto:dblai...@gmail.com>] > *Sent:* Thursday, September 18, 2014 1:09 PM > *To:* Robinson, Paul > *Cc:* llvm-comm...@cs.uiuc.edu > <mailto:llvm-comm...@cs.uiuc.edu>; Greg Clayton; Frédéric Riss; > lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu>; > jing...@apple.com <mailto:jing...@apple.com> > *Subject:* Re: [lldb-dev] [RFC][PATCH] Keep un-canonicalized > template types in the debug information > > On Thu, Sep 18, 2014 at 1:05 PM, David Blaikie > <dblai...@gmail.com <mailto:dblai...@gmail.com>> wrote: > > On Thu, Sep 18, 2014 at 1:00 PM, Robinson, Paul > <paul_robin...@playstation.sony.com > <mailto:paul_robin...@playstation.sony.com>> wrote: > > >From: David Blaikie [mailto:dblai...@gmail.com > <mailto:dblai...@gmail.com>] > >On Wed, Sep 17, 2014 at 11:54 AM, Robinson, Paul > <paul_robin...@playstation.sony.com > <mailto:paul_robin...@playstation.sony.com>> wrote: > >> From: David Blaikie [mailto:dblai...@gmail.com > <mailto:dblai...@gmail.com>] > >> > On Wed, Sep 17, 2014 at 7:45 AM, Robinson, Paul > <paul_robin...@playstation.sony.com > <mailto:paul_robin...@playstation.sony.com>> wrote: > >> > > From: David Blaikie [mailto:dblai...@gmail.com > <mailto:dblai...@gmail.com>] > >> > > On Sat, Sep 13, 2014 at 6:54 PM, Robinson, Paul > <paul_robin...@playstation.sony.com > <mailto:paul_robin...@playstation.sony.com>> wrote: > >> > > > > > On 09 Sep 2014, at 00:01, jing...@apple.com > > <mailto:jing...@apple.com> wrote: > >> > > > > > > > >> > > > > > > From the debugger's standpoint, the functional > concern is that if you do > >> > > > > > something more real, like: > >> > > > > > > > >> > > > > > > typedef int A; > >> > > > > > > template <typename T> > >> > > > > > > struct S > >> > > > > > > { > >> > > > > > > T my_t; > >> > > > > > > }; > >> > > > > > > > >> > > > > > > I want to make sure that the type of my_t is > given as "A" not as "int". > >> > > > > > The reason for that is that it is not uncommon to > have data formatters > >> > > > > > that trigger off the typedef name. This happens > when you use some common > >> > > > > > underlying type like "int" but the value has some > special meaning when it > >> > > > > > is formally an "A", and you want to use the data > formatters to give it an > >> > > > > > appropriate presentation. Since the data > formatters work by matching type > >> > > > > > name, starting from the most specific on down, it > is important that the > >> > > > > > typedef name be preserved. > >> > > > > > > > >> > > > > > > However, it would be really odd to see: > >> > > > > > > > >> > > > > > > (lldb) expr -T -- my_s > >> > > > > > > (S<int>) $1 = { > >> > > > > > > (A) my_t = 5 > >> > > > > > > } > >> > > > > > > > >> > > > > > > instead of: > >> > > > > > > > >> > > > > > > (lldb) expr -T -- my_s > >> > > > > > > (S<A>) $1 = { > >> > > > > > > (A) my_t = 5 > >> > > > > > > } > >> > > > > > > > >> > > > > > > so I am in favor of presenting the template > parameter type with the most > >> > > > > > specific name it was given in the overall template > type name. > >> > > > > > > >> > > > > > OK, we get this wrong today. I’ll try to look into > it. > >> > > > > > > >> > > > > > What’s your take on the debug info representation > for the templated class > >> > > > > > type? The tentative patch introduces a typedef > that declares S<A> as a > >> > > > > > typedef for S<int>. The typedef doesn’t exist in > the code, thus I find it > >> > > > > > a bit of a lie to the debugger. I was more in > favour of something like : > >> > > > > > > >> > > > > > DW_TAG_variable > >> > > > > > DW_AT_type: -> DW_TAG_structure_type > >> > > > > > DW_AT_name: S<A> > >> > > > > > DW_AT_specification: -> DW_TAG_structure_type > >> > > > > > DW_AT_name: S<int> > >> > > > > > > >> > > > > > This way the canonical type is kept in the debug > information, and the > >> > > > > > declaration type is a real class type aliasing the > canonical type. But I’m > >> > > > > > not sure debuggers can digest this kind of aliasing. > >> > > > > > > >> > > > > > Fred > >> > > > > > >> > > > > Why introduce the extra typedef? S<A> should have a > template parameter > >> > > > > entry pointing to A which points to int. The info > should all be there > >> > > > > without any extra stuff. Or if you think something > is missing, please > >> > > > > provide a more complete example. > >> > > > My immediate concern here would be either loss of > information or bloat > >> > > > when using that with type units (either bloat because > each instantiation > >> > > > with differently spelled (but identical) parameters is > treated as a separate > >> > > > type - or loss when the types are considered the same > and all but one are > >> > > > dropped at link time) > >> > > You'll need to unpack that more because I'm not > following the concern. > >> > > If the typedefs are spelled differently, don't they > count as different types? > >> > > DWARF wants to describe the program as-written, and > there's no S<int> written > >> > > in the program. > >> > > > >> > > Maybe not in this TU, but possibly in another TU? Or by > the user. > >> > > > >> > > void func(S<int>); > >> > > ... > >> > > typedef int A; > >> > > S<A> s; > >> > > func(s); // calls the same function > >> > > > >> > > The user probably wants to be able to call void func > with S<int> or S<A> > >> > Sure. > >> > > >> > > (and, actually, in theory, with S<B> where B is another > typedef of int, but > >> > > that'll /really/ require DWARF consumer support and/or > new DWARF wording). > >> > > >> > Not DWARF wording. DWARF doesn't say when you can and > can't call something; > >> > that's a debugger feature and therefore a debugger decision. > >> > > >> What I mean is we'd need some new DWARF to help explain > which types are > >> equivalent (or the debugger would have to do a lot of > spelunking to try > >> to find structurally equivalent types - "S<B>" and "S<A>", > go look through > >> their DW_TAG_template_type_params, see if they are typedefs > to the same > >> underlying type, etc... ) > >> > > >> > > >> > > We can't emit these as completely independent types - it > would be verbose > >> > > (every instantiation with different typedefs would be a > whole separate type > >> > > in the DWARF, not deduplicated by type units, etc) and > wrong > >> > > >> > Yes, "typedef int A;" creates a synonym/alias not a new > type, so S<A> and S<int> > >> > describe the same type from the C++ perspective, so you > don't want two complete > >> > descriptions with different names, because that really > would be describing them > >> > as separate types. What wrinkles my brow is having S<int> > be the "real" > >> > description even though it isn't instantiated that way in > the program. I wonder > >> > if it should be marked artificial... but if you do > instantiate S<int> in another > >> > TU then you don't want that. Huh. It also seems weird to > have this: > >> > DW_TAG_typedef > >> > DW_AT_name "S<A>" > >> > DW_AT_type -> S<int> > >> > but I seem to be coming around to thinking that's the most > viable way to have > >> > a single actual instantiated type, and still have the > correct names of things > >*mostly* correct; this still loses "A" as the type of the data > member. > > > >For the DW_TAG_template_type_parameter, you mean? No, it > wouldn't. > > > > (as a side note, if you do actually have a data member (or > any other mention) of > >the template parameter type, neither Clang nor GCC really get > that 'right' - > >"template<typename T> struct foo { T t; }; foo<int> f;" - in > both Clang and GCC, > >the type of the 't' member of foo<int> is a direct reference > to the "int" DIE, not > >to the DW_TAG_template_type_parameter for "T" -> int) > > Huh. And DWARF doesn't say you should point to the > template_type_parameter... > I thought it did, but no. Okay, so nothing is lost, but it feels > desirable > to me, that uses of the template parameter should cite it in the > DWARF as well. > But I guess we can leave that part of the debate for another time. > > > > >Crud. > >But I haven't come up with a way to get that back without > basically instantiating > >S<A> and S<int> separately. > > > >> > > >> Yep - it's the only way I can think of giving this > information in a way that's > >> likely to work with existing consumers. It would probably be > harmless to add > >> DW_AT_artificial to the DW_TAG_typedef, if that's any help > to any debug info > >> consumer. > > > >Hmmm no, S<A> is not the artificial name; > > > >It's not the artificial name, but it is an artificial typedef. > > If the source only says S<A>, then the entire S<int> description > is artificial, > because *that's not what the user wrote*. So both the typedef > and the class type > are artificial. Gah. Let's forget artificial here. > > > > >some debuggers treat DW_AT_artificial > >as meaning "don't show this to the user." > > > >In some sense that's what I want - we never wrote the typedef > in the source > >so I wouldn't want to see it rendered in the "list of > typedefs" (or even > >probably in the list of types, maybe). > > > >But S<A> is the name we *do* want to > >show to the user. > > > >Maybe. Sometimes. But there could be many such aliases for the > type. (& many > >more that were never written in the source code, but are still > valid in the > >source language (every other typedef of int, every other way > to name the int > >type (decltype, etc))) > > But you *lose* cases where the typedef is the *same* > *everywhere*. And in > many cases that typedef is a valuable thing, not the trivial > rename we've > been bandying about. This is a more real example: > > typedef int int4 __attribute__((ext_vector_type(4))); > template<typename T> struct TypeTraits {}; > template<> > struct TypeTraits<int4> { > static unsigned MysteryNumber; > }; > unsigned TypeTraits<int4>::MysteryNumber = 3U; > > Displaying "TypeTraits<int __attribute__((ext_vector_type(4)))>" > is much > worse than "TypeTraits<int4>" (and not just because it's shorter). > More to the point, having the debugger *complain* when the user > says > something like "ptype TypeTraits<int4>" is a problem. > > Reducing debug-info size is a worthy goal, but don't degrade the > debugging > experience to get there. > > I'm not sure which part of what I've said seemed like a > suggestion to degrade the debugging experience to minimize debug > info size (the proposition that we should use a typedef or other > alias on top of the canonical type? It wouldn't cause "ptype > TypeTraits<int4>" to complain - indeed for GDB ptyping a typedef > gives /exactly/ the same output as if you ptype the underlying > type - it doesn't even mention that there's a typedef involved: > > typedef fooA foo<int>; > > (keyboard shortcuts are hard - accidentally sent before I finished) > > (gdb) ptype fooA > > type = struct foo<int> [with T = int] { > > <no data fields> > > } > > But in any case, I think what I'm saying boils down to: > > Short of changing debug info consumers, I think the only thing > we can do is DW_TAG_typedef. That'll work for existing consumers. > > Anything else will need possibly new DWARF wording, or at least > an agreement between a variety of debug info consumers and > producers that some new cliche/use of existing DWARF be used to > describe these situations. > > I could be wrong - if someone wants to try prototyping the > DW_TAG_structure_type proposal Fred had and see if existing > debuggers work with that, sure. > > I'm not opposed to someone coming up with a standardizable more > descriptive form than DW_TAG_typedef, but that conversation > probably needs to happen with the DWARF Committee more than the > LLVM community. > > - David > > --paulr > > > > > > > >> That said, I'm not opposed to proposing something to > DWARF to define some more > >> 'proper' way to describe this. > > > >Yah. I've been thinking about the DW_AT_specification > idea too, which would be > >something like this: > > DW_TAG_class_type > > DW_AT_name "S<A>" > > DW_AT_specification -> S<int> > > > > DW_TAG_template_type_parameter > > DW_AT_name "T" > > DW_AT_type -> A > > > >The problem with this is you don't know where T is > used in the template, so > >you *still* don't know when to use A as the type of > "field". Also it's kind > >of an abuse of DW_AT_specification. If we can't get A > as the type of "field" > >then the typedef is more straightforward and > understandable. > > > >It's still a lot of DWARF to emit for every way the > user has named the template > >& I'm not sure how much value it provides - are there > use cases you have in mind > >that would benefit from the increased fidelity of > knowing which template argument > >corresponds to the way the user wrote the type. > > > > (& what would we emit if the user named the type in > some other more exotic way: > >int func(); template<typename T> struct S { }; ... > S<decltype(func())> s; ) > > > > > >Maybe I'll pop a note to the DWARF committee for a > broader set of opinions. > > > >> > >> One other open question is then, when, if ever, to > reference the DW_TAG_typedef > >> rather than the underlying type? Do we just > reference it whenever the user > >> writes using that name? > >> > >> void f(S<A>); > >> ... > >> void f(S<B>) { ... } > >> > >> etc... (this would be just as possible/we could > maybe treat it the same as if > >> the user wrote "void f(A); ... void f(B) { ... }") > > > >That's what I would do, and I think is more conformant > to the DWARF spec. > >--paulr > > > >> > >> > (because DWARF is all about the name "as it > appears in the source program.") > >> > > >> > > (the debugger wouldn't know these are actually > the same type so wouldn't > >> > > allow function calls, etc). > >> > > > >> > > - David > >> > > > >> > > > > >> > > > > >> > > > > Jim > >> > > > > > >> > > >> On Sep 8, 2014, at 12:38 PM, Frédéric Riss > > <fr...@apple.com <mailto:fr...@apple.com>> wrote: > >> > > >> > >> > > >> > >> > > >>> On 08 Sep 2014, at 19:31, Greg Clayton > > <gclay...@apple.com <mailto:gclay...@apple.com>> wrote: > >> > > >>> > >> > > >>> This means you will see "S<A>" as the type > for your variables in the > >> > > debugger when you view variables or children of > structs/unions/classes. I > >> > > think this is not what the user would want to > see. I would rather see > >> > > "S<int>" as the type for my variable than see > "S<A>”. > >> > > >> > >> > > >> I find it more accurate for the debugger to > report what has actually > >> > > been put in the code. Moreover when a typedef is > used, it’s usually to > >> > > make things more readable not to hide > information, thus I guess it would > >> > > usually be as informative while being more > compact. The debugger needs to > >> > > have a way to describe the real type behind the > abbreviated name though, > >> > > we must not have less information compared to > what we have today. > >> > > >> > >> > > >> Another point: this allows the debugger to > know what S<A> actually is. > >> > > Without it, the debugger only knows the > canonical type. This means that > >> > > currently you can’t copy/paste a piece of code > that references that kind > >> > > of template names and have it parse correctly. I > /think/ that having this > >> > > information in the debug info will allow more of > this to work. > >> > > >> > >> > > >> But we can agree to disagree :-) It would be > great to have more people > >> > > chime and give their opinion. > >> > > >> > >> > > >> Fred > >> > > >> > >> > > >>>> On Sep 5, 2014, at 4:00 PM, Adrian Prantl > > <apra...@apple.com <mailto:apra...@apple.com>> wrote: > >> > > >>>> > >> > > >>>> > >> > > >>>>> On Sep 5, 2014, at 3:49 PM, Eric > Christopher <echri...@gmail.com <mailto:echri...@gmail.com > >> > >> > > wrote: > >> > > >>>>> > >> > > >>>>> > >> > > >>>>> > >> > > >>>>> > >> > > >>>>> On Fri, Sep 5, 2014 at 3:43 PM, Duncan P. > N. Exon Smith > >> > > <dexonsm...@apple.com > <mailto:dexonsm...@apple.com>> wrote: > >> > > >>>>> > >> > > >>>>>> On 2014 Sep 5, at 16:01, Frédéric Riss > > <fr...@apple.com <mailto:fr...@apple.com>> wrote: > >> > > >>>>>> > >> > > >>>>>> I couldn’t even find a subject expressing > exactly what this patch > >> > > is about… First of all, it’s meant to start a > discussion, and I’m not > >> > > proposing it for inclusion right now. > >> > > >>>>>> > >> > > >>>>>> The issue I’m trying to address is that > template types are always > >> > > canonicalized when emitted in the debug > information (this is the desugar() > >> > > call in UnwrapTypeForDebugInformation). > >> > > >>>>>> > >> > > >>>>>> This means that if the developer writes: > >> > > >>>>>> > >> > > >>>>>> typedef int A; > >> > > >>>>>> template <typename T> > >> > > >>>>>> struct S {}; > >> > > >>>>>> > >> > > >>>>>> S<A> var; > >> > > >>>>>> > >> > > >>>>>> The variable var will have type S<int> > and not S<A>. In this simple > >> > > example, it’s not that much of an issue, but for > heavily templated code, > >> > > the full expansion might be really different > from the original > >> > > declaration. > >> > > >>>>>> > >> > > >>>>>> The attached patch makes us emit an > intermediate typedef for the > >> > > variable’s type: > >> > > >>>>>> > >> > > >>>>>> 0x0000002a: DW_TAG_variable [2] > >> > > >>>>>> DW_AT_name [DW_FORM_strp] ( > >> > > .debug_str[0x00000032] = “var") > >> > > >>>>>> DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => > >> > > {0x00000040}) > >> > > >>>>>> DW_AT_external [DW_FORM_flag] (0x01) > >> > > >>>>>> DW_AT_decl_file [DW_FORM_data1] (0x01) > >> > > >>>>>> DW_AT_decl_line [DW_FORM_data1] (8) > >> > > >>>>>> DW_AT_location [DW_FORM_block1] (<0x09> > 03 70 6c 00 00 > >> > > 00 00 00 00 ) > >> > > >>>>>> > >> > > >>>>>> 0x00000040: DW_TAG_typedef [3] > >> > > >>>>>> DW_AT_type [DW_FORM_ref4] (cu + 0x004b => > >> > > {0x0000004b}) > >> > > >>>>>> DW_AT_name [DW_FORM_strp] ( > >> > >.debug_str[0x00000035] = “S<A>") > >> > > >>>>>> DW_AT_decl_file [DW_FORM_data1] (0x01) > >> > > >>>>>> DW_AT_decl_line [DW_FORM_data1] (6) > >> > > >>>>>> > >> > > >>>>>> 0x0000004b: DW_TAG_structure_type [4] * > >> > > >>>>>> DW_AT_name [DW_FORM_strp] ( > >> > >.debug_str[0x0000003e] = “S<int>") > >> > > >>>>>> DW_AT_byte_size [DW_FORM_data1] (0x01) > >> > > >>>>>> DW_AT_decl_file [DW_FORM_data1] (0x01) > >> > > >>>>>> DW_AT_decl_line [DW_FORM_data1] (6) > >> > > >>>>>> > >> > > >>>>>> > >> > > >>>>>> Which basically is what I want, although > I don’t like that it > >> > > introduces a typedef where there is none in the > code. I’d prefer that to > >> > > be: > >> > > >>>>>> > >> > > >>>>>> DW_TAG_variable > >> > > >>>>>> DW_AT_type: -> DW_TAG_structure_type > >> > > >>>>>> DW_AT_name: S<A> > >> > > >>>>>> DW_AT_specification: -> > DW_TAG_structure_type > >> > > >>>>>> DW_AT_name: S<int> > >> > > >>>>>> … > >> > > >>>>>> > >> > > >>>>>> The patch also has the nice property of > omitting the defaulted > >> > > template arguments in the first level typedef. > For example you get > >> > > vector<A> instead of vector<int, > std::__1::allocator<int> >. > >> > > >>>>> > >> > > >>>>> If you specify `vector<int>` in C++ do you > get that instead of > >> > > >>>>> `vector<int, std::__1::allocator<int>>`? > >> > > >>>>> > >> > > >>>>> Yeah, I mentioned this as possibly causing > problems with debuggers > >> > > or other consumers, but I don't have any proof > past "ooooo scary!”. > >> > > >>>> > >> > > >>>> Well, [+lldb-dev], could this confuse > debuggers? :-) > >> > > >>>> > >> > > >>>> -- adrian > >> > > >>>>> > >> > > >>>>> That said, I like the idea personally :) > >> > > >>>>> > >> > > >>>>> -eric > >> > > >>>>> > >> > > >>>>> > >> > > >>>>>> Now there is one thing I really don’t > like about the patch. In > >> > > order not to emit typedefs for types that don’t > need it, I use string > >> > > comparison between the desugared and the > original type. I haven’t > >> > > quantified anything, but doing the construction > of the type name for every > >> > > template type and then comparing it to decide to > use it or not seems like > >> > > a big waste. > >> > > >>>>> > >> > > >>>>> Maybe someone on cfe-dev knows a better way. > >> > > >>>>> > >> > > >>>>>> > >> > > >>>>>> Thoughts? > >> > > >>>>>> > >> > > >>>>>> <template-arg-typedefs.diff> > >> > > >>>>>> > >> > > >>>>>> Fred > >> > > >>>>>> > >> > > >>>>>> > >> > > >>>>>> > >> > > >>>>>> > >> > > >>>>>> > >> > > >>>>>> > _______________________________________________ > >> > > >>>>>> llvm-commits mailing list > >> > > >>>>>> llvm-comm...@cs.uiuc.edu > > <mailto:llvm-comm...@cs.uiuc.edu> > >> > > >>>>>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > >> > > >>>>> > >> > > >>>>> > >> > > >>>> > >> > > >>>> > _______________________________________________ > >> > > >>>> lldb-dev mailing list > >> > > >>>> lldb-dev@cs.uiuc.edu > <mailto:lldb-dev@cs.uiuc.edu> > >> > > >>>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >> > > >>> > >> > > >> > >> > > >> > >> > > >> _______________________________________________ > >> > > >> lldb-dev mailing list > >> > > >> lldb-dev@cs.uiuc.edu > <mailto:lldb-dev@cs.uiuc.edu> > >> > > >> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >> > > > > >> > > > >> > > > >> > > _______________________________________________ > >> > > llvm-commits mailing list > >> > > llvm-comm...@cs.uiuc.edu > <mailto:llvm-comm...@cs.uiuc.edu> > >> > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > >> > > >> > _______________________________________________ > >> > llvm-commits mailing list > >> > llvm-comm...@cs.uiuc.edu > <mailto:llvm-comm...@cs.uiuc.edu> > >> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > _______________________________________________ > llvm-commits mailing list > llvm-comm...@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > > > _______________________________________________ > llvm-commits mailing list > llvm-comm...@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > > >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
