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
===
--- /dev
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 gre
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
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: source/Plugins/ObjectFile/PECOFF/O
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.
https://reviews.llvm.org/D
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
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/
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
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
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
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 SBBreakpoint
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
___
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 $$
Author: labath
Date: Wed Oct 25 16:56:17 2017
New Revision: 316629
URL: http://llvm.org/viewvc/llvm-project?rev=316629&view=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 TestBr
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
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 a
hintonda updated this revision to Diff 120340.
hintonda edited the summary of this revision.
hintonda added a comment.
Herald added a subscriber: ilya-biryukov.
- Addressed comments.
https://reviews.llvm.org/D36347
Files:
utils/clangdiag.py
Index: utils/clangdiag.py
=
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
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/
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
$ 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
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
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
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
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
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
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
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
__
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
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
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.
===
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 can
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 the
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 os.path.exists(diagtoo
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
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
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&id=120309#toc
Repository:
rL LLVM
https
Author: labath
Date: Wed Oct 25 14:05:31 2017
New Revision: 316609
URL: http://llvm.org/viewvc/llvm-project?rev=316609&view=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 mo
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
+++ utils/clangdiag.p
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 sh
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
in
41 matches
Mail list logo
