> On Aug 2, 2018, at 10:26 AM, Jim Ingham via lldb-dev
> wrote:
>
> I think the better behavior is to try FindLineEntry the first time with exact
> = false. If that picks up a different line from the one given, reset the
> line we are looking for to the found line. In ei
Thanks! I look forward to the patch.
Jim
> On Aug 2, 2018, at 8:56 PM, Venkata Ramanaiah Nalamothu
> wrote:
>
> Thanks Jim for the elaborate reply.
>
> I knew what is happening in below piece of code and also has a patch ready
> but now needs a bit of fine tuning based on your below commen
> On Aug 14, 2018, at 7:48 PM, Zachary Turner via lldb-dev
> wrote:
>
>
> On Tue, Aug 14, 2018 at 6:58 PM Jason Molenda wrote:
>
>
> > On Aug 14, 2018, at 6:39 PM, Zachary Turner wrote:
> >
> > Having bugs also makes the debugger harder to innovate in the future
> > because it’s, not ha
There are a couple of problems with using these reproducers in the testsuite.
The first is that we make no commitments that the a future lldb will implement
the "same" session with the same sequence of gdb-remote packet requests. We
often monkey around with lldb's sequences of requests to make
Yes, I think that would be pretty cool. It is along the same lines we've been
talking about with using "ProcessMock", "ThreadMock" etc. plugins. However, I
think you need both. For instance if we bobble a gdb-remote packet, you will
see that in a bad state of one of these higher level state d
When I am working on some changes and there are tests I know I've broken but
don't want to fix just yet, I just edit the test file and skip it using the
skip decorators. You have to remember not to check in the skips when you check
in whatever change you are making - but presumably by the time
> On Sep 20, 2018, at 4:16 AM, Zachary Turner wrote:
>
> For the first, I think 99% of the time the bug is not caused by the sequence
> of gdb remote packets. The sequence of gdb remote packets just happens to be
> the means by which the debugger was put into the state in which it failed.
The way to do this in the MI interface is with the command: inferior-tty-set.
Unfortunately, that command isn't implemented in the lldb-mi:
bool CMICmdCmdInferiorTtySet::Execute() {
// Do nothing
return MIstatus::success;
}
This should set the target.{input/output/error}-path to the tty it
So in the test scenario, we have this code:
printf("// Set second break point at this line.");
(text_list.push_back(std::string("!!!")));
and we have a breakpoint on the printf line. We've just continued to hit the
breakpoint at printf. Then we do next twice. That should certainly get
> On Oct 8, 2018, at 8:09 AM, Zachary Turner via lldb-dev
> wrote:
>
> I haven't heard of anyone using the Xcode generated project. In fact, LLDB
> maintains its own hand-created Xcode project precisely because the CMake one
> is considered "unusable". That said, I don't personally use Xco
A single sequence in the line table needs to be run from beginning to end to
make sense of it. It doesn't really have addresses, it generally has a start
address, then a sequence of "increment line, increment address" instructions.
So you have to run the state machine to figure out what the ad
I've had requests from several users now to change the default SIGPIPE handling
to "stop = false, notify = false". The argument is that most of the time these
signals are generally ignored and folks directly handle the read and write
errors. So having lldb stop by default for SIGPIPE is just a
said this test inadvertently showed itself a good
test for stepping, as well as being a test for data formatting. So we should
extract the part that proved its worth in catching stepping bugs into a
stepping-only test, and then rewrite the data formatter test so it wasn't
reliant on stepping behavio
Thanks for looking into this!
When I was first working on inlined stepping, I found a bunch of cases where
the line table info and the ranges for the inlined subroutines disagreed. I
remember seeing cases, for instance, where the address given for foo.h:xxx in
the line table was contained in
The data formatters don't currently have a specified language. We should
maybe add that and then we could only load formatters for a language when its
runtime gets loaded. Then they could also know to turn themselves on and off
based on the language of the current frame, or of the current exp
Remove the "not"...
Jim
> On Oct 26, 2018, at 10:24 AM, Jim Ingham wrote:
>
> But at the minimum, not loading formatters for a language that we can
> determine isn't used in this program seems like something we should try to
> avoid.
___
lldb-dev m
Most C++ classes and C structs don't have data formatters, particularly not
classes that you write yourself.
The way value printing works in lldb is that we start by making the ValueObject
for the value from its Type, so at that stage it is just a direct view of the
members of the object. Th
We need to do more work to make sure the "language" setting for expressions
gets propagated everywhere and obeyed. We could also be smarter about setting
the default.
It seems fine to me for lldb to assume - if we know nothing different - that we
should use ObjC++ as the language to compile ex
lldb has one feature - the "Operating System Plugin" that is specifically
designed for debugging threads in kernel contexts. The OS plugin allows a
kernel to present it's notion of threads into lldb_private::Threads. The xnu
kernel macros have an implementation of this, as do some other embedd
Right now, the OS plugin only supports the job of adding threads. And that
makes more sense as a plugin, because for instance if you had a cooperative
threading scheme that you were laying on top of the system threads in a User
Space process, you can use the Operating System plugin to show you
e place to put that functionality.
Jim
> On Oct 31, 2018, at 4:05 PM, Jim Ingham via lldb-dev
> wrote:
>
> Right now, the OS plugin only supports the job of adding threads. And that
> makes more sense as a plugin, because for instance if you had a cooperative
> threading sc
the place to put that functionality.
>
> Jim
>
>
> > On Oct 31, 2018, at 4:05 PM, Jim Ingham via lldb-dev
> > mailto:lldb-dev@lists.llvm.org>> wrote:
> >
> > Right now, the OS plugin only supports the job of adding threads. And that
> > mak
lldb finds the symbol you asked for in the elf file's symbols, and makes a
"location" for that address in that binary (as a section-relative address).
But that won't help it actually SET the breakpoint, since that doesn't tell us
where that section will end up in the executable image when it ru
> On Nov 8, 2018, at 11:18 AM, Adrian Harris wrote:
>
> Thanks Jim - that makes sense for the types of targets that lldb interacts
> with mostly.
>
> In my particular case, nothing is getting 'launched' - rather I'm attaching
> to an already running target. The elf that I'm pointing to is an
ate threads that are doing work
>> on behalf of some queue with the state of the thread that enqueued the work
>> at the time the work item was enqueued.
>>
>> If for instance you had a way to gather all the locks in the process
>> (something we've b
lldb does have an affordance for synthetic threads, but at present, those have
to be memory threads, and once you have the 0th frame, they are backtraced just
like ordinary threads. So they are a start but don't provide a way to make up
synthetic frames within a thread. So I don't think that t
You will need to add ABI support. You'll also need to make an Unwinder that
works for your platform. But the thread plan code is pretty generic and relies
on the Unwinder and generic features of the Disassembler (mostly "IsBranch") to
do its job. For instance, thread step-out just asks the Un
Ah, that’s right, we did it in debugserver as well. Apple used to have a
disassembly framework that we used for the purpose (separate from llvm). But
that’s long gone.
Jim
> On Nov 29, 2018, at 1:22 AM, Pavel Labath wrote:
>
> On 28/11/2018 21:05, Jim Ingham via lldb-dev wrot
I agree with Davide. Particularly if there’s code that is relying on the
“IsExactMatch” not behaving like the function name makes clear it obviously
should behave, we should straighten that out. Otherwise reasoning about this
will be too confusing.
Jim
> On Dec 6, 2018, at 3:26 PM, Davide I
The ObjectFileBreakpad change (r348592) first got tested on the bot for:
http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/13712/
and immediately TestFunctionStarts started failing.
You probably didn't get a mail because the previous test run failed with one of
these "concurrent signal" t
You would use an operating system plugin in cases where the underlying process
interface doesn't tell the complete story for the OS threads. For instance, a
lot of kernel and bare board OS'es have a gdb-remote stub that just describes
the state of the threads currently running on the cores of t
Even if it was the keyboard handler, lldb feeds characters to edit line through
the IO Handler, so it should be possible to emulate the up arrow as well. If
there are reasons why that's not feasible, we should be able to make it work.
This seems a tractable problem to me, and to me seems a bet
I don't think anybody uses these tests. They are all time based benchmarks,
and in the end there was just too much variability for them to be really
useful. We really need to do more work tracking performance, but I think a
better approach is to focus on how much work we do (how many DIE's did
> On Jan 31, 2019, at 10:42 AM, Pavel Labath via lldb-dev
> wrote:
>
> On 31/01/2019 19:26, Zachary Turner wrote:
>> Was the test failing specifically in the keyboard handler for up arrow, or
>> was it failing in the command history searching code? Because if it's the
>> latter, then we cou
All SBValues have an error in them (SBValue.GetError). Does that say anything
interesting?
Jim
> On Feb 14, 2019, at 10:08 AM, Alexander Polyakov via lldb-dev
> wrote:
>
> Hi lldb-dev,
>
> I work on a custom implementation of OperatingSystem plugin using Python and
> SB API. I’m tryin
That’s a little complicated…
lldb has two levels of stop state - private stops and public stops. When the
process gets notification from the underlying process plugin that the process
stopped, it raises a private stop event. That gets handled by the ShouldStop
mechanism on the private state
The simplest thing possible to reproduce the failure. So some OS_Plugin
implementation which tries to look up a global like this and fails, and some
program source I can run it under that provides said global. That way I can
easily watch it fails as you describe when the plugin gets activated,
Your plugin should have set the private state to stopped when it figures out
however it does that the process has stopped. The API is
Process::SetPrivateState. Is that happening at the right time?
Jim
> On Feb 14, 2019, at 1:50 PM, Alexander Polyakov
> wrote:
>
> I found out that the plug
> On Feb 21, 2019, at 11:22 AM, Tatyana Krasnukha via lldb-dev
> wrote:
>
> > lldb Process::SetPrivateState (stopped) stop_id = 2
> > error: error: process must be stopped.
>
> These two lines are printed from different threads, you cannot be sure the
> real order of execution i
What's triggering one of the OS Plugin methods to get run on this separate
thread? I would expect SetPrivateState would just cause the private stop event
to get broadcast to the private state thread, and then that would wake up and
then it would be the one to call the OS Plugin to do it's job.
Even though you can just use debugserver/lldb-server and debug remotely, many
people find it handy to be able to run a debugger directly on the device they
are using. But requiring that you port Python and bundle it with your embedded
platform just to get a debugger there is a pretty big ask.
> On Mar 7, 2019, at 11:37 AM, Zachary Turner wrote:
>
>
>
> On Thu, Mar 7, 2019 at 11:03 AM Jim Ingham via lldb-dev
> wrote:
> Even though you can just use debugserver/lldb-server and debug remotely, many
> people find it handy to be able to run a debugger dir
Seems like there are two kinds of DEBUG_PRINTF.
One is in SymbolFileDWARF, DWARFASTParserClang.cpp etc, where that is inserting
code into lldb. Those uses seem to me like they should be going to the dwarf
log channel when verbose is on. Many of these places also acquire the dwarf
log, so th
If you have a library that has a version number of 0.0.0,
uint32_t SBModule::GetVersion(uint32_t *versions, uint32_t num_versions)
will return a result of 2 (which is the number of elements it put into
num_versions) and the two elements it actually stuffed into the versions array
will be {UIN
> On Mar 28, 2019, at 3:03 AM, Pavel Labath wrote:
>
> On 28/03/2019 01:36, Jim Ingham wrote:
>> If you have a library that has a version number of 0.0.0,
>> uint32_t SBModule::GetVersion(uint32_t *versions, uint32_t num_versions)
>> will return a result of 2 (which is the number of elements it
Dereference returns another SBValue distinct from the initial one, so it needs
to make up a name for it. I think it would be confusing for it to return the
same name, and putting a * at the beginning of the initial SBValue seems as
good a choice as any.
Is this causing you some concrete proble
What are you using the name for? If the name of an SBValue is the name of a
variable, then it makes sense (at least in C languages) for the name of the
dereference Value to be "*VARNAME". After all that's what it is. If the name
is some other random string, I'm not sure anything would be bett
Independent of the naming issue, if you have an address and want to view its
pointee as a given type, CreateValueFromAddress is much more efficient than
CreateValueFromExpression. After all, CreateValueFromAddress just reads some
memory and presents it as the given type, rather than having to p
If you want to undertake such a thing, that would be great. The other fairly
complex OS plugin that exists in the wild is the one that ships with the Darwin
Kernel Debug Kit. You can get this from
http://developer.apple.com/download/more - you need a free ADC account to get
this, though if th
The os plugin in the KDK's is just a packaged up version of what's in the link
you referenced, so the KDK wouldn't add anything.
Jim
> On Apr 17, 2019, at 12:50 PM, Alexander Polyakov
> wrote:
>
> It seems that I need a Apple ID to create an account, can you please share
> the code?
>
> I
> On Apr 22, 2019, at 10:59 AM, Ted Woodward via lldb-dev
> wrote:
>
> The new LLDB website at http://lldb.llvm.org has an external resources page:
> http://lldb.llvm.org/resources/external.html
>
> It has 2 entries on it for Documentation:
> https://lldb.llvm.org/python_reference/index.html
Well, you can probably look at the copy in the sources (www/index.html & so
forth). But we do need to get this fixed as external folks who don't have a
checkout do rely on this.
Jim
> On Apr 22, 2019, at 11:37 AM, Ted Woodward wrote:
>
> Great, thanks Jim. Glad to see people are already on
This commit makes things look a little cleaner, but do we need any of these
forward declarations at all?
Most of these files either directly include lldb-forward.h or get it from
lldb-types.h or lldb-defines.h (which includes lldb-types.h). As a general
practice we've been getting all the ll
the incremental rebuild time after touching a file.
> This seems significant. :)
>
> -eric
>
> On Wed, May 15, 2019 at 10:49 AM Jim Ingham via lldb-dev
> wrote:
>>
>> This commit makes things look a little cleaner, but do we need any of these
>> forward dec
elp both compile time and understanding
>> what's used in any particular header.
>>
>> As a related exercise:
>>
>> https://twitter.com/echristo/status/1116609586004316160
>>
>> basically has removing a couple of transitive dependencies saving in
>
t;> included into an array of translation units
>>> b) Having each file contain the forward declarations it needs from the
>>> project and no more also will help both compile time and understanding
>>> what's used in any particular header.
>>>
>>> As
> On May 16, 2019, at 2:24 AM, Pavel Labath wrote:
>
> On 16/05/2019 01:10, Jim Ingham via lldb-dev wrote:
>> When you add to them you are often adding some larger feature which would
>> have required a rebuild anyway, and they go long times with no change... I
&g
By default, the SB API's run in "asynchronous" mode, where calls that cause the
target to run (launch, continue, etc) return when the target has started
running, and then you have to wait on the listener that you registered with the
process when you launched it to get notified of state changes.
Stop hooks only trigger when control is about to be returned to the user. And
in its normal mode, lldb doesn't step instruction all the time anyway... So I
don't think they would do what Vangelis wants. He would have to drive the
debugger with only the step-instruction command, which I think
We use http://reviews.llvm.org
Click on the Favorites:Differential side bar item, and then on Create Diff in
the URH Corner of the window. If you make your diff with:
svn diff --diff-cmd=diff -x -U99
or the git equivalent, then they are much easier to review. Once you have the
diff, sele
There isn't a general mechanism for external clients to watch settings changes.
But IMO, it would be appropriate for the setter for the
target.process.thread.trace-thread set function to go do this work. Having an
explicit relationship between setting the setting and changing state in the
thr
> On Jul 2, 2019, at 11:52 AM, Vangelis Tsiatsianas
> wrote:
>
> I would like to leave it as a suggestion for the future, just in case the
> need for such a mechanism arises in other places within LLDB or for plugins.
File an enhancement request with bugs.llvm.org, otherwise it will get lost
Are any sources for symbols getting added to the process as you go along, like
new shared library loads? You are asking for a non-existent name, so every new
source of debug info is a new place to look.
It's also possible that we are completing some types during the course of the
expression ev
It looks like you don't have a DynamicLoader plugin that tells lldb where your
binaries ended up in memory when the process ran. The [ADDRESS] means we are
reading instructions from memory not from the on-disk binary.
Jim
> On Jul 9, 2019, at 2:14 AM, Romaric Jodin via lldb-dev
> wrote:
>
lldb realizes types from DWARF lazily. So for instance, if an expression
refers to a pointer to type Foo, we won't necessarily realize the full type of
Foo from DWARF to parse that expression. Then if you write a second expression
that accesses a member of an object of type Foo, we will realiz
A "raw image" is one that loads all the code at some address and doesn't have a
dynamic loading mechanism. So it really just means "a binary that doesn't use
a dynamic loader." I'm not sure why it was called "Strata"...
But the Strata is used to disambiguate cases where the object file format
The main problem with trying to run a debug session multithreaded is
coordinating execution control. Thread A gets a variable list and iterates
over it to get child values. Thread B issues a "step" command. The API's
thread A calls will either fail (because the target is running) or maybe fet
Fernando, I don't see quite what you do. For me, -Q never sets the queue.
Rather, the current Xcode version of lldb seems to have a bug where it doesn't
reject illegal options, so the -Q argument is silently discarded. That would
cause the breakpoint to "work" but it won't only stop on one qu
I already filed both of these issues with Apple. If you want to file them too,
feel free. I'll dup them to the ones I filed but that way you will get
notification when they get fixed. These are also general lldb issues, so it
would be good to file something with http://bugs.llvm.org.
Jim
>
lldb can't currently create new template instantiations. It can only access
ones that were generated in the binary you were debugging. The debug
information doesn't have any code, so we can't create new instantiations from
there. Having the debugger try to include headers into the expression
Interesting... What lldb & clang were you using? With current TOT clang &
lldb I see:
(lldb) run
Process 83732 launched: '/tmp/template2' (x86_64)
Process 83732 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010fad template2`main at
> On Jul 24, 2019, at 7:23 AM, Scott Funkenhauser
> wrote:
>
> I've tried with LLVM 4, 7 and 8. They all fail to evaluate 'sizeof(foo)'.
>
The fundamental problem is that DWARF doesn't represent templates per se. It
only represents template instantiations. So there's nothing in the debug
Amplifying Fred's comments:
Most of the code in ParseSymtab is parsing the nlist records in the binary.
Only a tiny subset of those nlist records are "stabs". Most are just the
format by which MachO expresses its symbol table. So all that needs to be
there.
Over the past couple of years, th
Is this in the on-line docs somewhere?
Jim
> On Aug 8, 2019, at 12:49 PM, Jonas Devlieghere via lldb-dev
> wrote:
>
> Hey Ted,
>
> 1. You can run just the dotest-tests by pointing lit at the
> `lit/Suite` directory.
> 2. You can pass arguments to dotest by passing `dotest-args` in --param.
>
IIUC an llvm::Expected is only supposed to abort if you leave its scope with an
un-consumed error. LLDB_LOG_ERROR is supposed to consume the error - the code
looks like it is doing that. So if you are still seeing an abort when there's
an error, then it sounds like something is wrong with LLDB
> On Aug 14, 2019, at 1:41 PM, Adrian Prantl via lldb-dev
> wrote:
>
>
>
>> On Aug 14, 2019, at 11:26 AM, Adrian McCarthy via lldb-dev
>> wrote:
>>
>> A recent change is causing several LLDB tests on Windows to fail and several
>> more to time out, which I intend to look into.
>>
>> It
I don't know where the windows bot output is...
Which tests are timing out?
Maybe you ought to skip those tests on Windows for now to reduce the noise?
Jim
> On Aug 14, 2019, at 4:14 PM, Adrian McCarthy wrote:
>
>
>
> On Wed, Aug 14, 2019 at 2:47 PM Jim Ingham wrote:
>
>
> > On Aug
Thanks for your great comments. A few replies...
> On Aug 15, 2019, at 10:10 AM, Pavel Labath via lldb-dev
> wrote:
>
> Hello Ismail, and wellcome to LLDB. You have a very interesting (and not
> entirely trivial) project, and I wish you the best of luck in your work. I
> think this will be a
> On Aug 15, 2019, at 11:55 AM, Pavel Labath wrote:
>
> On 15/08/2019 20:15, Jim Ingham wrote:
>> Thanks for your great comments. A few replies...
>>> On Aug 15, 2019, at 10:10 AM, Pavel Labath via lldb-dev
>>> wrote:
>>> I am wondering whether we really need to involve the memory allocation
> On Aug 20, 2019, at 3:30 AM, Tamas Berghammer via lldb-dev
> wrote:
>
> It is great that you are looking at supporting these fast breakpoints
> but I am concerned about the instruction moving code along the same
> lines Pavel mentioned. Copying instructions from 1 location to another
> is fa
From what I can tell the main thing this is missing is a Console window. I
imagine hosting a full console window inside a ncurses sub window would be a
pain if there isn't a pre-built widget for that. But maybe it would be easier
to open another terminal window and connect the debuggers I/O ch
The GUI is built into lldb, it is not a separate entity.
Jim
> On Aug 26, 2019, at 12:39 PM, René J.V. Bertin via lldb-dev
> wrote:
>
> On Monday August 26 2019 11:18:28 Raphael “Teemperor” Isemann via lldb-dev
> wrote:
>
>>> On 25. Aug 2019, at 02:02, Greg Clayton via lldb-dev
>>> wrote:
You would need to implement an ObjectFile and SymbolFile plugin for your .wasm
files for lldb to make a Target for them.
Jim
> On Aug 26, 2019, at 6:27 PM, Terry Guo via lldb-dev
> wrote:
>
> Hi Raphael,
>
> Thanks for your recommendation. How about the very first step which
> enables LLDB
If I have a program like:
class A {
public:
int AMethod() { return 100; }
};
class AA {
public:
int AMethod() { return 200; }
};
int
main()
{
A myA;
AA myAA;
myA.AMethod();
myAA.AMethod();
return 0;
}
Build and run it under lldb, and do:
(lldb) b s -n A::AMethod
Breakpoint 1: 2 l
lldb doesn’t currently support breakpoint callbacks that try to control running
the target in the callback. I’m not sure how easy it would be to support that
reliably, but anyway, that doesn’t work at present.
My model for this sort of tracing activity is that you are writing a fancy kind
of “
At some point it would be good to add trampoline support at the Python level.
You can produce scripted thread plans now - and the trampoline mechanism just
returns a thread plan to step through the trampoline... It would be neat to be
able to support other systems without having to build them
> On Sep 21, 2019, at 11:11 AM, Nikita Karetnikov wrote:
>
> Jim,
>
> > My model for this sort of tracing activity is that you are writing a fancy
> > kind
> > of “step” operation. You would write a fancy step & record plan that would
> > proceed along however you wanted and log at each stop
We've had many requests to elide some classes of entries in backtraces - like
to mirror the Xcode display I mentioned previously. Most of these requests
don't depend on the functions being marked artificial. So if we're going to do
this, something more general than just "marked artificial" ->
> On Sep 24, 2019, at 11:36 AM, Nat! via lldb-dev
> wrote:
>
>
>
> On 24.09.19 19:28, Jim Ingham wrote:
>> We've had many requests to elide some classes of entries in backtraces -
>> like to mirror the Xcode display I mentioned previously. Most of these
>> requests don't depend on the fun
he ways to decide a frame should be elided. But
that should just be one pattern we look for, not the way we implement the
feature.
Jim
> On Sep 25, 2019, at 5:51 AM, paul.robin...@sony.com wrote:
>
>
>
>> -Original Message-
>> From: lldb-dev [mailto:lldb-dev-boun
Right. If you watch the lazy binding that happens the first time a symbol is
called - at least on macOS - the loader does a lot of work, and calls various
standard library functions and helper functions in its own library that aren't
in any real sense trampolines. Actually, objc_msgSend can do
Nikita,
There was a lot of other stuff in that scripted_step.py beyond the plan class
itself. I didn't follow what that did altogether. But if I removed all that
stuff, and changed your plan slightly to not rely on the global TARGET and
START_ADDRESS (I attached my simplified version below),
So the problem you are having is getting the scripted step started in "trace"
with the SBThread::StepUsingScriptedStep? Did you try passing False for
"resume_immediately" and then returning False from "trace".
The explanation for:
# XXX: Doesn't seem to matter with 'thread step-scripted
> On Sep 30, 2019, at 5:05 PM, Peter Rowat via lldb-dev
> wrote:
>
> I have a process P1 that forks a child process P2. Both have graphic
> displays, P2 is an animation depending on data from P1.
> P2 suddenly disappears at a time that is never the same as any previous run.
>
> I use lldb to
> On Oct 1, 2019, at 11:54 AM, Vadim Chugunov via lldb-dev
> wrote:
>
> > Unless my memory is failing me, I don't think we ever explicitly
> > rejected Rust's language plugin. We removed a few other language
> > plugins (Go, Java) that were not maintained and were becoming an
> > increasing bu
> On Oct 7, 2019, at 3:35 AM, Raphael “Teemperor” Isemann via lldb-dev
> wrote:
>
> To my knowledge there is no way to have completions for custom commands. If
> you just want completions for nested commands (e.g., having a “custom add”
> and “custom remove” commands and want completions for
Hi, all...
Saleem submitted a patch to work around some other changes in llvm cmakery that
was making LLVM_DEFAULT_TARGET_TRIPLE undefined when lldb went to use it for
the macOS debugserver build.
That was:
commit 55eec2ba96bd9c19ccb5d4d13cb8c88d4abcebc6
Author: Saleem Abdulrasool
Date: Tue
Except of course without the comment markers...
> On Oct 30, 2019, at 11:36 AM, Jim Ingham wrote:
>
> Anyway, another way to do this would be something like:
>
> #if (${LLVM_DEFAULT_TARGET_TRIPLE})
> string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH
> "${LLVM_DEFAULT_TARGET_TRIPLE}")
> #else(
64-apple-darwin. I'm not
> sure what the exact triples are :-)
>
> When we build Hexagon tools, LLVM_DEFAULT_TARGET_TRIPLE, LLVM_TARGET_ARCH and
> TARGET_TRIPLE are hexagon-unknown--elf. LLVM_HOST_TRIPLE is either
> x86_64-unknown-linux or x86_64-pc-windows.
>
>> ---
It looks like this change is causing problems with swift. I was talking a
little bit with Davide about this and it seems like it wasn't obvious how this
was designed to work. So here's what this was intended to do (apologies if
this is at too basic a level and the issue was something deeper I
301 - 400 of 483 matches
Mail list logo
