[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

clayborg added a comment. It would be nice if we can try and disable the redeclaration lookups from clang when in debugger mode. I can't remember if we already have such a flag in the compiler options. If we do, we should try to just disable this when in debug expression mode and see how the te

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

jingham added a comment. @rsmith: lldb does as you suggest, if it can find a name in the local context, it returns that, if it can find it in the current CU, it returns that, etc... It only returns multiple matches if it can't find a single instance along that chain. The problem with this cas

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

xiaobai abandoned this revision. xiaobai added a comment. It's clear this is not the way forward. The problem I am trying to solve should be attacked differently. Thanks everyone for your input! https://reviews.llvm.org/D39307 ___ lldb-commits mail

Re: [Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

> On Oct 26, 2017, at 9:34 AM, Zachary Turner > wrote: > > Note that $ is a valid character in a MSVC-mangled symbol name. So, I don't > think it will work for that reason alone. FWIW, I also don't like the {,,} > syntax very much, but if you read on there's a sim

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

rsmith added a comment. In https://reviews.llvm.org/D39307#907358, @xiaobai wrote: > It seems like clang shouldn't even be asking us about this in the first > place, but I don't fully understand why it's trying to do what it's trying to > do. It looks like there are two issues here: clang is

Re: [Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

Note that $ is a valid character in a MSVC-mangled symbol name. So, I don't think it will work for that reason alone. FWIW, I also don't like the {,,} syntax very much, but if you read on there's a simpler ! syntax that is pretty nice. libfoo!symbolname On Thu, Oct 26, 2017 at 9:30 AM Greg Cla

Re: [Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

> On Oct 25, 2017, at 6:05 PM, Zachary Turner wrote: > > > > On Wed, Oct 25, 2017 at 4:59 PM Jim Ingham via Phabricator > mailto:revi...@reviews.llvm.org>> wrote: > jingham added a comment. > > Note, BTW, we absolutely need some way to say "this symbol from this > library". But first of al

Re: [Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

On Wed, Oct 25, 2017 at 4:59 PM Jim Ingham via Phabricator < revi...@reviews.llvm.org> wrote: > jingham added a comment. > > Note, BTW, we absolutely need some way to say "this symbol from this > library". But first of all, if we're going to do this you need to be able > to mix & match within an

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

davide added a subscriber: rsmith. davide added a comment. Richard Smith (@rsmith) owns clang and is familiar with this. https://reviews.llvm.org/D39307 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

xiaobai added a comment. In https://reviews.llvm.org/D39307#907301, @jingham wrote: > So one of the expectations of people using the debugger is that their whole > program is available to them wherever they happen to be stopped. People get > really upset when we break that fiction. I've exper

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

xiaobai added a comment. In https://reviews.llvm.org/D39307#907302, @jingham wrote: > Note, BTW, we absolutely need some way to say "this symbol from this > library". But first of all, if we're going to do this you need to be able to > mix & match within an expression which you can't do with a

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

jingham added a comment. The problem here is that the name that started the whole query is a local variable in the code we're currently compiling. So clang doesn't need to ask us about it, and in fact since we're still in mid-compilation lldb doesn't know anything about the name we're actually

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

labath added a comment. I thought https://reviews.llvm.org/D33083 was supposed to resolve the conflicting-symbol-in-another-library issue by giving precedence to the current module. Why doesn't that apply here? https://reviews.llvm.org/D39307 ___

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

jingham added a comment. Note, BTW, we absolutely need some way to say "this symbol from this library". But first of all, if we're going to do this you need to be able to mix & match within an expression which you can't do with a flag to expr. Instead you need something like: (lldb) expr $$

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

jingham added a comment. So one of the expectations of people using the debugger is that their whole program is available to them wherever they happen to be stopped. People get really upset when we break that fiction. I've experienced this both in Radar and in person... But in this case, it

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

xiaobai added a comment. $ nm /lib64/libm.so.6 | grep " a$" 00093bb0 r a 000c6a80 r a 00093bb0 r a This is what I get, which seems to match what you said. These are definitely internal to libm. It's a similar story for the symbol `b`. https://reviews.llvm.org/D3

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

davide added a comment. Sorry, my bad, I haven't grepped properly, there are 3 internal symbols named `a` in `libm.so`. https://reviews.llvm.org/D39307 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

davide added a comment. Thanks for taking care of the test. About the libmath question. I thought libmath exported a symbol named `a` ,but I haven't checked the `readelf` output. This is what I saw for the symbols: (lldb) image lookup --address 0x777ec290 Address: libm.so.6[0x00

Re: [Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

$ nm /lib64/libm.so.6| grep " a$" 00093bb0 r a 000c6a80 r a 00093bb0 r a No, they are internal to libm only. Alex On 10/25/17, 4:15 PM, "Greg Clayton" wrote: Not hard. Just find a test that has a shared library and copy it. Modify the shared library to create a sy

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

xiaobai added a comment. In https://reviews.llvm.org/D39307#907248, @davide wrote: > Thanks, I'll try this patch tomorrow. > I know this may be a little off, but how hard is to write a test for this so > that it doesn't regress? I don't think this would be terribly difficult, and I absolutely

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

xiaobai added a comment. In https://reviews.llvm.org/D39307#907253, @jingham wrote: > If I have a library that uses some singleton class that's not exported, and > I'm debugging code in a client of my library, and the state of my library is > looking odd based on what it is returning to the cli

Re: [Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

Not hard. Just find a test that has a shared library and copy it. Modify the shared library to create a symbol named "a". Then the main executable, just run the same lambda expression and it will fail on all platforms. The current fix in the review is just for internal symbols in other shared li

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

jingham requested changes to this revision. jingham added a comment. This revision now requires changes to proceed. If I have a library that uses some singleton class that's not exported, and I'm debugging code in a client of my library, and the state of my library is looking odd based on what i

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

davide added a comment. Thanks, I'll try this patch tomorrow. I know this may be a little off, but how hard is to write a test for this so that it doesn't regress? https://reviews.llvm.org/D39307 ___ lldb-commits mailing list lldb-commits@lists.llv

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

xiaobai added a comment. In https://reviews.llvm.org/D39307#907220, @clayborg wrote: > It is a nice idea. I would still rather fix this in clang so it doesn't ask > us about a variable it already knows about. Though this might be a good > solution until we can fix it for real though. Sean or Ji

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

clayborg added a comment. It is a nice idea. I would still rather fix this in clang so it doesn't ask us about a variable it already knows about. Though this might be a good solution until we can fix it for real though. Sean or Jim? https://reviews.llvm.org/D39307 __

[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

xiaobai created this revision. With this patch I want to do the following: When searching for global data symbols, only consider non-externally visible symbols if we are in the module where they are visible. I was investigating bug 35043 (https://bugs.llvm.org/show_bug.cgi?id=35043) and found out