<br><br><div>On Tue Dec 17 2013 at 5:29:51 PM, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Dec 17, 2013, at 4:40 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
<br>
> Let's see if I've managed to divine the use case that you're talking about here so we can attempt to refocus the discussion somewhat:<br>
><br>
> a) You ship headers and libraries to customers.<br>
> b) You will not or, at least, have not shipped debug info to those customers.<br>
> c) For this case in particular:<br>
>    1) The headers contain a polymorphic base class<br>
>    2) Customers derive from this polymorphic base class<br>
>    3) Linking still works since the customer has the library but not the debug info for the base class where the key function was emitted.<br>
><br>
> Is this correct?<br>
<br>
yes, this is what is got our kernel group filing bugs.<br>
<br>
For any LLDB debugging, I will always want full base class definitions.<br></blockquote><div><br></div><div>You will always want full base class definitions where? With the fully linked binary or elsewhere? Do you want to require them all in the same .o file as any derived class definition?</div>
<div><br></div><div>I.e. if you compile your entire program with debug info then you'll have a full base class definition somewhere in the debug info. If you can't cope with this then it's a bug in lldb that you can't process correct debug information.</div>
<div><br></div><div>-eric</div>