<div dir="ltr">(ping, in case anyone has some thoughts here)</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 15, 2017 at 11:00 AM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Feb 14, 2017 at 7:32 PM Robinson, Paul <<a href="mailto:paul.robinson@sony.com" class="gmail_msg" target="_blank">paul.robinson@sony.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David, this is pretty dense, I've asked for some clarifications<br class="gmail_msg">
as well as making a few other comments.<br class="gmail_msg">
<br class="gmail_msg">
Broadly speaking it seems like there are a couple of problems:<br class="gmail_msg">
- picking what should be put into a type unit relies on poor heuristics;<br class="gmail_msg">
- can have an excessive volume of stuff dragged along with the type that<br class="gmail_msg">
  you actually *want* to put into the type unit.<br class="gmail_msg">
If there was another one in addition, please reiterate it.<br class="gmail_msg">
<br class="gmail_msg">
Relying on "has a mangled name" as a proxy for "can go into a type unit"<br class="gmail_msg">
(which is what it sounded like, not sure I understood that part correctly)<br class="gmail_msg">
seems like not a great fit.</blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">It's a pretty good fit. All public types have mangled names. All types with mangled names are public. So it's pretty much the set of things that can be present in more than one translation unit and represent the same entity (that's why it has a mangled name - so it can be consistently identified across translation units)</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  In the original type-unit discussions, I<br class="gmail_msg">
remember Cary talking about using the signature as the group key; is that<br class="gmail_msg">
infeasible for some reason?</blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Ah, practical details - Clang doesn't produce a type unit signature the way the DWARF spec describes (I believe the spec is overly prescriptive here - how the hash is computed is/should be an implementation detail, I think), instead it hashes the mangled name of the type and uses that as the signature and as the group key.<br class="gmail_msg"><br class="gmail_msg">I suppose this means that the mangling between two different compilers could accidentally/erroneously collide given they're using different hashing schemes. Don't think we've seen a problem with that in practice so far. It does make sure we hash more equivalent things and requires less work. (actually one of the cases where LLVM produces different DWARF for the same type but still provides a matching hash is this case we're talking about - if there's type A with a pointer to B and in one translation unit B is defined and the other B is declared then the type unit for A looks different (in the first it has a DW_AT_signature to reference B, in the second it has a DW_AT_name instead))</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  It would keep unnamed enums from being<br class="gmail_msg">
excluded from type units,</blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Here's some more details about the unnamed enum situation.<br class="gmail_msg"><br class="gmail_msg">Unnamed enums are actually file-local names. Technically the following would produce an ODR violation in C++, for example:<br class="gmail_msg"><br class="gmail_msg">  enum { MY_CONST = 3; }<br class="gmail_msg">  inline void f() {<br class="gmail_msg">    (void)MY_CONST;<br class="gmail_msg">  }</div><div class="gmail_msg"><br class="gmail_msg">(the ODR requires that every definition of 'f' consist of the same sequence of tokens, and that the names referenced from it find the same entities - and since MY_CONST in one translation unit is a different entity from MY_CONST in some other translation unit - two definitions of 'f' wouldn't meet the ODR requirement)<br class="gmail_msg"><br class="gmail_msg">This would be more visible, in say a template instantiation:<br class="gmail_msg"><br class="gmail_msg">  template<typename T> f(T) { }<br class="gmail_msg">  ... f(MY_CONST);<br class="gmail_msg"><br class="gmail_msg">produces an instantiation of 'f' with internal linkage (because it has an internal linkage type as a template type parameter).</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">as well as being considerably shorter than most<br class="gmail_msg">
mangled names (saving even more space!).<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">*nod* no worries about size - the mangled names are in the IR, but they're hashed for the DWARF output, so it doesn't make a difference to size.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(Nothing from inside an anonymous namespace should go into a type unit.<br class="gmail_msg">
Type units are for enabling de-duplication, and anonymous namespaces by<br class="gmail_msg">
definition do not contain anything sharable across CUs.  It wasn't clear<br class="gmail_msg">
whether you thought the current state of things there was good or bad.)<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Right - but by that same logic, anonymous enums shouldn't go in type units either, because they have internal/no linkage.<br class="gmail_msg"><br class="gmail_msg">This is a bit of a bug in the C++ spec, probably - Clang's C++ Modules support works around this by mangling the first member of the enum, so I hear. So we might do the same thing and/or hope someone fixes the C++ spec, then this would all fall out naturally.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And the part about throwing away work late, after discovering something<br class="gmail_msg">
relies on an address...  That one would depend on how often you had to<br class="gmail_msg">
throw away work in practice.  I could imagine doing some kind of<br class="gmail_msg">
isOKForTypeUnit() predicate, traversing the type tree before we actually<br class="gmail_msg">
emit anything, but whether that's profitable is a performance question<br class="gmail_msg">
that requires experimental evidence.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Sure enough.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As for reducing the volume of stuff in the type unit, I think I need<br class="gmail_msg">
the clarifications I've asked for below in order to get a handle on<br class="gmail_msg">
what you are thinking there.<br class="gmail_msg">
<br class="gmail_msg">
I am interested in having type units be useful and effective, so this<br class="gmail_msg">
is something I am happy to devote some time to.  See inline comments<br class="gmail_msg">
and looking forward to figuring all this stuff out.<br class="gmail_msg">
--paulr<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> From: David Blaikie [mailto:<a href="mailto:dblaikie@gmail.com" class="gmail_msg" target="_blank">dblaikie@gmail.com</a>]<br class="gmail_msg">
> Sent: Friday, February 03, 2017 7:16 PM<br class="gmail_msg">
> To: llvm-dev; Robinson, Paul; Eric Christopher<br class="gmail_msg">
> Cc: Adrian Prantl<br class="gmail_msg">
> Subject: DWARF: Should type units be referenced by signature or declaration?<br class="gmail_msg">
><br class="gmail_msg">
> Bunch of initially unrelated context:<br class="gmail_msg">
><br class="gmail_msg">
> * type units can be referenced in a variety of ways:<br class="gmail_msg">
>  * DW_FORM_ref_sig8 on any attribute needing to reference the type<br class="gmail_msg">
>  * DW_AT_signature on a declaration of the type<br class="gmail_msg">
>  * extra wrinkle: the declaration can be nested into the appropriate namespace and given a name, or not<br class="gmail_msg">
<br class="gmail_msg">
Sorry, didn't follow the wrinkle.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">OK - so here's an example of the 3 ways I've seen GCC produce a reference to a type unit:<br class="gmail_msg"><br class="gmail_msg"><ol class="gmail_msg"><li class="gmail_msg">If a type is referenced exactly once from this (type or compile)unit:<br class="gmail_msg"><font face="monospace" class="gmail_msg"><b class="gmail_msg">AT_type FORM_ref_sig8</b></font><br class="gmail_msg"></li><li class="gmail_msg">If the type is referenced more than once (the choice of representation is cost-neutral at this point (two FORM_ref_sig8 or two FORM_ref4 and a structure_type with FORM_ref_sig8) 2 * 8 == 8 + 2 * 4, which doesn't account for the extra abbrev reference for the TAG_structure_type, but's probably close enough for government work)<br class="gmail_msg"><font face="monospace" class="gmail_msg"><b class="gmail_msg">AT_type FORM_ref4 -><br class="gmail_msg">TAG_structure_type // omits namespaces<br class="gmail_msg">  AT_signature FORM_ref_sig8</b></font></li><li class="gmail_msg">Only used from a CU, when the type has member functions (with definitions in this CU) or other entities (like nested types) that need to be referenced in the CU.<br class="gmail_msg"><b class="gmail_msg">AT_type FORM_ref4 -><br class="gmail_msg">TAG_namespace // includes all relevant namespaces<br class="gmail_msg">  TAG_structure_type<br class="gmail_msg">    AT_name<br class="gmail_msg">    AT_declaration<br class="gmail_msg">    AT_signature FORM_ref_sig8<br class="gmail_msg"></b>    <b class="gmail_msg">DW_TAG_subprogram, etc...</b></li></ol></div><div class="gmail_msg"> <br class="gmail_msg">Here's an example source file you can compile with GCC and Clang to see how this all looks:<br class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><font face="monospace" class="gmail_msg">namespace ns {</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">struct single_reference {</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">};</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">struct multiple_reference {</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">  single_reference s;</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">};</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">struct full_reference {</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">  void f(single_reference s, multiple_reference m1, multiple_reference m2) {</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">  }</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">};</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">}</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">using namespace ns;</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">void (full_reference::* x)(single_reference, multiple_reference, multiple_reference) = &full_reference::f;</font></div></div><div class="gmail_msg"><br class="gmail_msg">One extra wrinkle I just spotted - GCC doesn't produce DIEs for the parameters in the declaration of a member function in a type unit reference (in case (3) above, the DW_TAG_subprogram in the declaration of the type ("full_reference" in the worked example) - that could save us a few bytes)<br class="gmail_msg"><br class="gmail_msg">GCC never uses (3) to reference a type from another type unit - Clang could/should probably do that... <br class="gmail_msg"><br class="gmail_msg">Clang always use (3) but skips the DW_AT_name. I haven't tested extensively to see which things work/don't work with GDB for example, but this seemed the most descriptive option and Clang's debug info was still so much smaller than GCC's it wasn't a real priority for me to make it even better at the time.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
>  * LLVM always does the "most expressive"/expensive thing: a full declaration (though without a name, but with the DW_AT_signature) in the correct namespace.<br class="gmail_msg">
<br class="gmail_msg">
If you could unpack this a little more, that would help.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Hopefully the above example and details help there. If it's not clear in any way, I can try to explain differently/better.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
>  * GCC is more selective/nuanced in its choice fo representation, depending on context.<br class="gmail_msg">
> * Types may be emitted unreferenced (LLVM's retained types list, which will be more strongly leveraged for C++ modules + debug info in the near future) into type units, or directly into the CU<br class="gmail_msg">
> * Types that reference addresses (pointer non-type template parameters, for example) may not be in type units when using Fission (they have no way to reference the address pool)<br class="gmail_msg">
>  * The LLVM implementation of this isn't terribly efficient - a flag is lowered on the address pool, if at any point an address is required the flag is raised and all subsequent type creation is skipped, once control returns to the code responsible for creating the type unit, the flag is examined and if it is up - all the work is thrown out, and the type is then created in the CU.<br class="gmail_msg">
> * Type units have some overhead (2x on GCC, 1.5x on Clang (as measured by the difference between the reduction in debug_info size compared to the increase in debug_type size) when I measured a while ago)<br class="gmail_msg">
> * LLVM uses the mangled name of the type as the deduplication key for type units<br class="gmail_msg">
>  * because of this, LLVM doesn't produce type units for non-public types (eg: classes in anonymous namespaces - or unnamed enums... (this latter one produces some wrinkles))<br class="gmail_msg">
><br class="gmail_msg">
> Motivation:<br class="gmail_msg">
> * Types that are only emitted once across the program (eg: attached to a template explicit instantiation definition or emitted due to a strong vtable) shouldn't be put into type units so they don't pay the overhead.<br class="gmail_msg">
><br class="gmail_msg">
> Issues:<br class="gmail_msg">
> * This leads to type unit types referencing non-type unit types - what DWARF should be used for that? a type declaration in the type unit? I think: yes<br class="gmail_msg">
<br class="gmail_msg">
A type unit has "a single complete type definition."  If the type's definition can be considered complete while making use of other types that are merely declarations, seems fine to me.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">I'm not sure I follow the implication there - are there cases you've got in mind where a type might not be "considered complete" when referencing other types by declaration?<br class="gmail_msg"><br class="gmail_msg">At least for Clang - it's trivial to cause any situation to have a type declaration where it otherwise has a type definition: by giving the type a key function/strong vtable and defining the key function/vtable elsewhere.<br class="gmail_msg"><br class="gmail_msg">eg: <br class="gmail_msg"><br class="gmail_msg">struct foo {</div><div class="gmail_msg">  virtual void f();</div><div class="gmail_msg">};</div><div class="gmail_msg">struct bar {<br class="gmail_msg">  foo f;<br class="gmail_msg">};<br class="gmail_msg"><br class="gmail_msg">In some sense 'bar' looks like it must have a definition of 'foo' available (the code wouldn't compile if 'foo' were only a declaration) but with or without type units, both Clang and GCC produce DWARF containing only a declaration of 'foo' and a dfinition of 'bar'.<br class="gmail_msg"><br class="gmail_msg">This can be done for any type referenced from/used by 'bar'. So in the sense that all these possible definitions of 'bar' are 'complete', then it's true that a type unit for 'bar' containing only declarations of other types would be complete.<br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> * This issue sort of already comes up & is punted if the ODR is violated. If an external type references an internal type, the internal type is emitted into the type unit (& into any other TU/CU that uses it - much duplication)<br class="gmail_msg">
<br class="gmail_msg">
Yep<br class="gmail_msg">
<br class="gmail_msg">
> * If type units may reference other types by declaration (already true - a type may only be available as a declaration) - why not referencing all types by declaration?<br class="gmail_msg">
<br class="gmail_msg">
You can probably figure out how to replace some referenced definitions by declarations, when constructing the type unit. Can't be done for everything (there's no way to turn a base_type into a declaration) </blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Right - this only applies to user defined types, which are the only types that Clang (& I'm pretty sure GCC) put in type units. Base types and the like don't get separated into their own type unit - the overhead's probably not worth it, generally. I suppose in theory if you had a particularly complicated composite but not-user-defined type (like a complex pointer type - maybe a function pointer type with lots of interesting parameters, layers of indirection, etc) could be nice to have in a type unit - but I'm not sure the hashing code/type unit spec allows for this since the type doesn't have a name.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and for cases where you can substitute, the question is whether the consumer can do anything useful with the breadcrumbs you have left behind.</blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Given that for any case given, one can construct the same type unit that would look identical to the proposed (declarified) output by vtabling all the referenced types - it seems in that sense, any consumer should be OK with a type unit like this, itself.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>  * Is there substantial benefit to the debugger to not have to do name resolution, but rather to match types by signature directly?<br class="gmail_msg">
<br class="gmail_msg">
Once I understand the question, I can ask our debugger people. :-)<br class="gmail_msg">
<br class="gmail_msg">
> * Since type units can be emitted without an reference to them from the CU, a consumer can't rely on reachability of the type unit reference graph so this should be only a performance concern, not a correctness one.<br class="gmail_msg">
<br class="gmail_msg">
Rely on reachability of the type unit reference graph?  Feels like there's a use-case you have in mind that I am not reconstructing.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">I'm not working on/haven't seen any consumer rely on this, but I could imagine things like the following:<br class="gmail_msg"><br class="gmail_msg">Fission + DWP + type units + GDB Index (made from pubnames/pubtypes)<br class="gmail_msg"><br class="gmail_msg">The GDB index/pubtypes entry for types when using type units from GCC and Clang uses the DW_TAG_compile_unit as the TAG offset to reference for types in a type unit (since the pubtypes doesn't haev any way of referencing type units, only of referencing offsets within the CU).<br class="gmail_msg"><br class="gmail_msg">So, if GDB (or any other pubtypes-motivated DWARF consumer) wanted to find a reference to type "foo", looks it up in the index, finds "it's somewhere in the bar CU", so it loads the CU and if the type unit were emitted unreferenced (modular codegen, say - where we might pin a definition into the object file even though there's no code referencing the type - also template explicit instantiation definitions is a place we do this already) there what would it do? Maybe it is referenced from the CU - even then, GDB has to search through every type reference (except the (3) - if 'foo' was referenced with a (3), GDB could find the name and then not load any other types, follow the signature and load that one type) and every type they reference, etc.<br class="gmail_msg"><br class="gmail_msg">What's the alternative? Load every type in the DWP/in the whole program to see if it's a type called 'foo'?<br class="gmail_msg"><br class="gmail_msg">Without DWP it's at least constrained - the pubtypes in this DWO file say "foo" is somewhere here so the consumer can search all the type units in the DWO - not quick, but at least it's not "ever type in the program". Once all the types are thrown together into the DWP that constrained environment is lost.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> * If declarations are used selectively or pervasively, this would help address pool issue too: even if a type uses an address, it would go in the CU but types referencing that type could still remain in a TU.<br class="gmail_msg">
><br class="gmail_msg">
> So, barring anything else, I'm sort of inclined to just make all references to types in type units plain declarations (oh, also, DW_AT_declaration + DW_AT_name is smaller than DW_AT_declaration + DW_AT_signature (4 bytes instead of 8)). Simpler implementation, possible performance loss for the debugger (lacking the shortcut to find a type by signature instead of name lookup) and should tidy up a bunch of oddities as well as paving the way for improvements around types that don't need type units.<br class="gmail_msg">
><br class="gmail_msg">
> Any thoughts/suggestions/(dis)recommendations?<br class="gmail_msg">
><br class="gmail_msg">
> - Dave<br class="gmail_msg">
><br class="gmail_msg">
> Bonus question: it's possible that the type-with-addresses issue could be checked up front (the DICompositeType could be examined for all its template parameters to see if any involve addresses of globals) but that seems a little brittle (other uses of addresses could crop up - like some IR producer could create a member function declaration in the member list for a member function template instantiation (Clang doesn't do this - member function template instantiations refer to the class as their scope, but do not appear in the member list - this keeps types uniform across translation units), for example) but could simplify the implementation in terms of not needing to do a bunch of (now much less if all the intermediate types don't need to be thrown out too) work that may be thrown out. Worth it? Other ideas?<br class="gmail_msg">
> (also: GCC doesn't implement this rule, so its Fission+type units should have trouble resolving addresses & may end up referring to the wrong address pool, etc)<br class="gmail_msg">
</blockquote></div></div></blockquote></div>