amccarth added a comment.

In https://reviews.llvm.org/D43688#1017638, @labath wrote:

> This test deliberately compiles without `-g`, so the variable should not be 
> in the debug info.


Ah, that makes more sense than what I was thinking:  that it was trying to make 
sure the unused symbol wasn't being optimized away.

> On non-windows systems we're expected to pick up the name from the symbol 
> table. Is there such a thing on windows as well?

Given that constant is declared with visibility("hidden"), why would it end up 
in a symbol table?  Windows DLLs have tables for items explicitly exported, but 
that's contrary to asking the symbol to be hidden.

> Maybe you need to lookup the symbol as `_conflicting_symbol` ?

No, that doesn't make a difference.

> I think this could also be related to your  breakpoint location resolving 
> problem. The test explicitly calls `self.registerSharedLibrariesWithTarget` 
> which explicitly adds the shared library to the list of target modules, so 
> (assuming registerSharedLibrariesWithTarget works on windows) this test 
> should not depend on automatic library searching in lldb. I'm guessing you 
> have some problems looking things up when debug info is absent.

No, registering the libraries doesn't work on Windows (as discussed in the 
other patch were we introduced the -2 magic value).  The Windows search rules 
for DLLs are quite complex -- it would be very difficult to replicate them in 
lldb.

> With all that in mind, I don't think this patch would hurt this test, but I 
> don't believe it will help you getting the test passing either, so I would 
> keep the num_expected_locations as-is (the LLDB_TEST_API thingy is obviously 
> fine).

But that would leave the test failing for a reason other than the underlying 
problem:  that we can't resolve the symbol, which probably indicates an 
incomplete implementation somewhere.  I think a test that failure that points 
to the root problem is more useful than a general 
this-doesn't-even-link-on-Windows error.


https://reviews.llvm.org/D43688



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to