It sounds like we need to get someone from the Foundation (chandlerc@,
lattner@, tanya@, someone else?) to reach out to them offline about this.
On Wed, Mar 20, 2019 at 11:23 AM Arthur O'Dwyer
wrote:
> On Wed, Mar 20, 2019 at 2:19 PM Tom Stellard via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
On Tue, Mar 19, 2019 at 12:00 PM Tom Stellard via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi,
>
> I would like to follow up on the previous thread[1], where there was a
> consensus
> to disallow merge commits in the llvm github repository, and start a
> discussion
> about how we should enforc
te DWARF, "tuned" for LLDB. Clang
> understands three "debugger tunings" which are gdb, lldb, and sce. The
> distinctions are minor and not relevant here.
>
> --paulr
>
>
>
>
>
> *From:* lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] *On Behalf Of
Two things stand out to me as odd here.
1) -glldb. -g is supposed to specify the debug information format, either
dwarf, codeview, or whichever is the default. I've never heard of anyone
using -glldb (or for that matter -ggdb). Just -g, -gcodeview, or -gdwarf.
2) You're using clang instead of
Apparently we have a macro called DEBUG_PRINTF() which, if you compile LLDB
with a special pre-processor setting enabled, will cause certain messages
to be printed to stdout while running LLDB.
Does anyone use this? This seems like a kind of hacky alternative to
tracepoints and/or pretty printers
This seems reasonable to me. It's worth pointing out though that in
regards to the last comment "IMO it's good to make this lldb-vscode more
general so that it can be used by other debugger frontends besides vscode",
despite the name lldb-vscode, there is actually nothing here that is
specific to
ay (which again, appears to not fully work).
If we can go this route, it makes merging the two DWARF parsing
implementations quite a bit simpler
On Mon, Mar 11, 2019 at 3:33 PM Adrian Prantl wrote:
>
>
> > On Mar 11, 2019, at 12:45 PM, Zachary Turner via lldb-dev <
> lldb-dev@list
in a local branch while waiting to see if
anyone else has any input.
On Mon, Mar 11, 2019 at 1:25 PM Jan Kratochvil
wrote:
> On Mon, 11 Mar 2019 20:45:48 +0100, Zachary Turner via lldb-dev wrote:
> > I want to ask what the status of DWARF64 in LLDB is.
>
> IMO there isn't as for
I want to ask what the status of DWARF64 in LLDB is. I can tell there's
some support for it by reading the code, but it seems to have zero test
coverage so it's not clear to me that anyone depends on it. For example, I
know that clang and LLVM will not even generate DWARF64, so if anyone is
depen
It's been a long time coming and a lot of work to get here, but Host is now
dependency free. While this may not be enforced in the Xcode project
(unless someone changes it to not link against any other libraries /
targets), as of r355730 this is enforced in the CMake build, so if new
dependencies
Yes, Pavel pointed out one specific case where it is used, and that case
definitely needs to be supported.
We've talked in the past about fixing the layering in such a way that all
Python related code is in ScriptInterpreterPython, but there's definitely a
non-trivial amount of work needed to make
Does lldb-server for Android currently use this flag? I was under the
impression it just linked against Python anyway.
On Thu, Mar 7, 2019 at 11:50 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> On 07/03/2019 20:29, Davide Italiano via lldb-dev wrote:
> > I'm in favor of this.
On Thu, Mar 7, 2019 at 11:03 AM Jim Ingham via lldb-dev <
lldb-dev@lists.llvm.org> 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 directly on the
> device they are using. But requiring that you port Python
On Mon, Mar 4, 2019 at 10:32 AM Zachary Turner wrote:
> On Sat, Mar 2, 2019 at 2:56 PM Adrian Prantl wrote:
>
>>
>>- It becomes testable as an independent component, because you can
>>just send requests to it and dump the results and see if they make sense.
>>Currently there is almos
Well, all of the actual yamlization code in obj2yaml and yaml2obj is
library-ized, so you could always add the real code there, then have
core2yaml just link against it
On Wed, Mar 6, 2019 at 5:11 AM Pavel Labath wrote:
> On 05/03/2019 22:52, Zachary Turner wrote:
> >
> >
> > On Tue, Mar 5, 2019
On Tue, Mar 5, 2019 at 1:47 PM Jonas Devlieghere via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
> I don't know much about the minidump format or code, but it sounds
> reasonable for me to have support for it in yaml2obj, which would be a
> sufficient motivation to have the code live there. As yo
On Sat, Mar 2, 2019 at 2:56 PM Adrian Prantl wrote:
>
> On Feb 25, 2019, at 10:21 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi all,
>
> We've got some internal efforts in progress, and one of those would
> benefit from debu
On Wed, Feb 27, 2019 at 4:35 PM Frédéric Riss wrote:
>
> On Feb 27, 2019, at 3:14 PM, Zachary Turner wrote:
>
>
>
> On Wed, Feb 27, 2019 at 2:52 PM Frédéric Riss wrote:
>
>> On Feb 27, 2019, at 10:12 AM, Zachary Turner wrote:
>>
>>
>>
>> For what it's worth, in an earlier message I mentioned t
On Wed, Feb 27, 2019 at 2:52 PM Frédéric Riss wrote:
> On Feb 27, 2019, at 10:12 AM, Zachary Turner wrote:
>
>
>
> For what it's worth, in an earlier message I mentioned that I would
> probably build the server by using mostly code from LLVM, and making sure
> that it supported the union of thin
GSYM, as I understand it, is basically just an evolution of Breakpad
symbols. It doesn't contain full fidelity debug information (type
information, function parameters, etc).
On Tue, Feb 26, 2019 at 5:56 PM wrote:
> When I see this "parsing DWARF and turning it into something else" it is
> very
On Tue, Feb 26, 2019 at 5:39 PM Frédéric Riss wrote:
>
> On Feb 26, 2019, at 4:52 PM, Zachary Turner wrote:
>
>
>
> On Tue, Feb 26, 2019 at 4:49 PM Frédéric Riss wrote:
>
>>
>> On Feb 26, 2019, at 4:03 PM, Zachary Turner wrote:
>>
>> I would probably build the server by using mostly code from
On Tue, Feb 26, 2019 at 4:49 PM Frédéric Riss wrote:
>
> On Feb 26, 2019, at 4:03 PM, Zachary Turner wrote:
>
> I would probably build the server by using mostly code from LLVM. Since
> it would contain all of the low level debug info parsing libraries, i would
> expect that all knowledge of de
path and switch
everything to the out of process server, even if that server were running
on the same physical machine as the debugger client (which would be
functionally equivalent to what we have today).
On Tue, Feb 26, 2019 at 3:46 PM Frédéric Riss wrote:
>
> On Feb 25, 2019, at 10:21 AM, Zachar
Hi all,
We've got some internal efforts in progress, and one of those would benefit
from debug info parsing being out of process (independently of whether or
not the rest of LLDB is out of process).
There's a couple of advantages to this, which I'll enumerate here:
- It improves one source of
It's worth mentioning that pexpect is basically unusable on Windows, so
there's still that.
On Thu, Jan 31, 2019 at 11:40 AM Pavel Labath wrote:
> On 31/01/2019 19:51, Zachary Turner wrote:
> > FileCheck the ansi escape codes seems like one possibility.
> >
> > In general I think you don't ac
FileCheck the ansi escape codes seems like one possibility.
In general I think you don't actually need to test true interactivity,
because the odds of there being a problem in the 2-3 lines of code that
convert the keyboard press to something else in LLDB are very unlikely to
be problematic, and t
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 could have a command which searches the command history.
On Thu, Jan 31, 2019 at 10:23 AM Davide Italiano via lldb-dev <
lldb-dev@li
This would be great. All of these tests have always been disabled on
Windows so converting them to lit tests would increase test coverage there
as well
On Wed, Jan 30, 2019 at 6:00 PM Alex Langford via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> +1
>
> Thanks for bringing this up. I'd like to see
Can you try clang-cl.exe /Z7 main.cpp instead of a clang.exe command line?
On Wed, Jan 16, 2019 at 10:56 PM Christoph Baumann via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hey,
>
> I wrote a simple hello-world program to test lldb on windows:
>
>
>
> #include
>
> in
I own this one: lldb-x86-windows-msvc2015
It can be removed, especially now that Stella's is strictly better than
mine was even when it was working.
There will probably be an effort on our side to get the Linux bots up and
running again "soon", but I don't have an exact timeline right now.
On Fr
The Native PDB symbol file plugin I think is mostly complete. It's at
least almost as good as the old Windows-only PDB plugin in 90% of ways,
while actually being significantly better in other ways (for example, there
was a test that took over 2 minutes to run with the Windows-only PDB
plugin, whi
I'd be curious to see if the PID of the process that is failed to attach to
is the same as one of the PIDs of a process that was previously attached to
(and if so, if it is the first such case where a PID is recycled).
On Sat, Jan 5, 2019 at 4:42 AM Florian Weimer via lldb-dev <
lldb-dev@lists.llv
It seems like we have 3 uses of this constructor in LLDB.
IRInterpreter.cpp: Constructs a Scalar for an llvm::Constant.
IRForTarget.cpp: Constructs a Scalar for an llvm::Constant.
ClangASTContext.cpp: bitcasts an APFloat to an APInt.
The first two we should just treat constants in LLVM IR as sig
On Fri, Jan 4, 2019 at 3:23 PM Jonas Devlieghere
wrote:
> On Fri, Jan 4, 2019 at 3:13 PM Zachary Turner wrote:
>
>> I don't think #2 is a correct change. Just because the sign bit is set
>> doesn't mean it's signed. Is the 4-byte value 0x1000 signed or
>> unsigned? It's a trick question,
I don't think #2 is a correct change. Just because the sign bit is set
doesn't mean it's signed. Is the 4-byte value 0x1000 signed or
unsigned? It's a trick question, because there's not enough information!
If it was written "int x = 0x1000" then it's signed (and negative). If
it was wr
mm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
>
>
>
> *From:* lldb-dev *On Behalf Of *Zachary
> Turner via lldb-dev
> *Sent:* Friday, December 7, 2018 4:38 AM
> *To:* Pavel Labath
> *Cc:* LLDB
> *Subject:* Re: [lldb-d
We can already say that with OSType::Unknown. That’s different than “i know
that no OS exists”
On Fri, Dec 7, 2018 at 12:00 AM Pavel Labath wrote:
> On 07/12/2018 01:22, Jason Molenda via lldb-dev wrote:
> > Oh sorry I missed that. Yes, I think a value added to the OSType for
> NoOS or something
That's what I mean though, perhaps we could add a value to the OSType
enumeration like BareMetal or None to explicitly represent this. the
SubArchType enum has NoSubArch, so it's not without precedent. As long as
you can express it in the triple format, the problem goes away.
On Thu, Dec 6, 2018
Is there some reason we can’t define vendors, environments, arches, and
oses for all supported use cases? That way “there is no os” would not ever
be a thing.
On Thu, Dec 6, 2018 at 3:37 PM Jason Molenda via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I think the confusing thing is when "unspecif
at 9:12 PM Jonas Devlieghere
wrote:
>
>
> On Tue, Dec 4, 2018 at 19:11 Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Have you tried an strace to see if it tells you who is sending the signal?
>
>
> I used DTrace with the default ki
Have you tried an strace to see if it tells you who is sending the signal?
On Tue, Dec 4, 2018 at 6:49 PM Jonas Devlieghere via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi everyone,
>
> Since we switched to lit as the test driver we've been seeing it getting
> killed as the result of a SIGHUP
On Tue, Nov 20, 2018 at 8:51 AM Alexandru Croitor via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
> I would appreciate, if someone could point me to some relevant code that
> does something similar to what I'm asking, so I could use it as a base
> point for exploration.
>
> Many thanks.
Not sur
One of the issues we've faced a couple of times (and will continue to face)
is that lit is generally built around substitutions and command lines, but
different compilers will generally have different substitutions, and worse
-- different command line syntaxes.
The most recent example of this is t
I tried to run this command:
(lldb) target variable "std::numeric_limits::max_exponent"
In Variable.cpp:386 we run a regex against the input string which results
in the above string being cut down to just `std::numeric_limits`. So then
I search my debug info and don't find anything.
What I need
I had considered a libraries/Backends:Other as well that would be separate
from libraries/Other
On Fri, Nov 9, 2018 at 11:20 AM Derek Schuff wrote:
> I wonder if backends are a special case to the heuristic of "let's not
> make a bug component for code components that are too small". LLVM is
>
To elaborate, I didn't mean to group all components with less than 10 bugs
into one massive component. Rather, to do it separately for each
subcomponent. Grouping by expertise is fine, but I would argue that a
component with 2 or 3 bugs filed per year is not a very useful component.
There has to
Just so I'm clear, are we going to attempt to clean up and/or merge the
components? If we are, it makes sense to do that before we start putting
ourselves as default CC's on the various components since they will just
change. If not, it would be nice to get some clarification on that now.
I've p
I don’t totally agree with this. I think there are a lot of useful os
awareness tasks in user mode. For example, you’re debugging a deadlock and
want to understand the state of other mutexes, who owns them, etc. or you
want to examine open file descriptors. In the case of a heap corruption you
may
I can tell you that in LLDB we already do get CC'ed on the list for every
bug. I will grant you that the volume of bugs in LLDB is much lower than
other lists, but I find it very helpful. It gives visibility to bugs that
would otherwise be seen by nobody.
On the other hand, I'm intentionally uns
The first thing I would try is to see where the language is getting set to
objective c and force it c++. Just as an experiment. Depending where it
happens, it may be possible to initialize it from the debug info (or
hardcode it).
But since ObjC assumptions are baked into several places, this has
p
It seems like we hit this issue in different contexts almost at the same
time (see my thread several days ago about “problem formatting value
objects”). That might at least give you some context about why things
I wish ObjC assumptions weren’t so deeply embedded, but alas it is the case.
Hopefull
Ok that was it, it was because my type was called Class. Oops!
On Fri, Oct 26, 2018 at 4:28 PM Jim Ingham wrote:
> 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
So, the second command works, but the first one doesn't. It doesn't give
any error, but on the other hand, it doesn't change the results of printing
the variable. When I run type category list though, I get this:
(lldb) type category list
Category: default (enabled)
Category: VectorTypes (enable
Note that I also tried this with a a linux / DWARF executable and had the
same result.
On Fri, Oct 26, 2018 at 3:21 AM Zachary Turner wrote:
> Hello,
>
> I've got this code:
>
> class Class {
> int x = 0;
> short y = 1;
> char z = 'z';
> } C;
>
> int main(int argc, char **argv) {
> __deb
Hello,
I've got this code:
class Class {
int x = 0;
short y = 1;
char z = 'z';
} C;
int main(int argc, char **argv) {
__debugbreak();
return 0;
}
and I run the following LLDB session:
lldb.exe -f foo.exe
(lldb) target create "foo.exe"
Current executable set to 'foo.exe' (x86_64).
(ll
I was trying to implemented type lookup for qualified names (e.g. in
namespaces), and I noticed we have this code in Module.cpp:
if (Type::GetTypeScopeAndBasename(type_name_cstr, type_scope,
type_basename,
type_class)) {
// Check if "name" starts with "::"
So IIUC this all 1 big solution, one component of which is LLVM? How do you
get them all together in 1 big solution?
On Wed, Oct 10, 2018 at 7:16 AM Nicolas Capens
wrote:
> Hi Zachary,
>
> We use LLVM JIT in SwiftShader, which is used by Google Chrome and Android
> (Emulator). Most development ta
On Tue, Oct 9, 2018 at 12:49 AM Csaba Raduly wrote:
> On Sun, Oct 7, 2018 at 10:51 PM Zachary Turner via cfe-dev
> wrote:
>
> > 1) Run CMake twice, generating to separate output directories. Once
> using -G "Visual Studio 15 2017" and once using -G Ninja, each to different
> directories.
> >
>
On Mon, Oct 8, 2018 at 12:29 PM wrote:
> I build with the VS project. I find it more convenient to do that than
> have VS and a cmd window open to run ninja. Especially when I’ve got more
> than 1 copy of VS open looking at different release trains. I wouldn’t mind
> using ninja to build, but onl
s us the function's address
> range, so is there some technical reason why it couldn't parse the line
> table only for the given address range?
> >
> > My understanding is that there's one DWARF .debug_line "program" per CU,
> and normally you'd need to &qu
On Mon, Oct 8, 2018 at 11:54 AM Stephen Kelly via cfe-dev <
cfe-...@lists.llvm.org> wrote:
>
> > 3) Even if you do pass -Thost=x64 to CMake, it will apparently still
> > fail sometimes. See this thread for details:
> > http://lists.llvm.org/pipermail/cfe-dev/2018-October/059609.html. It
> > seem
On Mon, Oct 8, 2018 at 7:42 AM Greg Bedwell wrote:
> Thanks for raising this.
>
> This is a topic I've been interested in for a while too, as I've had to do
> a few of those lite.site.cfg fix-ups that you mention (in fact I have one
> sitting unreviewed at https://reviews.llvm.org/D40522 although
Yes i listed 5 steps, but 2 of them (#2 and #5) are exactly what you
already do.
#1 I only actually do every couple of weeks, which is an improvement over
building inside VS. when you build inside vs you have to close and reopen
the solution every time you sync, which is really slow. You don’t act
What would the variable do? Ninja and VS are generators, the only way to
specify them is with the -G option to cmake. If you use the VS generator,
there's no way I'm aware of to make it use ninja instead of MSBuild when
you hit Ctrl+Shift+B.
That said, type ninja in a command prompt is not a ter
This has been on my mind for quite some time, but recently it's been
popping up more and more seeing some of the issues people have run into.
Before people get the wrong idea, let me make one thing clear. **I am not
proposing we stop supporting the CMake Visual Studio generator. I am only
propos
While implementing native PDB support I noticed that LLDB is asking to
parse an entire compile unit's line table in order to determine if 1
address is a function prologue or epilogue.
Is this necessary in DWARF-land? It would be nice if I could just pass the
prologue and epilogue byte size direct
To clarify, #1 is saying to re-implement the API **in LLVM** so that LLDB
transparently just works with no code changes. While #2 is saying to
re-implement the plugin **in LLDB** to not use that API at all, and instead
use the low-level API that parses records directly from the file.
On Tue, Oct
Currently our PDBASTParser and SymbolFilePDB can only work on Windows
because it relies on a builtin Windows library.
In LLVM now we have full ability to read, parse, and interpret the contents
of PDB files at the byte level. There are two approaches to getting this
working in LLDB.
1) Re-implem
but I think the problem space here
> is complicated enough already... You can't write a test if you don't know
> the correct end state.
>
> Jim
>
>
> > On Sep 19, 2018, at 10:59 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
By the way, several weeks / months ago I had an idea for exposing a
debugger object model. That would be one very powerful way to create
reproducers, but it would be a large effort. The idea is that if every
important part of your debugger is represented by some component in a
debugger object mod
I assume that reproducing race conditions is out of scope?
Also, will it be possible to incorporate these reproducers into the test
suite somehow? It would be nice if we could create a tar file similar to a
linkrepro, check in the tar file, and then have a test where you don't have
to write any p
That would be my thought, yea
On Fri, Aug 31, 2018 at 1:21 AM Aleksandr Urakov <
aleksandr.ura...@jetbrains.com> wrote:
> Thanks for the reply!
>
> Yes, the function search is implemented in the way similar to what you
> have described (and even the search in a symbol file is done before the
> sea
It seems reasonable to me to say that if the symbol is not found in the
executables symtab, it will fall back to searching in the symbol file..
this logic doesn’t even need to be specific to PDB
On Thu, Aug 30, 2018 at 7:00 AM Aleksandr Urakov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hello
I’m fine with it. I still would like to see inline tests ported to a custom
lit test format eventually, but this seems orthogonal to that and it can be
done in addition to this
On Thu, Aug 23, 2018 at 4:25 PM Vedant Kumar wrote:
> Pinging this because I'd like this to go forward to make testing e
I think Aaron added that code for when the language is not set, but he can
clarify.
Off the top of my head I guess it helps with demangling symbols. Eg you
can’t demangle symbols from a TU without knowing what the language is.
There could be other reasons though. For example each language is going
Various parts of lldb require knowing the source language. It’s possible
that things will mostly work if you report that the language is c++, but
you’ll probably get errors in other areas. It goes all the way down to the
CodeView level, where certain cv records indicate the original source
language
What do your patches do, out of curiosity?
On Wed, Aug 15, 2018 at 12:45 PM Vedant Kumar wrote:
>
> On Aug 15, 2018, at 12:27 PM, Zachary Turner wrote:
>
> Back to the original proposal, my biggest concern is that a single inline
> test could generate many FileCheck invocations. This could cau
Back to the original proposal, my biggest concern is that a single inline
test could generate many FileCheck invocations. This could cause
measurable performance impact on the test suite. Have you considered this?
Another possible solution is what i mentioned earlier, basically to expose
a debug
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 having tests leads to having bugs, and sb api tests leads
> to not having te
>
> Yes, l
Having bugs also makes the debugger harder to innovate in the future
because it’s, not having tests leads to having bugs, and sb api tests leads
to not having tests. At the end of the day, it doesn’t matter how stable
the tests are if there arent enough of them. There should be about 10x-20x
as man
On Tue, Aug 14, 2018 at 5:56 PM Vedant Kumar wrote:
>
>
> On Aug 14, 2018, at 5:34 PM, Zachary Turner wrote:
>
> I’ve thought about this in the past but the conclusion I came to is that
> lldbinline tests are actually just filecheck tests in disguise. Why do we
> need both? I’d rather delete the
I’ve thought about this in the past but the conclusion I came to is that
lldbinline tests are actually just filecheck tests in disguise. Why do we
need both? I’d rather delete the lldbinline infrastructure entirely and
make a new lit TestFormat that basically does what lldbinline already does
On Tu
This is really cool. Maybe you could do it for all of LLVM too? It would
be nice if, instead of cycling through each benchmark on a set interval,
there were just a dropdown box where you could select the one you wanted to
see.
On Fri, Aug 3, 2018 at 3:37 PM Raphael Isemann via lldb-dev <
lldb-de
Yea, removing them is probably fine.
On Tue, Jul 17, 2018 at 11:14 AM Stella Stamenova
wrote:
> Hey all,
>
>
>
> I’ve been looking at some of the test failures on Windows and this led me
> to realize that there are at least several tests that are duplicated
> between lldb-suite and the lit tests
You might not get a reply but usually the turnaround time is < 24 hours.
If it's not let me know and I'll find out who to ask.
On Thu, Jul 12, 2018 at 7:50 AM NeckTwi via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I’m getting same error even if I debug on the same device.
>
> necktwi@pi:/home/n
Is it? If lldb is totally broken without that patch we should upstream it
no?
On Tue, Jul 10, 2018 at 8:52 PM Aaron Smith
wrote:
> This patch is needed for lldb to work on Windows.
>
> https://reviews.llvm.org/D12245
>
>
> --
> *From:* Zachary Turner
> *Sent:* Friday,
It’s been a while since i was close to this code, so adding people who have
been in there more recently
On Thu, Jul 5, 2018 at 1:12 PM Salahuddin Khan wrote:
> Hi Zachary,
>
>
>
> Ahh ok, thanks for your quick response.
>
>
>
> I was hoping to use LLDB on Windows (to debug Go code), which I know
Plugin is a bit misleading. All “plugins” are compiled into lldb. Plugins
are really just a layering abstraction.
To answer your question, pdb works currently but is limited in
functionality. First, it only supports limited usage scenarios, and second
it requires Windows. It’s currently built on t
assumptions and requirements
On Wed, Jun 27, 2018 at 12:56 AM Pavel Labath wrote:
> On Wed, 27 Jun 2018 at 01:14, Zachary Turner via lldb-dev
> wrote:
> >
> > Yes that’s what I’ve been thinking about as well.
> >
> > One thing I’ve been giving a lot of thought to is whether
ser" or do you mean something more radical? For instance, adding a
> TypeSystem and its DWARF parser for C family languages that uses a
> different underlying representation than Clang AST's to store the results
> would be a lot of work that wouldn't be terribly interes
Ahh, thanks. I thought those changes never landed, but it's good to hear
that they did.
On Tue, Jun 26, 2018 at 1:49 PM Adrian Prantl wrote:
>
> > On Jun 26, 2018, at 1:38 PM, Zachary Turner wrote:
> >
> >> On Tue, Jun 26, 2018 at 1:28 PM Adrian Prantl
> wrote:
> >>
> >>> > On Jun 26, 2018, a
On Tue, Jun 26, 2018 at 1:28 PM Adrian Prantl wrote:
>
>
> > On Jun 26, 2018, at 11:58 AM, Zachary Turner via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
> >
> > Hi all,
> >
> > We have been thinking internally about a lightweight llvm-based
> ptracer. To address one question up front: the prim
Jun 26, 2018 at 12:26 PM Jim Ingham wrote:
> >> Just to be clear, by "no clang integration" do you mean "no expression
> parser" or do you mean something more radical? For instance, adding a
> TypeSystem and its DWARF parser for C family languages that uses a
>
parser for C family languages that uses a
> different underlying representation than Clang AST's to store the results
> would be a lot of work that wouldn't be terribly interesting to lldb. I
> don't think that's what you meant, but wanted to be sure.
>
> Jim
>
>
Hi all,
We have been thinking internally about a lightweight llvm-based ptracer.
To address one question up front: the primary way in which this differs
from LLDB is that it targets a more narrow use case -- there is no
scripting support, no clang integration, no dynamic extensibility, no
support
+1 for limiting the scope of a variable as much as possible
On Mon, Jun 18, 2018 at 7:57 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Thanks. I am going to submit the patch then.
>
> On Fri, 15 Jun 2018 at 19:56, Jim Ingham wrote:
> > > On Jun 15, 2018, at 3:44 AM, Pavel Labat
find an object-file-reader/writer library. ELF may be more complicated
> though.
>
> > On Jun 13, 2018, at 2:51 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > What about the case where you already have a Unix core file and you
> aren
they are not examined in the machine that
>> they were produced on. So LLDB gives us the connection to the live process,
>> and we can then create a minidump file. I am going to create a python
>> module that can do this for us.
>>
>> Greg
>>
>>
>> O
oduced on. So LLDB gives us the connection to the live process,
> and we can then create a minidump file. I am going to create a python
> module that can do this for us.
>
> Greg
>
>
> On Jun 13, 2018, at 2:29 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org>
;>> I've also pinged another Googler who I know might be interested in
>>> converting between minidumps and core files (the opposite direction) to see
>>> if he has any additional info. I don't think he's on lldb-dev, though, so
>>> I'll act as a r
1 - 100 of 635 matches
Mail list logo
