[Lldb-commits] [PATCH] D36347: New lldb python module for adding diagnostic breakpoints

hintonda updated this revision to Diff 120360. hintonda added a comment. - Add diagtool option used to set arbitrary diagtool path. https://reviews.llvm.org/D36347 Files: utils/clangdiag.py Index: utils/clangdiag.py === ---

[Lldb-commits] Buildbot numbers for the last week of 10/15/2017 - 10/21/2017

Hello everyone, Below are some buildbot numbers for the last week of 10/15/2017 - 10/21/2017. Please see the same data in attached csv files: The longest time each builder was red during the week; "Status change ratio" by active builder (percent of builds that changed the builder status from

[Lldb-commits] Buildbot numbers for the week of 10/8/2017 - 10/14/2017

Hello everyone, Below are some buildbot numbers for the week of 10/8/2017 - 10/14/2017. Please see the same data in attached csv files: The longest time each builder was red during the week; "Status change ratio" by active builder (percent of builds that changed the builder status from greed to

[Lldb-commits] [PATCH] D39315: Correct the start address for exported windows functions in arm

sas created this revision. Herald added subscribers: kristof.beyls, aemerson. This assumes that the environment is always Thumb Change by Walter Erquinigo https://reviews.llvm.org/D39315 Files: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp Index:

[Lldb-commits] [PATCH] D39314: Implement basic DidAttach and DidLaunch for DynamicLoaderWindowsDYLD

sas created this revision. This commit implements basic DidAttach and DidLaunch for the windows DynamicLoader plugin which allow us to load shared libraries from the inferior. This is an improved version of https://reviews.llvm.org/D12245 and should work much better.

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

[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

[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

[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

[Lldb-commits] [PATCH] D36347: New lldb python module for adding diagnostic breakpoints

jingham added a comment. Ack, my bad. I should remember not to rely on my memory... I thought at one point I was going to do it that way, then got annoyed I'd have to have "BreakpointDisableByName" etc... So apparently I made: SBTarget.FindBreakpointByName that takes a name & an

[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] [lldb] r316629 - Makefile.rules: move CFLAGS_EXTRAS to the end of compile line

Author: labath Date: Wed Oct 25 16:56:17 2017 New Revision: 316629 URL: http://llvm.org/viewvc/llvm-project?rev=316629=rev Log: Makefile.rules: move CFLAGS_EXTRAS to the end of compile line This makes sure that any options specified there override generic compiler options. This fixes

[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] D36347: New lldb python module for adding diagnostic breakpoints

hintonda added inline comments. Comment at: utils/clangdiag.py:83 +# Remove all diag breakpoints. +bkpts = lldb.SBBreakpointList(target) +target.FindBreakpointsByName("clang::Diagnostic", bkpts) Can't use iterator because it gets invalidated and not

[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`.

[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

[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:

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

[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

[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

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

[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

[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] [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

[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

[Lldb-commits] [PATCH] D36347: New lldb python module for adding diagnostic breakpoints

jingham added a comment. Note, BTW, Enrico also added a form of the command add that allows you to use a Python class to wrap the callable. That was in early 2015 so it's probably safe to use as well by now. That's even more convenient, and obviates the need for globals at all. One instance

[Lldb-commits] [PATCH] D36347: New lldb python module for adding diagnostic breakpoints

clayborg added inline comments. Comment at: utils/clangdiag.py:62 + +def enable(debugger, args): +# Always disable existing breakpoints Pass exe_ctx or target into this instead of the debugger (see Jim's comment on execution contexts below.

[Lldb-commits] [PATCH] D36347: New lldb python module for adding diagnostic breakpoints

jingham added a comment. Yes definitely use names for your breakpoints. It makes them easier to handle. Note starting a month or two ago you can set names to not get deleted except by an explicit gesture. That hasn't shown up in releases yet, but once you can rely on its being there, you

[Lldb-commits] [PATCH] D36347: New lldb python module for adding diagnostic breakpoints

jingham requested changes to this revision. jingham added a comment. This revision now requires changes to proceed. Use the form of the command that gets an SBExecutionContext, then you can avoid having to cache the target at all. Comment at: utils/clangdiag.py:98-100 +def

[Lldb-commits] [PATCH] D36347: New lldb python module for adding diagnostic breakpoints

hintonda added a comment. Thanks for the quick feedback. I'll make all you suggested changes, but need to think a little more about `diagtool`. Comment at: utils/clangdiag.py:75-78 +diagtool = os.path.join(exe.GetDirectory(), 'diagtool') +if not

[Lldb-commits] [PATCH] D39283: [lldb-dev] Update LLDB test cases for 'inlineStepping'

tberghammer added a comment. Hi Carlos, Sorry for not responding to your related e-mails lately. I am still not convinced that tis is the right way forward as you are changing the expected behavior from LLDB side to make it work with the new debug info emitted by clang but I think the current

[Lldb-commits] [PATCH] D36347: New lldb python module for adding diagnostic breakpoints

clayborg added a comment. Looks good. A little bit of cleanup. Let me know what you think of the comments. Comment at: utils/clangdiag.py:17 +import os +from subprocess import check_output as qx; + I would rather just do: ``` import subprocess ``` Then later

[Lldb-commits] [PATCH] D31172: Move stop info override callback code from ArchSpec into Process

This revision was automatically updated to reflect the committed changes. Closed by commit rL316609: Move StopInfoOverride callback to the new architecture plugin (authored by labath). Changed prior to commit: https://reviews.llvm.org/D31172?vs=106600=120309#toc Repository: rL LLVM

[Lldb-commits] [lldb] r316609 - Move StopInfoOverride callback to the new architecture plugin

Author: labath Date: Wed Oct 25 14:05:31 2017 New Revision: 316609 URL: http://llvm.org/viewvc/llvm-project?rev=316609=rev Log: Move StopInfoOverride callback to the new architecture plugin This creates a new Architecture plugin and moves the stop info override callback to this place. The

[Lldb-commits] [PATCH] D36347: Add new script to launch lldb and set breakpoints for diagnostics all diagnostics seen.

hintonda updated this revision to Diff 120308. hintonda added a comment. Reimplement at a python module. https://reviews.llvm.org/D36347 Files: utils/clangdiag.py Index: utils/clangdiag.py === --- /dev/null +++

[Lldb-commits] [PATCH] D35556: Add data formatter for libc++'s forward_list

jingham requested changes to this revision. jingham added a comment. This revision now requires changes to proceed. It looks like the behavior of the two derived list classes here are only partially factored out. See the individual comments but it looks like there is a lot more that could be

[Lldb-commits] [PATCH] D39283: [lldb-dev] Update LLDB test cases for 'inlineStepping'

CarlosAlbertoEnciso created this revision. Herald added a subscriber: eraman. A patch to correct the compiler issue, where instructions associated to the function prolog are assigned line information, causing the debugger to show incorrectly the beginning of the function body, caused some tests