Author: jingham
Date: Fri Jan 29 14:21:33 2016
New Revision: 259237
URL: http://llvm.org/viewvc/llvm-project?rev=259237&view=rev
Log:
Fixed a couple of places where we were getting the module from a
section and using it w/o checking that it was valid. This can
cause crashes - usually when tearing
Author: jingham
Date: Fri Jan 29 14:09:30 2016
New Revision: 259234
URL: http://llvm.org/viewvc/llvm-project?rev=259234&view=rev
Log:
Fix this test for the the switch in default for IgnoreBreakpoints in
SBFrame.EvaluateExpression.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/s
Author: jingham
Date: Mon Feb 1 14:05:37 2016
New Revision: 259396
URL: http://llvm.org/viewvc/llvm-project?rev=259396&view=rev
Log:
Add a note on how to create an empty target and use it to attach to
processes whose executables you don't know up front.
Modified:
lldb/trunk/scripts/interface
Author: jingham
Date: Mon Feb 1 18:21:39 2016
New Revision: 259443
URL: http://llvm.org/viewvc/llvm-project?rev=259443&view=rev
Log:
We try to avoid static objects. These are on the error path for unsupported
features
in the socket, so just returning freshly constructed objects is fine.
Modifi
jingham added a comment.
Yes, it has always been this way. Whenever we are about to start up the target
- for whatever reason, we check to see if there is a breakpoint at the
instruction where we are starting and if so we push a
"ThreadPlanStepOverBreakpoint" which removes the breakpoint, puts
Author: jingham
Date: Tue Feb 2 18:07:23 2016
New Revision: 259611
URL: http://llvm.org/viewvc/llvm-project?rev=259611&view=rev
Log:
The compiler may use "line number 0" to indicate compiler generated goo that it
can't
track a source for. When we are pushing breakpoints and stepping past funct
;t you write a test for this by stepping over a function call which has
> this kind of code in it?
>
> On Tue, Feb 2, 2016 at 4:11 PM Jim Ingham via lldb-commits
> wrote:
> Author: jingham
> Date: Tue Feb 2 18:07:23 2016
> New Revision: 259611
>
> URL: http://llvm.org/v
Author: jingham
Date: Wed Feb 3 13:45:31 2016
New Revision: 259684
URL: http://llvm.org/viewvc/llvm-project?rev=259684&view=rev
Log:
The SetStopInfo from a Mach Exception was setting the stop
reason to None when we stop due to a trace, then noticed that
we were on a breakpoint that was not valid
Author: jingham
Date: Wed Feb 3 13:49:03 2016
New Revision: 259685
URL: http://llvm.org/viewvc/llvm-project?rev=259685&view=rev
Log:
Remove a stray ;.
Modified:
lldb/trunk/source/Target/Thread.cpp
Modified: lldb/trunk/source/Target/Thread.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/t
Author: jingham
Date: Wed Feb 3 19:34:33 2016
New Revision: 259738
URL: http://llvm.org/viewvc/llvm-project?rev=259738&view=rev
Log:
Fix a little threading thinko in StartPrivateStateThread - don't pass stack
variables
as args to a pthread_create function...
Modified:
lldb/trunk/include/l
Author: jingham
Date: Thu Feb 4 13:42:32 2016
New Revision: 259818
URL: http://llvm.org/viewvc/llvm-project?rev=259818&view=rev
Log:
Make HostThread SetName work on OS X. GetName doesn't currently work, the code
that was in
GetName actually got the queue name not the thread name and anyway didn
Author: jingham
Date: Fri Feb 5 18:31:23 2016
New Revision: 259962
URL: http://llvm.org/viewvc/llvm-project?rev=259962&view=rev
Log:
Fix "thread backtrace -s": option was misparsed because of a missing break.
Modified:
lldb/trunk/source/Commands/CommandObjectThread.cpp
Modified: lldb/trun
y Turner wrote:
>
> Sounds like we don't have a test for thread backtrace -s. I know I usually
> argue against tests of the CLI, but only when they're used instead of tests
> for the api. Seems like we should have at least one test for every option of
> every command.
&g
> On Feb 5, 2016, at 4:43 PM, Enrico Granata via lldb-commits
> wrote:
>
> Modified: lldb/trunk/source/Target/LanguageRuntime.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/LanguageRuntime.cpp?rev=259964&r1=259963&r2=259964&view=diff
> ===
Is it ever right for a Command to add a subcommand from a different
CommandInterpreter? If it is not (and I am pretty sure it isn't) then this
check should be done in LoadSubCommand, where you would check the to-be-added
command's interpreter against the added-to's interpreter. This would
imm
jingham added a comment.
This seems fine as a generic instrumentation point. Obviously, the onus in on
the passes, since they could totally ruin the expression evaluation if they
don't do their job right... But I'm not sure there's any good way to make this
not a sharp tool. But you should w
Author: jingham
Date: Tue Feb 9 12:53:49 2016
New Revision: 260247
URL: http://llvm.org/viewvc/llvm-project?rev=260247&view=rev
Log:
Mention the --all-files option in the -p help string.
Modified:
lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp
Modified: lldb/trunk/source/Commands/Co
Author: jingham
Date: Tue Feb 9 19:33:58 2016
New Revision: 260345
URL: http://llvm.org/viewvc/llvm-project?rev=260345&view=rev
Log:
Add a missing break.
Modified:
lldb/trunk/tools/debugserver/source/debugserver.cpp
Modified: lldb/trunk/tools/debugserver/source/debugserver.cpp
URL:
http://
Author: jingham
Date: Tue Feb 9 21:25:24 2016
New Revision: 260352
URL: http://llvm.org/viewvc/llvm-project?rev=260352&view=rev
Log:
This is an idea to make "thread step-in --target" work for the common
case where you have:
1 ->foo (bar(),
2baz(),
3lala());
4
You are
> On Feb 10, 2016, at 3:45 AM, Luke Drummond wrote:
>
> ldrumm added a comment.
>
>
>
> In http://reviews.llvm.org/D17027#347487, @jingham wrote:
>
>> This seems fine as a generic instrumentation point. Obviously, the onus in
>> on the passes, since they could totally ruin the expression e
course of stepping", which as you point out we
already have breakpoints for. The command will work as described even if bar
calls foo because "step-in" always only steps one level deep and then either
stops or immediately steps back out, so it would never notice the call
foo-&
Author: jingham
Date: Wed Feb 10 16:30:20 2016
New Revision: 260452
URL: http://llvm.org/viewvc/llvm-project?rev=260452&view=rev
Log:
Revert 260436. I pretty consistently upper-case the letter I use for the
short option as an aid to memory. Like it's w because of the W in throW.
That helps me r
jingham added a subscriber: jingham.
jingham added a comment.
Unless something has changed since last I looked, the llvm path utilities are
host specific. I didn't inspect the code where this is being used, but it is
in Host/common, so unless there's an ifdef WINDOWS around it, I don't think yo
Unless something has changed since last I looked, the llvm path utilities are
host specific. I didn't inspect the code where this is being used, but it is
in Host/common, so unless there's an ifdef WINDOWS around it, I don't think you
should use the llvm path utilities.
Jim
> On Feb 10, 2016,
My bad, that sees to be what it does.
Jim
> On Feb 10, 2016, at 4:59 PM, Zachary Turner wrote:
>
> zturner added a comment.
>
> In http://reviews.llvm.org/D17107#349421, @jingham wrote:
>
>> Unless something has changed since last I looked, the llvm path utilities
>> are host specific. I di
jingham added a comment.
My bad, that sees to be what it does.
Jim
Repository:
rL LLVM
http://reviews.llvm.org/D17107
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: jingham
Date: Thu Feb 11 18:03:19 2016
New Revision: 260624
URL: http://llvm.org/viewvc/llvm-project?rev=260624&view=rev
Log:
When calling TypeSystemMap::Clear, objects being destroyed in the process of
clearing the map ended up calling back into the TypeSystemMap to do lookups.
Not a g
Author: jingham
Date: Fri Feb 12 18:31:47 2016
New Revision: 260772
URL: http://llvm.org/viewvc/llvm-project?rev=260772&view=rev
Log:
Adding an SBThread::StepInto that takes an end-line, also moved the code that
figures
out the address range for the step to SymbolContext.
Modified:
lldb/trun
Author: jingham
Date: Mon Feb 15 14:04:15 2016
New Revision: 260909
URL: http://llvm.org/viewvc/llvm-project?rev=260909&view=rev
Log:
Refinement of r260624. It is possible somebody might try to add to the map
while we are finalizing its elements. Prevent that.
Modified:
lldb/trunk/include
jingham added a subscriber: jingham.
jingham added a comment.
Other than that is looks fine.
Comment at:
source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp:559-560
@@ -558,5 +558,4 @@
-static bool FindFunctionInModule (ConstString &mangled_name,
-
Author: jingham
Date: Wed Feb 17 19:28:22 2016
New Revision: 261183
URL: http://llvm.org/viewvc/llvm-project?rev=261183&view=rev
Log:
Add usage instructions for TypeSystemMap::AddToMap.
Modified:
lldb/trunk/include/lldb/Symbol/TypeSystem.h
Modified: lldb/trunk/include/lldb/Symbol/TypeSystem.
Author: jingham
Date: Thu Feb 18 17:58:45 2016
New Revision: 261279
URL: http://llvm.org/viewvc/llvm-project?rev=261279&view=rev
Log:
Make sure code that is in the middle of figuring out the correct architecture
on attach uses the architecture it has figured out, rather than the Target's
architect
Please don't make this sort of change. With the code as originally written, I
can set a breakpoint on the returns "true" or "false" case separately, and stop
there if I am doing that experiment, whereas your change makes that impossible.
Neither one is particularly harder to read than the othe
+1
We put the header file first immediately after the header comment in the .cpp
file. The reason is that if you put the .cpp file's associated .h file in the
project include headers section, then it would be easy to accidentally put
another "project include" in front of the associated one (f
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
IIUC, what you are doing here is when lldb-server gets a "step instruction"
request that would step into one of these atomic regions, it sets a bunch of
breakpoints on it's end (no
Yes, exactly.
Jim
> On Feb 24, 2016, at 4:11 AM, Tamas Berghammer wrote:
>
> tberghammer added a comment.
>
> In http://reviews.llvm.org/D17535#360519, @bhushan wrote:
>
>> In MIPS, we can not put a breakpoint in middle of an atomic sequence.
>> If we do so (and that breakpoint is hit) then c
jingham added a subscriber: jingham.
jingham added a comment.
Yes, exactly.
Jim
Repository:
rL LLVM
http://reviews.llvm.org/D17535
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-comm
Author: jingham
Date: Thu Feb 25 19:37:30 2016
New Revision: 261953
URL: http://llvm.org/viewvc/llvm-project?rev=261953&view=rev
Log:
Add the "block" keyword to "thread step-in -e", and an alias that uses it: "sif
" - i.e. step-into-function
to allow you to step through a complex calling sequence
Ah, thanks, I missed that!
Jim
> On Feb 25, 2016, at 7:36 PM, Chaoren Lin via lldb-commits
> wrote:
>
> Author: chaoren
> Date: Thu Feb 25 21:36:27 2016
> New Revision: 261969
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261969&view=rev
> Log:
> Clear alias argument vector for 'p' alias.
jingham added a subscriber: jingham.
jingham added a comment.
It's okay to short-circuit this here, but why was PrivateResume not returning
an error when the process was not alive. That error should have gotten
propagated to the caller, obviating the need for this short-circuit.
http://review
jingham requested changes to this revision.
jingham added a reviewer: jingham.
jingham added a comment.
This revision now requires changes to proceed.
I agree with Zachary, it would be better to put it in PrivateResume before the
call to WillResume. Having this happen in Process::PrivateResume a
Author: jingham
Date: Fri Feb 26 13:33:11 2016
New Revision: 262051
URL: http://llvm.org/viewvc/llvm-project?rev=262051&view=rev
Log:
SymbolFileDWARFDebugMap::FindTypes didn't obey the max_matches flag,
but kept looking through .o files even after it had found as many
matches as were requested.
jingham added a comment.
I don't think you can manipulate the public run lock in PrivateResume like
this. PrivateResume gets run in a bunch of places (like calling functions)
that are way below the level the public run lock. You probably need to catch
errors from PrivateResume in Resume and r
The straightforward way to do specify a complex command line for debugging is:
lldb —arch=x86_64 — /bin/ls -IAF
everything after the — are arguments to the program. This also allows you to
cut & paste whole command lines. It works by the trick that if you haven’t
specified a file before the —
There's an lldb-private-forward.h that you can use for this purpose if you wish.
Jim
> On Mar 1, 2016, at 10:32 AM, Zachary Turner via lldb-commits
> wrote:
>
>
>
> On Tue, Mar 1, 2016 at 10:10 AM Greg Clayton wrote:
> clayborg requested changes to this revision.
> clayborg added a comment.
jingham added a comment.
IIUC, we can't get out of the business of supporting the HostGetOpt on freebsd
& windows since we can't use the llvm version for the command line. So I don't
see that it much eases the support burden. The differences in the help output
don't seem significant, which do
Fixed with r262543
Jim
> On Mar 2, 2016, at 5:10 PM, Ying Chen via lldb-commits
> wrote:
>
> chying added a subscriber: chying.
> chying added a comment.
>
> Seems this patch breaks OSX build. I guess the new files were not added to
> xcode project file.
> Could you please take a look?
> htt
jingham added a subscriber: jingham.
jingham added a comment.
Fixed with r262543
Jim
http://reviews.llvm.org/D17363
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jingham added a subscriber: jingham.
jingham added a comment.
This looks fine to me.
http://reviews.llvm.org/D17848
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jingham added a comment.
At some point we should deal with the loss of information when we resolve
re-mapped paths. For instance, here I set a breakpoint by the moved source
location's full path, and that gets remapped to the build location. That's
lovely since it makes the breakpoint take, b
> On Mar 2, 2016, at 10:18 AM, Greg Clayton wrote:
>
> So this is nice that you cleaned up this one place where we can use LLVM's
> option parsing stuff, but it now makes the driver inconsistent with the rest
> of LLDB. It also makes it so you have to link some LLVM .a files into the
> lldb c
jingham added a subscriber: jingham.
jingham added a comment.
I don't think this is right. It is possible to have a sc.symbol be nullptr,
but sc.function be valid. So the check for sc.symbol will reject the valid
information in the function. Note, the code in the function is also wrong,
sinc
jingham added a comment.
Greg suggests adding something to SymbolContext to get the start address of the
function that handles this possibility. GetAddressRange sort of does this, but
only if the SymbolContext doesn't have a block or line entry.
http://reviews.llvm.org/D17860
_
Thanks, Tamas, sorry I missed that. Looks like everything is green again.
Jim
> On Mar 8, 2016, at 5:39 AM, Tamas Berghammer wrote:
>
> I committed in a fix as rL262925 (initialization order issue in a log line)
>
> On Tue, Mar 8, 2016 at 3:04 AM Jim Ingham via lldb-commits
> On Mar 8, 2016, at 2:46 PM, Ted Woodward wrote:
>
> ted added a comment.
>
> The change is to guard against the case where candidate_sc.symbol is nullptr.
>
> candidate_sc.function is only used when load_address != LLDB_INVALID_ADDRESS,
> but load_address is set on line 802:
>
> load_addr
We use the entry point address as the place to stop when we call functions by
hand in the target. That's one place which is legit TEXT, but we are pretty
sure the code you are calling will never call. So if the entry point address
isn't set correctly we probably won't be able to call any funct
jingham added a subscriber: jingham.
jingham added a comment.
We use the entry point address as the place to stop when we call functions by
hand in the target. That's one place which is legit TEXT, but we are pretty
sure the code you are calling will never call. So if the entry point address
Author: jingham
Date: Wed Mar 9 12:59:13 2016
New Revision: 263049
URL: http://llvm.org/viewvc/llvm-project?rev=263049&view=rev
Log:
Add an "offset" option to "break set -n" and "break set -f -l".
That way you can set offset breakpoints that will move as the function they are
contained in move
Right. If we have both, the symbol should be faster and won't potentially drag
in more debug info, so we should use it. If the two have different addresses
that's a more fundamental problem we shouldn't try to patch over here. We
should only use the function if it's all we have. Note also, i
In the case of something like SBAddress, I think it would be better to have a
class header that explains file/load addresses and section offset addresses.
Then you can just use the terms in the function documentation, and they can be
shorter and more explicit. Trying to define terms inline like
jingham added a subscriber: jingham.
jingham added a comment.
The source change looks fine, but Greg's the owner of this code so I'll let him
say yes for sure.
But don't call the test case "ExpressionPath". The expression parser is
different from frame variable. I understand that your intent
jingham added a comment.
There's actually already a test for handling C anonymous unions in
lang/c/anonymous. That tests the expression parser and some direct SBValue
queries at present. It would be appropriate to add your test as another test
case in here.
Repository:
rL LLVM
http://rev
jingham added a comment.
The part of frame variable you are testing here - namely the parsing of these
"frame variable" paths, can also be directly accessed with
SBValue::GetValueForExpressionPath (aargh, shouldn't have called that
"expression" should we? Too late to change now.) Anyway, you
jingham added a comment.
That seems fine to me. Thanks for putting up with the niggling...
http://reviews.llvm.org/D17860
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
The relation between section offsets and files is stronger than you are stating
here. You say:
+/// Represents an address. An address may refer to code or data from an
+/// existing module, or it may refer to something on the stack or heap.
+///
That part is good, but you should use that in th
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
I marked a comment left over from a previous draft of the patch that isn't
needed. Other than that, this looks fine.
Comment at: source/Target/Process.cpp:3561-3562
@@ +35
jingham added a comment.
More precisely, the "Public running lock..." part of the comment.
http://reviews.llvm.org/D17635
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: jingham
Date: Thu Mar 10 19:57:45 2016
New Revision: 263183
URL: http://llvm.org/viewvc/llvm-project?rev=263183&view=rev
Log:
Fix SBDebugger.GetOutputFileHandle() on OS X.
The swig typemaps had some magic for output File *'s on OS X that made:
SBDebugger.GetOutputFileHandle()
actually
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
Yeah, I'm beginning to wonder whether we're doing ourselves a favor by putting
off computing the ObjC runtime symbols till some time that's bound to be more
inconvenient than right
jingham added a comment.
Another even safer way to do this is to take the thread list, turn it into a
vector of TID's, then iterate over the TID's looking them up one at a time as
you go. That way you don't have to worry about your ThreadSP going stale. You
could even change HandleOneThread t
jingham added a comment.
Oh, yeah, and note the other branch of the if holds the thread list mutex the
whole time. So you'll need to change that to get the list of threads, then
drop the mutex & iterate over them or you'll get into the same problem if
somebody does:
(lldb) thread backtrace 1
Few more comments...
+/// If an address comes from an existing module, then it will be resolved
+/// into an offset from its containing section in that module. That way it
+/// can refer to the same logical location as the module that holds it even
Probably my error, but "location as the module"
Author: jingham
Date: Fri Mar 11 12:49:38 2016
New Revision: 263274
URL: http://llvm.org/viewvc/llvm-project?rev=263274&view=rev
Log:
Check for a NULL input filehandle before referencing it.
Modified:
lldb/trunk/scripts/Python/python-typemaps.swig
Modified: lldb/trunk/scripts/Python/python
Author: jingham
Date: Fri Mar 11 13:15:03 2016
New Revision: 263283
URL: http://llvm.org/viewvc/llvm-project?rev=263283&view=rev
Log:
Remove the skip if Darwin since I fixed the crash.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/python_api/default-constructor/TestDefaultConstructorFo
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
That looks good, thanks.
http://reviews.llvm.org/D18075
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin
We use UINT32_MAX and so forth all over in lldb. Were you planning to switch
over all the uses? That seem like something you should not do unilaterally,
but we should decide on as a group.
I originally thought maybe this would buy us some type safety, but it looks
like (and the docs seem to i
Author: jingham
Date: Fri Mar 11 20:45:34 2016
New Revision: 263326
URL: http://llvm.org/viewvc/llvm-project?rev=263326&view=rev
Log:
This change introduces a "ExpressionExecutionThread" to the ThreadList.
Turns out that most of the code that runs expressions (e.g. the ObjC runtime
grubber) on
Author: jingham
Date: Fri Mar 11 21:33:36 2016
New Revision: 26
URL: http://llvm.org/viewvc/llvm-project?rev=26&view=rev
Log:
Let's not convert from UINT32_MAX to the std::numeric_limits version.
Modified:
lldb/trunk/source/Core/DataEncoder.cpp
lldb/trunk/source/Core/Disassembler.
Author: jingham
Date: Tue Mar 15 16:11:02 2016
New Revision: 263588
URL: http://llvm.org/viewvc/llvm-project?rev=263588&view=rev
Log:
Remove unnecessary includes.
Modified:
lldb/trunk/source/Core/DataEncoder.cpp
lldb/trunk/source/Core/DataExtractor.cpp
lldb/trunk/source/Core/Disassem
t; wrote:
> If we're favoring the macros over the functions, then
> perhaps update the #includes?
>
> On Fri, Mar 11, 2016 at 7:33 PM, Jim Ingham via lldb-commits
> wrote:
> Author: jingham
> Date: Fri Mar 11 21:33:36 2016
> New Revision: 26
>
> URL: h
how? I thought C++ numeric_limits were
> > actually preferred over the C macros.
> >
> > On Mon, Mar 14, 2016 at 7:59 AM Adrian McCarthy via lldb-commits
> > wrote:
> > If we're favoring the macros over the functions, then
> > perhaps update the #includes?
&
The only other suggestion I have is that the first time we refer to a module in
this file
we should say "(see SBModule)" or something like that to make it clear what we
mean by a module.
Other than that this looks good to me.
Jim
> On Mar 15, 2016, at 5:05 PM, John Lindal wrote:
>
> Great!
Author: jingham
Date: Fri Mar 18 19:53:20 2016
New Revision: 263865
URL: http://llvm.org/viewvc/llvm-project?rev=263865&view=rev
Log:
Use Enrico's new CommandAlias to give better help to the "sif" command.
Modified:
lldb/trunk/source/Interpreter/CommandInterpreter.cpp
Modified: lldb/trunk/so
Author: jingham
Date: Fri Mar 18 19:21:21 2016
New Revision: 263861
URL: http://llvm.org/viewvc/llvm-project?rev=263861&view=rev
Log:
Fix the project file for the removal of lldb-mi's Platform.cpp.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/projec
Author: jingham
Date: Mon Mar 21 14:21:13 2016
New Revision: 263972
URL: http://llvm.org/viewvc/llvm-project?rev=263972&view=rev
Log:
Compilation can end up calling functions (e.g. to resolve indirect functions)
so I added
a way for compilation to take a "thread to use for compilation". If it is
Once per login session. You may also need to run:
sudo /usr/sbin/DevToolsSecurity --enable
if you've never debugged anything before. You should only need to do this once
per clean OS install.
Jim
> On Mar 24, 2016, at 2:53 PM, Zachary Turner via lldb-commits
> wrote:
>
> Is it one time un
Author: jingham
Date: Thu Mar 24 20:57:14 2016
New Revision: 264379
URL: http://llvm.org/viewvc/llvm-project?rev=264379&view=rev
Log:
Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. "."
for "->".)
This feature is controlled by an expression command option, a target pro
off? Seems to me like off should be default
> >
> > An enumerated setting would be even nicer, where one option is "report"
> > that just doesn't apply any FixIts, but prints a message saying "did you
> > mean Foo->bar()?"
> > On Thu, Mar 24
Author: jingham
Date: Tue Mar 29 17:00:08 2016
New Revision: 264793
URL: http://llvm.org/viewvc/llvm-project?rev=264793&view=rev
Log:
Figure out what the fixed expression is, and print it. Added another target
setting to
quietly apply fixits for those who really trust clang's fixits.
Also, move
Author: jingham
Date: Wed Mar 30 13:14:36 2016
New Revision: 264883
URL: http://llvm.org/viewvc/llvm-project?rev=264883&view=rev
Log:
Fix header name.
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h
Modified: lldb/trunk/source/Plugins/ExpressionParser/Clang/Clang
I don't agree that asserts are good in released code unless you have no way of
backing out of the situation you find yourself in. After all, you are saying
to some unlucky user out there that they can't use the debugger on their app
and in general there's nothing they can do about it. Greg's s
jingham added a subscriber: jingham.
jingham added a comment.
I don't agree that asserts are good in released code unless you have no way of
backing out of the situation you find yourself in. After all, you are saying
to some unlucky user out there that they can't use the debugger on their app
es using other debug info which is not
> corrupt, but you terminate all those sessions because one piece of unrelated
> debug info in an unrelated process is bad. Doesn't seem right to me.
>
> debug info is program input, and you would never assert on program input, you
> hav
> On Apr 1, 2016, at 3:43 AM, Tamas Berghammer wrote:
>
> tberghammer added a comment.
>
> This assert is NOT verifying the debug info itself. It is verifying that LLDB
> asked the right SymbolFileDWARFDwo to find a DIE based on a DIERef.
> Independently of the debug info (what can be garbage
jingham added a subscriber: jingham.
jingham added a comment.
The only worry I have about this is
- thread A is stopped at a breakpoint, and then we stop on thread B instead,
then we report a breakpoint, great!
- The user steps thread B, which we do by suspending thread B and stepping A.
- Then
jingham accepted this revision.
jingham added a reviewer: jingham.
jingham added a comment.
Yes, that sounds right.
http://reviews.llvm.org/D18692
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listin
Author: jingham
Date: Tue Apr 5 19:24:17 2016
New Revision: 265494
URL: http://llvm.org/viewvc/llvm-project?rev=265494&view=rev
Log:
Don't write "using $_lldb_local_vars" statements for variables with
no name. These were showing up with a recent clang, I haven't tracked
down why yet, but adding
Author: jingham
Date: Tue Apr 5 19:25:44 2016
New Revision: 265496
URL: http://llvm.org/viewvc/llvm-project?rev=265496&view=rev
Log:
The FixItList typedef should have been inside "class ClangDiagnostic".
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h
Modified:
Author: jingham
Date: Tue Apr 5 19:25:04 2016
New Revision: 265495
URL: http://llvm.org/viewvc/llvm-project?rev=265495&view=rev
Log:
If the fixed expression doesn't parse, don't tell the user about it.
Modified:
lldb/trunk/source/Expression/UserExpression.cpp
Modified: lldb/trunk/source/Exp
Will this be necessary for everybody who uses "command script import" with
Python 3? If so, it would be really nice to do this work in "command script
import" if possible. Otherwise everybody will have to put this goo at the top
of every .py file they write for formatters & breakpoint commands
701 - 800 of 1210 matches
Mail list logo
