Author: jingham
Date: Tue Oct 9 17:51:30 2018
New Revision: 344102
URL: http://llvm.org/viewvc/llvm-project?rev=344102&view=rev
Log:
Add "var" and "vo" aliases for "frame variable" and "frame variable -O".
Differential Revision: https://reviews.llvm.org/D53010
Modified:
lldb/trunk/source/Co
Author: jingham
Date: Fri Oct 12 11:46:02 2018
New Revision: 344397
URL: http://llvm.org/viewvc/llvm-project?rev=344397&view=rev
Log:
Add "v" as well as "var" as an alias for "frame var".
Modified:
lldb/trunk/source/Interpreter/CommandInterpreter.cpp
Modified: lldb/trunk/source/Interpreter
Author: jingham
Date: Fri Oct 12 14:27:49 2018
New Revision: 344418
URL: http://llvm.org/viewvc/llvm-project?rev=344418&view=rev
Log:
Change the default handling for SIGPIPE to pass/,no-stop/no-notify.
Most of the time SIGPIPE is just annoying, and so we should
pass it on silently it by default.
Author: jingham
Date: Tue Oct 16 14:58:40 2018
New Revision: 344647
URL: http://llvm.org/viewvc/llvm-project?rev=344647&view=rev
Log:
Return a named error in the result object of an expression with no result
Before we returned an error that was not exposed in the SB API and no useful
error messag
So far as I can tell, this patch will make lookup of exact types faster for
PDB, but because of the way DWARF debug_names tables are constructed, I don't
think there's any way we can do the same thing for DWARF.
But unless I'm misunderstanding the patch, this doesn't change correctness of
the l
Ah, right... Too many patches (a good problem!)
The standard as I read it says that the name entry points into the general
string table, but doesn't specify which entry it points to. However, the
current DWARF debug_info doesn't ever emit a string for the fully qualified
name, so you would ha
I am pretty sure the has is computed from the name string. And BTW, having the
base name in the quick lookup tables (either with or alongside the full name)
is a really good thing. People using the debugger really don't want to type
out fully qualified names as a general rule. So you have to
gdb's expression parser went out of it's way to allow you to type as little as
possible, and to do things that made no sense in the current context (use
variables and types in expressions that aren't actually visible in the current
context, etc). People's workflows came to really depend on thes
Author: jingham
Date: Fri Nov 2 16:42:40 2018
New Revision: 346053
URL: http://llvm.org/viewvc/llvm-project?rev=346053&view=rev
Log:
Add an SBExpressionOptions setting mirroring the "exec" command's --allow-jit.
Differential Revision: https://reviews.llvm.org/D54056
Added:
lldb/trunk/pack
Thanks for doing this! Why do we care about the file name of the test,
shouldn't we be using the test class name for everything (that one I did
remember to change...)
Jim
> On Nov 3, 2018, at 11:18 PM, Jan Kratochvil via Phabricator
> wrote:
>
> jankratochvil added a comment.
>
> In https
Author: jingham
Date: Mon Nov 5 12:15:27 2018
New Revision: 346162
URL: http://llvm.org/viewvc/llvm-project?rev=346162&view=rev
Log:
Fix the Xcode project for the removal of the Go, Java & OCaml
plugins.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj
For dotest style tests, the debug format to test is chosen by the test driver.
All the tests should run with any format, but sometimes there are bugs in one
reader or another (or in one version of DWARF or another) so you can skip or
xfail a test based on format. Sounds like this test should b
Author: jingham
Date: Tue Nov 13 10:18:32 2018
New Revision: 346775
URL: http://llvm.org/viewvc/llvm-project?rev=346775&view=rev
Log:
Since ABI's now hold a process WP, they should be handed
out one per process rather than keeping a single global instance.
Differential Revision: https://reviews.l
Author: jingham
Date: Thu Dec 6 11:23:21 2018
New Revision: 348519
URL: http://llvm.org/viewvc/llvm-project?rev=348519&view=rev
Log:
Fix the Xcode project build for the addition of
NativePDB/DWARFLocationExpression.{h,cpp}
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/
Author: jingham
Date: Thu Dec 6 17:18:40 2018
New Revision: 348559
URL: http://llvm.org/viewvc/llvm-project?rev=348559&view=rev
Log:
Handle detecting exec for DynamicLoaderMacOS with older debugservers
that don't send reason:exec.
Differential Revision: https://reviews.llvm.org/D55399
Modifie
Author: jingham
Date: Thu Dec 6 18:28:04 2018
New Revision: 348561
URL: http://llvm.org/viewvc/llvm-project?rev=348561&view=rev
Log:
Add SBInitializerOptions.h to the Xcode project.
And mark it as a public header so it will get copied
into the LLDB.framework. A handful of "api" tests were
faili
It the section isn't in the target's SectionLoadList, then GetLoadAddress
should return LLDB_INVALID_ADDRESS. I.e. this bit from
Section::GetLoadBaseAddress:
load_base_addr = target->GetSectionLoadList().GetSectionLoadAddress(
const_cast(this)->shared_from_this());
should return LL
The current behavior is definitely correct. An Address without a section is
generally going to be something like a stack or heap address. Those definitely
have load addresses of whatever their value is.
I'm not sure what it means to have a file address represented as an offset not
a section w
Author: jingham
Date: Tue Dec 11 11:25:03 2018
New Revision: 348890
URL: http://llvm.org/viewvc/llvm-project?rev=348890&view=rev
Log:
Add ObjectFileBreakpad.{cpp,h} to the Xcode project.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
U
Sections can have parents. In MachO the text and data sections are actually
contained in the TEXT and DATA segments respectively. LLDB represents this by
having an lldb_private::Section for the segment, and then all the sections in
that segment are children of the parent Section (the MachO seg
In MachO a segment fully contains its sections and a section can only be in one
segment. I don't remember how much the lldb Section nesting code enforces
this. It would be weird to have two Sections at the same level overlap, I
don't see any "GetSectionsForAddress(lldb::addr_t address)" API's
Author: jingham
Date: Fri Dec 14 15:27:08 2018
New Revision: 349211
URL: http://llvm.org/viewvc/llvm-project?rev=349211&view=rev
Log:
Fix the unittests for the move of Listener & Broadcaster
from Core to Utility.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.x
Author: jingham
Date: Mon Dec 17 17:49:02 2018
New Revision: 349435
URL: http://llvm.org/viewvc/llvm-project?rev=349435&view=rev
Log:
Call DeleteCurrentProcess before we replace the old process.
We need to ensure that Finalize gets called before we start
to destroy the old Process or the weak_ptr
Author: jingham
Date: Thu Dec 20 17:45:28 2018
New Revision: 349874
URL: http://llvm.org/viewvc/llvm-project?rev=349874&view=rev
Log:
"help finish" tells you it is an alias. "help fin" doesn't.
They both run the same command, and people get used to typing the shortest
string they can, so we shou
Author: jingham
Date: Mon May 21 15:41:28 2018
New Revision: 332914
URL: http://llvm.org/viewvc/llvm-project?rev=332914&view=rev
Log:
Fix the Xcode project for the refactoring of the
DWARF reader.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project
Author: jingham
Date: Mon May 21 17:06:55 2018
New Revision: 332922
URL: http://llvm.org/viewvc/llvm-project?rev=332922&view=rev
Log:
Work around some odd instruction single-step behavior on macOS.
We've seen some cases on macOS where you go to instruction single
step (over a breakpoint), and sin
continue (after the first $s packet, server stays at 0x1010, after the
> second one it advances to 0x1011, after the final $c, return W00)
> - verify the expected packets were sent
>
> Have you tried using MockGdbServer in this way?
>
> regards,
> pl
>
> On Tue, 22 M
--address 0x1010
>> - continue (server pretends to stop at 0x1010)
>> - continue (after the first $s packet, server stays at 0x1010, after the
>> second one it advances to 0x1011, after the final $c, return W00)
>> - verify the expected packets were sent
>>
>&
Where clang stores modules by default on the host system seems like a Host
function. It isn't in practice because that gets delegated to clang to do the
host specific calculation, but in theory that seems where the functionality
properly belongs. It's a little odd to have ModuleList depend on
The expression command had two modes before introducing the REPL. You can do:
(lldb) expr -- some C expression
or you can do:
(lldb) expr
Enter expressions, then terminate with an empty line to evaluate:
1: first C expression
2: Second C Expression
3:
The second only differs from the fi
> On May 23, 2018, at 7:21 PM, Zachary Turner wrote:
>
>
> On Wed, May 23, 2018 at 7:04 PM Jim Ingham via Phabricator
> wrote:
> jingham added a comment.
>
> I worry when concerns of layering which seem a little artificial to me would
> make us add a shadow class for something that is alre
Author: jingham
Date: Thu May 24 10:06:48 2018
New Revision: 333208
URL: http://llvm.org/viewvc/llvm-project?rev=333208&view=rev
Log:
pc's should be printed in hex...
Modified:
lldb/trunk/source/Target/ThreadPlanStepOverBreakpoint.cpp
Modified: lldb/trunk/source/Target/ThreadPlanStepOverBrea
Author: jingham
Date: Thu May 24 10:06:11 2018
New Revision: 333207
URL: http://llvm.org/viewvc/llvm-project?rev=333207&view=rev
Log:
Add SystemInitializerLLGS to the lldb-server target.
This should unbreak the xcode build.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/
Author: jingham
Date: Thu May 24 16:33:27 2018
New Revision: 333238
URL: http://llvm.org/viewvc/llvm-project?rev=333238&view=rev
Log:
Add DWARFBaseDie.{h,cpp} to the Xcode build.
This should unbreak the green dragon bot builds.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: l
Author: jingham
Date: Mon Jun 4 17:19:03 2018
New Revision: 333971
URL: http://llvm.org/viewvc/llvm-project?rev=333971&view=rev
Log:
Add ClangHost.cpp to the Xcode project.
Also add an include that was needed for the if APPLE branch
of the function.
Modified:
lldb/trunk/lldb.xcodeproj/pr
> On Jun 11, 2018, at 2:19 PM, Leonard Mosescu via lldb-commits
> wrote:
>
> Author: lemo
> Date: Mon Jun 11 14:19:26 2018
> New Revision: 334439
>
> URL: http://llvm.org/viewvc/llvm-project?rev=334439&view=rev
> Log:
> Add a new SBTarget::LoadCore() overload which surfaces errors if the load
Thanks for the explanation!
Jim
> On Jun 15, 2018, at 2:35 AM, Pavel Labath via Phabricator
> wrote:
>
> labath added a comment.
>
> Thank you for implementing this. We've had code like this in android studio
> for a long time, but it's definitely better doing it in lldb instead.
>
> I'll
The SB API's tend to take SBError as an in/out parameter for the cases where
the function in question naturally returns some other value, and return an
SBError when there's no other logical return value.
So in these cases it would be more in line with the general practice to return
an SBError.
Won't this break client code that was calling StepOver? We are pretty serious
about maintaining binary compatibility with the SB API's.
Jim
> On Jun 20, 2018, at 11:19 AM, Alexander Polyakov via Phabricator
> wrote:
>
> apolyakov added a comment.
>
> I think we just can make old versions o
The client won't be expecting a struct return, and will have generated code to
take a void return. If SBError happens to be returned in registers, nothing
bad will happen, but if it's returned on the stack, that would corrupt the
caller's stack. Relying on the particular kind of struct return
> On Jun 20, 2018, at 3:14 PM, Frederic Riss via Phabricator
> wrote:
>
> friss added a comment.
>
> In https://reviews.llvm.org/D48393#1138398, @zturner wrote:
>
>> Long term I think one potentially interesting possibility for solving a lot
>> of these threading and lazy evaluation issues
This change will break building from Xcode without Python. It will take a
bunch of monkeying with the project files to achieve the same effect as your
cmake changes, and I don't have time to do that right now. I have no problem
with changing cmake to just not build the relevant files, but can
Part of gdb's slow startup used to be because it built its indexes manually.
But also, while gdb does do lazy ingestion of debug information it's laziness
is (or was last time I looked at it) on a compile-unit boundary, so when you
stop in a file that includes a many complex types you can end
Yes, I really wish unittest2 allowed non-aborting tests. If you split up all
these tests, then you make the testsuite have to build and run some little
executable over and over. It would be so nice if there were a way to say:
self.startTestBundle()
self.assertTrue(something)
...
self.
> On Jun 22, 2018, at 3:19 AM, Pavel Labath via Phabricator
> wrote:
>
> labath added a comment.
>
> I think this would be a very nice feature for lldb. Thank you for working on
> this.
>
> However, I am somewhat worried about how you're hooking the expression
> completer into the completi
> On Jun 22, 2018, at 4:05 AM, Pavel Labath wrote:
>
> On Wed, 20 Jun 2018 at 23:21, Jim Ingham wrote:
>>
>> It is not uncommon that you would be parsing the DWARF for module A and find
>> a type that is only known as a forward declaration. In that case, lldb will
>> look through the other
> On Jun 22, 2018, at 5:20 PM, Jim Ingham wrote:
>
> This is very cool!
>
> Could we make a base class for lldb commands in the lldb module that provides
> register_lldb_command? Then you wouldn't have to copy and paste this
> boiler-plate in every command file. Now that you have a gener
Author: jingham
Date: Tue Jun 26 13:40:29 2018
New Revision: 335659
URL: http://llvm.org/viewvc/llvm-project?rev=335659&view=rev
Log:
Reverting r335656, SWIG doesn't like "enum class".
Modified:
lldb/trunk/include/lldb/lldb-enumerations.h
Modified: lldb/trunk/include/lldb/lldb-enumerations.h
Author: jingham
Date: Tue Jun 26 16:31:44 2018
New Revision: 335688
URL: http://llvm.org/viewvc/llvm-project?rev=335688&view=rev
Log:
This is not a debug info sensitive test.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py
Modified:
lldb/tr
Author: jingham
Date: Tue Jun 26 16:38:58 2018
New Revision: 335689
URL: http://llvm.org/viewvc/llvm-project?rev=335689&view=rev
Log:
The Process class ivar ivar was changed to a weak pointer, but was still _sp.
Fix that to _wp.
Modified:
lldb/trunk/include/lldb/Target/Process.h
lldb/trun
Author: jingham
Date: Tue Jun 26 16:54:50 2018
New Revision: 335690
URL: http://llvm.org/viewvc/llvm-project?rev=335690&view=rev
Log:
Use the API's to get the TargetSP.
Modified:
lldb/trunk/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
Modified: lldb/trunk/source/Plugins/Process/W
Author: jingham
Date: Thu Jun 28 13:02:11 2018
New Revision: 335912
URL: http://llvm.org/viewvc/llvm-project?rev=335912&view=rev
Log:
Add a way to load an image using a library name and list of paths.
This provides an efficient (at least on Posix platforms) way to offload to the
target process th
Thanks for fixing this.
Jim
> On Jun 29, 2018, at 2:22 AM, Pavel Labath via lldb-commits
> wrote:
>
> Author: labath
> Date: Fri Jun 29 02:22:07 2018
> New Revision: 335956
>
> URL: http://llvm.org/viewvc/llvm-project?rev=335956&view=rev
> Log:
> Fix TestLoadUsingPaths on linux
>
> we need t
Sure, that also sounds fine.
Jim
> On Jun 29, 2018, at 11:55 AM, Dave Lee via Phabricator
> wrote:
>
> kastiglione added a comment.
>
> Thanks @jingham.
>
>> if the `IOHandlerDelegate` could say whether it wants to be notified for
>> `IOHandlerActivated` when non-interactive (like have a
Author: jingham
Date: Thu Jul 5 16:11:27 2018
New Revision: 336397
URL: http://llvm.org/viewvc/llvm-project?rev=336397&view=rev
Log:
Don't muck with _LIBCPP_INLINE_VISIBILITY just to get predictable line table
entries.
This test was trying to stop at a variety of std::vector calls. It looks li
Author: jingham
Date: Thu Jul 5 16:23:06 2018
New Revision: 336398
URL: http://llvm.org/viewvc/llvm-project?rev=336398&view=rev
Log:
Address a few post facto review comments from Adrian.
Thanks, Adrian!
Modified:
lldb/trunk/include/lldb/Target/Platform.h
lldb/trunk/source/Plugins/Platfo
Author: jingham
Date: Thu Jul 5 17:16:21 2018
New Revision: 336403
URL: http://llvm.org/viewvc/llvm-project?rev=336403&view=rev
Log:
Remove a bunch more references to _LIBCPP_INLINE_VISIBILITY
and adjust the tests that needed it to set their breakpoints more robustly.
Modified:
lldb/trunk
There's code in the ThreadHandler to handle systems with short thread names.
If that isn't producing readable names, we should fix it there. A better
algorithm might be to drop the leading "lldb" and then instead of truncating
drop vowels (maybe leaving the first vowel after a .) So you'd get
Author: jingham
Date: Fri Jul 13 12:24:26 2018
New Revision: 337034
URL: http://llvm.org/viewvc/llvm-project?rev=337034&view=rev
Log:
Add the new PDBLocationToDWARFExpression.{cpp,h} to the Xcode project.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj
Author: jingham
Date: Fri Jul 13 12:28:32 2018
New Revision: 337035
URL: http://llvm.org/viewvc/llvm-project?rev=337035&view=rev
Log:
Fix the libcxx set, multiset, vector and bitset formatters to work on
references.
The synthetic child providers for these classes had a type expression that
matc
Author: jingham
Date: Fri Jul 13 15:31:59 2018
New Revision: 337058
URL: http://llvm.org/viewvc/llvm-project?rev=337058&view=rev
Log:
Make these tests c++ tests so they can be skipped on systems that don't support
those tests.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalit
Author: jingham
Date: Thu Jul 19 18:20:18 2018
New Revision: 337515
URL: http://llvm.org/viewvc/llvm-project?rev=337515&view=rev
Log:
Defend LoadImageUsingPaths against a path list
with empty paths on it.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_using_paths/Te
Author: jingham
Date: Tue Aug 7 14:05:34 2018
New Revision: 339181
URL: http://llvm.org/viewvc/llvm-project?rev=339181&view=rev
Log:
Fix the Xcode project for the Core -> Utility moves.
Scalar.{h,cpp}, RegisterValue.{h,cpp}, State.{h,cpp} were moved.
Modified:
lldb/trunk/lldb.xcodeproj/proj
Author: jingham
Date: Tue Aug 7 14:09:55 2018
New Revision: 339182
URL: http://llvm.org/viewvc/llvm-project?rev=339182&view=rev
Log:
If a function starts with line number 0, don't try to check if a breakpoint
crossed function boundaries.
clang doesn't use line number 0 (to mean artifically gene
It looks like lots of options to debugserver were added without also adding
them to the --help output. Probably because there are so few clients they
already know the options (the same person added & used them...) But if you
look at the actual options in debugserver.cpp, you will see:
{"u
Author: jingham
Date: Wed Aug 15 16:10:32 2018
New Revision: 339833
URL: http://llvm.org/viewvc/llvm-project?rev=339833&view=rev
Log:
Fix a little thinko in generating ___lldb_unnamed_symbol symbols
when we have only an in-memory copy of the binary.
Also added a test for the generation of these
Author: jingham
Date: Fri Aug 17 10:39:32 2018
New Revision: 340053
URL: http://llvm.org/viewvc/llvm-project?rev=340053&view=rev
Log:
Show how to use "lldb -P" to find the lldb.py.
We had hard-coded the path in the docs but that got
out of date - showing again that -P is the better
way to do this.
Author: jingham
Date: Fri Sep 7 11:10:26 2018
New Revision: 341683
URL: http://llvm.org/viewvc/llvm-project?rev=341683&view=rev
Log:
Add input files to the "prepare swig bindings" step.
This build phase had no inputs, so you always had to manually
delete LLDBWrapPython.cpp to get it to rebuild.
Author: jingham
Date: Fri Sep 7 11:43:04 2018
New Revision: 341690
URL: http://llvm.org/viewvc/llvm-project?rev=341690&view=rev
Log:
NFC: Move Searcher::Depth into lldb-enumerations as SearchDepth.
In a subsequent commit, I will need to expose the search depth
to the SB API's, so I'm moving this
Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbutil.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbutil.py?rev=342185&r1=342184&r2=342185&view=diff
==
--- lldb/trunk/pack
Author: jingham
Date: Thu Sep 13 14:35:32 2018
New Revision: 342185
URL: http://llvm.org/viewvc/llvm-project?rev=342185&view=rev
Log:
Add a "scripted" breakpoint type to lldb.
This change allows you to write a new breakpoint type where the
logic for setting breakpoints is determined by a Python c
Author: jingham
Date: Thu Sep 13 14:55:00 2018
New Revision: 342188
URL: http://llvm.org/viewvc/llvm-project?rev=342188&view=rev
Log:
Remember to sort the Xcode project file. NFC.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
___
lldb-commit
Author: jingham
Date: Thu Sep 13 14:59:16 2018
New Revision: 342190
URL: http://llvm.org/viewvc/llvm-project?rev=342190&view=rev
Log:
svn add the new files...
I started from a clean slate to do the checkin, but forgot to svn add the new
files.
Do that now.
Also add the one new source file to CM
Author: jingham
Date: Fri Sep 14 11:41:40 2018
New Revision: 342259
URL: http://llvm.org/viewvc/llvm-project?rev=342259&view=rev
Log:
Make the eSearchDepthFunction searches work, add tests
using the scripted breakpoint resolver.
Differential Revision: https://reviews.llvm.org/D52111
Modified:
Author: jingham
Date: Mon Sep 17 14:55:46 2018
New Revision: 342419
URL: http://llvm.org/viewvc/llvm-project?rev=342419&view=rev
Log:
Add docs for scripted breakpoint resolvers
Differential Revision: https://reviews.llvm.org/D52065
Modified:
lldb/trunk/www/python-reference.html
Modified: ll
I'm not sure we have enough instances to decide on better organization, but
ArchSpec really doesn't feel like a Utility for lldb. That would be like
moving the llvm triple handling to ADT, that seems a little weird. Similarly
having the register stuff in Utility seems odd as well. I would nev
Author: jingham
Date: Thu Nov 16 17:19:59 2017
New Revision: 318495
URL: http://llvm.org/viewvc/llvm-project?rev=318495&view=rev
Log:
"source list -a" was calling DisplaySourceLinesWithNumbers incorrectly.
The parameters were just passed in the wrong order.
Modified:
lldb/trunk/source/Comm
Author: jingham
Date: Thu Nov 16 17:22:34 2017
New Revision: 318496
URL: http://llvm.org/viewvc/llvm-project?rev=318496&view=rev
Log:
Recognize another magic token sent in the LaunchInfo's EventData.
Modified:
lldb/trunk/tools/debugserver/source/MacOSX/MachProcess.mm
Modified: lldb/trunk/t
How would the ObjectFile API's that take or return UUID's work in this case?
Jim
> On Nov 28, 2017, at 11:44 AM, Zachary Turner via lldb-commits
> wrote:
>
> Also worth pointing out that when you write things this way, this UUID
> class can be part of a larger structure that matches the reco
Author: jingham
Date: Tue Nov 28 13:11:15 2017
New Revision: 319226
URL: http://llvm.org/viewvc/llvm-project?rev=319226&view=rev
Log:
Add elf-core/RegisterUtilities.{cpp,h} to the project file.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pb
I'm a little confused by your response.
My stated objection to command output dependent tests is and has always been
that they make the test dependent on the details of command output. Over time
doing so makes it hard to modify command output. This is sort of related to
interactivity, in th
I'm mostly basing this concern on the bad effect this had on gdb all of whose
testing was expect based command scraping. gdb is a tool that's much closer to
lldb than any of the compiler tools so that experience seems relevant. It's
been a decade or so since I worked on gdb, but back when I wa
> On Nov 29, 2017, at 3:46 PM, Zachary Turner wrote:
>
> FWIW, it can certainly use the SB API where it makes sense, but I think
> requiring that it only use the SB API would be very limiting and a big
> mistake.
>
> The entire point of a tool such as this is that it allows you to dig deep
Author: jingham
Date: Wed Nov 29 16:23:42 2017
New Revision: 319389
URL: http://llvm.org/viewvc/llvm-project?rev=319389&view=rev
Log:
Fix the gtest target for the move of ArchSpecTest.cpp from Core to Utility.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xc
I thought we weren't talking about why you want this lldb-test, but rather why
tests that poke deep into the lldb_private API's are or are not appropriate for
your test dingus.
The thing I worry about is if you start using this for very special purpose
"reach deep into the lldb_private API's"
And of course, one such discipline would be "only use SB API's"...
Jim
> On Nov 29, 2017, at 5:00 PM, Jim Ingham wrote:
>
> I thought we weren't talking about why you want this lldb-test, but rather
> why tests that poke deep into the lldb_private API's are or are not
> appropriate for your
Author: jingham
Date: Thu Nov 30 10:35:35 2017
New Revision: 319454
URL: http://llvm.org/viewvc/llvm-project?rev=319454&view=rev
Log:
Remove a long out-of-date comment.
Modified:
lldb/trunk/source/Target/Process.cpp
Modified: lldb/trunk/source/Target/Process.cpp
URL:
http://llvm.org/viewvc/
We had a similar problem with the tests on macOS. lldb has a facility that
will do automatic lookup of UUID -> dSYM (macOS's separate debug info format)
and if you are internal to Apple this will find all the system library debug
info. That will cause a handful of tests to fail, mostly because
This test actually almost succeeds on macOS. The problem is that your
breakpoint in the Foo constructor produces two line table entries so we hit the
foo breakpoint twice. If you change the test file to:
Index:
packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.c
The other way to do this would be to pass num_expected_locations = -1 when you
make the foo breakpoint, and then grab the breakpoint's number of locations and
assume you are going to hit the breakpoint that many times.
But changing the code so that the line you are breaking on is unambiguously o
Author: jingham
Date: Thu Nov 30 12:43:00 2017
New Revision: 319472
URL: http://llvm.org/viewvc/llvm-project?rev=319472&view=rev
Log:
Fix this test so that the breakpoints you set are
unambiguously on one bit of code. On macOS these
lines mapped to two distinct locations, and that
was artificiall
Author: jingham
Date: Thu Nov 30 19:41:30 2017
New Revision: 319516
URL: http://llvm.org/viewvc/llvm-project?rev=319516&view=rev
Log:
ClangASTContext::ParseClassTemplateDecl doesn't always succeed.
When it does, it returns a NULL ClassTemplateDecl. Don't use
it if it is NULL...
Modified:
his failure anyway, so that effort is really orthogonal to
this patch.
Jim
> On Nov 30, 2017, at 9:45 PM, Davide Italiano wrote:
>
> On Thu, Nov 30, 2017 at 7:41 PM, Jim Ingham via lldb-commits
> wrote:
>> Author: jingham
>> Date: Thu Nov 30 19:41:30 2017
>> New
h wrote:
>
> cool. thanks.
>
> On 30 November 2017 at 20:43, Jim Ingham via lldb-commits
> wrote:
>> Author: jingham
>> Date: Thu Nov 30 12:43:00 2017
>> New Revision: 319472
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=319472&view=rev
>
This certainly should be cleared up and centralized. I'm not quite as sure it
should be in Platform however. For instance, macOS has the DebugSymbols
framework that allows users to specify a local lookup tool to find symbol files
given a UUID. That runs only on MacOS and requires MacOS specif
Yes, we don't use llvm code in debugserver. It doesn't actually use any lldb
classes either, it's its own standalone thing.
Jim
> On Dec 1, 2017, at 4:01 PM, Zachary Turner via lldb-commits
> wrote:
>
> I don't recall, is there a hard restriction on debugserver not being allowed
> to use l
If somebody finds themselves ambitious to work on debugserver, they should
divert that energy to porting lldb-server to macOS IMHO.
Jim
> On Dec 1, 2017, at 4:04 PM, Jim Ingham wrote:
>
> Yes, we don't use llvm code in debugserver. It doesn't actually use any lldb
> classes either, it's its
Author: jingham
Date: Fri Dec 1 16:11:18 2017
New Revision: 319598
URL: http://llvm.org/viewvc/llvm-project?rev=319598&view=rev
Log:
Don't use llvm::EnablePrettyStackTrace on macOS.
LLDB.framework gets loaded into Xcode and other
frameworks, and this is inserting a signal handler into
the proce
Yeah, I was not being realistic in saying that.
debugserver has a bunch of junk in it specific to our various embedded
platforms that isn't actually buildable outside of Apple, but which we need
(it's all #ifdef around in the debugserver sources). We aren't going to be
able to do away with thi
resent all I have is a bunch of non-reproducible crash reports, I don't
know why it isn't working.
Jim
>
> On Sat, Dec 2, 2017 at 12:24 PM Davide Italiano wrote:
> Maybe we should remove this feature altogether?
>
> On Fri, Dec 1, 2017 at 4:11 PM, Jim Ingham vi
1 - 100 of 1210 matches
Mail list logo
