Re: [lldb-dev] Passing std::atomics by value

ote: > > > >> > >> On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> > >> I recently updated to Visual Studio 2015 Update 3, which has improved > its diagnostics. As a result of this, LLDB is unc

Re: [lldb-dev] Passing std::atomics by value

nction signature, so they can both figure out where the actual struct > lives in the argument slot based on the alignment of the stack slot. > > Jim > > > > > > On Fri, Aug 26, 2016 at 11:29 AM Greg Clayton > wrote: > > > > > On Aug 26, 2016, at 11:24 AM,

Re: [lldb-dev] Passing std::atomics by value

win as the target and the generated assembly makes no attempt to > pad the arguments. > > > > I'll post some code later > > > > On Fri, Aug 26, 2016 at 11:42 AM Jim Ingham wrote: > > > > > On Aug 26, 2016, at 11:36 AM, Zachary Turner via lldb-dev < > lld

Re: [lldb-dev] Passing std::atomics by value

h that. > > Is Address the only class that is causing problems? > > Greg > > > On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > I recently updated to Visual Studio 2015 Update 3, which has improved > it

Re: [lldb-dev] Passing std::atomics by value

oblem. On Fri, Aug 26, 2016 at 1:11 PM Mehdi Amini wrote: > On Aug 26, 2016, at 1:02 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > It seems to be. I will also make the copy constructor =delete() to make > sure this cannot happen again. > > >

Re: [lldb-dev] Passing std::atomics by value

the problem. > > On Fri, Aug 26, 2016 at 1:11 PM Mehdi Amini wrote: > >> On Aug 26, 2016, at 1:02 PM, Zachary Turner via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >> It seems to be. I will also make the copy constructor =delete() to make >> sure

Re: [lldb-dev] Passing std::atomics by value

t;> > > { > > } > > > > circumventing the problem. > > > > On Fri, Aug 26, 2016 at 1:11 PM Mehdi Amini > wrote: > >> On Aug 26, 2016, at 1:02 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> > >&g

Re: [lldb-dev] LLDB Evolution

writing most tests as inline tests like > lldbinline. Lit can support this too, the parsing and file commands are all > up to the implementation. So the existing model of run tool and grep output > is just one implementation of that, but you could design one that has build > commands, c+

Re: [lldb-dev] LLDB Evolution

26, 2016, at 6:12 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Back to the formatting issue, there's a lot of code that's going to look > bad after the reformat, because we have some DEEPLY indented code. LLVM > has adopted the early return m

Re: [lldb-dev] Symbol Server for everyone.

Making the SymbolVendor dependent on Python is probably a non starter, and it would also make debugging more difficult. We have network code for various platforms in Host already. It would be nice to have a symbol server format that is platform agnostic. On the other hand, Microsoft tools already

Re: [lldb-dev] Symbol Server for everyone.

By platform agnostic i mean having a single symbol server that works across multiple platforms is very nice. It sounds like in addition to being a symbol server this can also serve source code, and should work with embedded debug info, split dwo, or even pdb? On Fri, Aug 26, 2016 at 9:54 PM Taras T

Re: [lldb-dev] LLDB Evolution

the egregious cases before the big reformat will present a challenge, so I'm not sure if it's better to spend effort trying, or just deal with it as we spot code that looks bad because of indentation level. On Sat, Aug 27, 2016 at 9:24 AM Chris Lattner wrote: > On Aug 26, 2016, at 6:1

[lldb-dev] debugserver and llvm

What is the status of using LLVM from debugserver? AFAICT, it doesn't use llvm, but it DOES use some lldb private libraries, in which case it is already implicitly linking against LLVM anyway. So why can't LLVM headers be included and used from debugserver? Just now I was changing the signature

Re: [lldb-dev] LLDB Evolution

'm not sure if it's better to spend effort trying, or just > deal with it as we spot code that looks bad because of indentation level. > > On Sat, Aug 27, 2016 at 9:24 AM Chris Lattner wrote: > >> On Aug 26, 2016, at 6:12 PM, Zachary Turner via lldb-dev < >>

Re: [lldb-dev] LLDB Evolution

big reformat). >> >> Finding all of the egregious cases before the big reformat will present a >> challenge, so I'm not sure if it's better to spend effort trying, or just >> deal with it as we spot code that looks bad because of indentation level. >> >

Re: [lldb-dev] Passing std::atomics by value

My concern is that by not taking out the copy constructor, someone passes another Address by value later. If passing by value is unsafe (ignoring whether it generates a compiler error) it should be prevented by the compiler. That is doing due diligence. I will track down the commit that introduced

Re: [lldb-dev] Passing std::atomics by value

How about making it a std::unique_ptr>? This way there's no risk of re-introducing a potential race, and copying still works. On Mon, Aug 29, 2016 at 8:49 AM Zachary Turner wrote: > My concern is that by not taking out the copy constructor, someone passes > another Address by value later. If pa

Re: [lldb-dev] debugserver and llvm

n, Aug 29, 2016 at 10:51 AM Greg Clayton wrote: > > > On Aug 27, 2016, at 3:14 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > What is the status of using LLVM from debugserver? AFAICT, it doesn't > use llvm, but it DOES use some ll

Re: [lldb-dev] debugserver and llvm

the packet. Not to say that this can't be fixed with > software. > > I still vote to just make a StringRefExtractor.h/.cpp that completely cuts > over to using llvm::StringRef only. We can cut over to using it everywhere. > If nothing is left inside of LLDB, we can move StringExt

Re: [lldb-dev] debugserver and llvm

ndler for the GDB remote stuff. >> StringExtractorGDBRemote inherits from StringExtractor and uses the >> std::string to store the packet. Not to say that this can't be fixed with >> software. >> >> I still vote to just make a StringRefExtractor.h/.cpp that comple

Re: [lldb-dev] Python3 compatibility for the API

Hi, LLDB already supports Python 3. I spent a LONG time making this work. :) I've only ever tested the Python 3 support on Windows, and I've only tested 3.5 and above, but I don't expect any major difficulties getting it working on another platform, although you may need to tweak the CMake a li

Re: [lldb-dev] Python3 compatibility for the API

3.6.2 should be new enough, Python 3 has been working for over a year and it's actually the only supported configuration right now on Windows. Most likely the problem is just that I never updated the build system to work with a platform other than Windows. Unfortunately, being that I work primari

Re: [lldb-dev] Python3 compatibility for the API

Right, the existing version that is built and what you are using links directly against a 2.7 libpython at compile time. So you would probably need to build LLDB from source and tweak the build system to make it possible to link against your 3.x version of python. There's some build instructions

Re: [lldb-dev] LLDB Evolution: Next Phase

Yea it's only clang bots i think On Tue, Sep 6, 2016 at 6:30 AM Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Wow, I had no idea things were that bad. LLDB buildbots do not seem to > be affected though, so I think we should proceed. > > pl > > > > On 6 September 2016 at 14:09, Ed M

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

I think it goes without saying, but henceforth, no changes should be landed without first passing them through clang-format. Personally, I will be reverting any I see that don't conform. But I can't promise to catch all of them. On Tue, Sep 6, 2016 at 2:17 PM Kate Stone via lldb-dev < lldb-dev@l

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

Everything compiles on Windows now but all the tests are failing with ERROR. I'm looking into this now. On Tue, Sep 6, 2016 at 2:26 PM Ed Maste via lldb-dev < lldb-dev@lists.llvm.org> wrote: > On 6 September 2016 at 17:17, Kate Stone via lldb-dev > wrote: > > The storm of commit messages might

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

I think Windows is good. On Tue, Sep 6, 2016 at 3:10 PM Zachary Turner wrote: > Everything compiles on Windows now but all the tests are failing with > ERROR. I'm looking into this now. > > On Tue, Sep 6, 2016 at 2:26 PM Ed Maste via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > On 6 Septemb

Re: [lldb-dev] Running Clang-format automatically in CMake

What would be the gain of such a thing? It would be extremely slow to run clang-format every single time you ran CMake, and also having a run of CMake generate changes to your source tree seems like using the wrong tool for the job. I think we should follow whatever LLVM does, which in this case

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

unit tests get green > > on windows. > > > > pl > > > > On 6 September 2016 at 23:26, Zachary Turner via lldb-dev > > wrote: > >> I think Windows is good. > >> > >> On Tue, Sep 6, 2016 at 3:10 PM Zachary Turner > wrote: > >>

Re: [lldb-dev] [OS X]: building lldb with cmake

It's possible they weren't supported in the past, but creating Frameworks is definitely supported now. https://cmake.org/cmake/help/v3.6/manual/cmake-buildsystem.7.html#apple-frameworks https://cmake.org/cmake/help/v3.6/prop_tgt/FRAMEWORK.html#prop_tgt:FRAMEWORK Here's a more detailed example. h

Re: [lldb-dev] [OS X]: building lldb with cmake

Yes, this is a bug in LLDB. You're welcome to try to fix it by changing it to include "llvm/Support/Regex.h" instead of this private header. Not sure if you will run into any issues, but in theory I see no reason why it shouldn't work. On Fri, Sep 9, 2016 at 12:37 PM René J.V. Bertin via lldb-de

Re: [lldb-dev] [OS X]: building lldb with cmake

To be completely honest with you I don't even know why this class exists. All it needs to do is use llvm's regex class. The entire MIUtilParse.h / .cpp files can be deleted as far as I'm concerned. On Fri, Sep 9, 2016 at 12:45 PM Zachary Turner wrote: > Yes, this is a bug in LLDB. You're welco

Re: [lldb-dev] [OS X]: building lldb with cmake

Agree that a standalone build would be great to have working, it just requires someone willing and able to come along and fix it :) On Sat, Sep 10, 2016 at 1:00 AM René J.V. Bertin wrote: > On Friday September 09 2016 20:00:34 Zachary Turner wrote: > >To be completely honest with you I don't eve

Re: [lldb-dev] Psuedo terminal on Windows

Ahh that explains why I didn't notice it. Is the fix straightforward? On Mon, Sep 12, 2016 at 1:31 AM Carlo Kok via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > On 2016-09-12 10:06, Carlo Kok via lldb-dev wrote: > > Hi, > > > > ProcessLaunchInfo seems to, unconditionally create a pseudo termin

Re: [lldb-dev] [PATCH] D24591: [LIT] First pass of LLDB LIT support

lldb-commits to bcc, lldb-dev to cc. > The biggest feature I see missing here is the ability to run tests remotely. Remote debugging is the most important use case for our team, and now we have a number of (experimental) bots running the remote test suite. We want to make sure we can debug correct

[lldb-dev] LLDB Evolution - Final Form

Following up with Kate's post from a few weeks ago, I think the dust has settled on the code reformat and it went over pretty smoothly for the most part. So I thought it might be worth throwing out some ideas for where we go from here. I have a large list of ideas (more ideas than time, sadly) th

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 1:38 PM Sean Callanan wrote: > I'll only comment on the stuff that affects me. > > >1. Use llvm streams instead of lldb::StreamString > 1. Supports output re-targeting (stderr, stdout, std::string, etc), > printf style formatting, and type-safe streaming

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 1:57 PM Enrico Granata wrote: > > I am definitely not innocent in this regard. However, it does happen for a > reason. > > Sometimes, I am writing code in lldb that is the foundation of something I > need to do over on the Swift.org side. > > I'll lay out foundational work

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > • Separate testing tools > > • One question that remains open is how to > represent the complicated needs of a debugger in lit tests. Part a) above > covers the trivial cases, but what about the difficu

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Following up with Kate's post from a few weeks ago, I think the dust has > settled on the code ref

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 2:20 PM Mehdi Amini wrote: > > > I’m surprise by your aversion to assertions, what is your suggested > alternative? Are you expecting to check and handle every possible > invariants everywhere and recover (or signal an error) properly? That does > not seem practical, and i

Re: [lldb-dev] LLDB Evolution - Final Form

n Mon, Sep 19, 2016 at 2:34 PM Greg Clayton wrote: > > > On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote: > > > >> > >> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> > >> >

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 2:37 PM Greg Clayton wrote: > > > Just thinking out loud here, but one possibility is to have multiple > pools. One which is ref counted and one which isn't. If you need > something to live forever, vend it from the non-ref-counted pool. > Otherwise vend it from the ref

Re: [lldb-dev] LLDB Evolution - Final Form

at 2:11 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > > > > > On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > > > • Separate testing tools > > > • One question that r

Re: [lldb-dev] LLDB Evolution - Final Form

e. We should > test this thing that we think is valuable. > > What's a good way to make sure we test that? > > USE IT FOR TESTING. > > Jim > > > > > > > > On Mon, Sep 19, 2016 at 3:07 PM Jim Ingham wrote: > >

Re: [lldb-dev] LLDB Evolution - Final Form

> > > > >> > > >> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > >> > > >> > > >>> On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: >

Re: [lldb-dev] LLDB Evolution - Final Form

> >> > >>> > >>> On Sep 19, 2016, at 2:20 PM, Mehdi Amini > wrote: > >>> > >>>> > >>>> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >>>> > >

Re: [lldb-dev] LLDB Evolution - Final Form

ev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of > Zachary Turner via lldb-dev > Sent: Tuesday, September 20, 2016 12:47 PM > > > This kind of philisophical debate is probably worthy of a separate > thread :) That being said, I think asserts are typically used in place

Re: [lldb-dev] LLDB Evolution - Final Form

On Tue, Sep 20, 2016 at 1:55 PM Greg Clayton wrote: > > > On Sep 20, 2016, at 1:45 PM, Zachary Turner wrote: > > > > I do agree that asserts are sometimes used improperly. But who's to say > that the bug was the assert, and not the surrounding code? For example, > consider this code: > > > > a

Re: [lldb-dev] LLDB Evolution - Final Form

Well, but StringRef for example is well documented. So it seems to me like there's an example of a perfectly used assert. It's documented that you can't use null, and if you do it asserts. Just like strlen. The issue I have with "you can't ever assert" is that it brings it into an absolute when

Re: [lldb-dev] LLDB Evolution - Final Form

I don't think anyone is ok with that. I just think that a better solution is to document them. Why handle at runtime what is known about at compile time? On Tue, Sep 20, 2016 at 2:24 PM Zachary Turner wrote: > Well, but StringRef for example is well documented. So it seems to me > like there'

Re: [lldb-dev] LLDB Evolution - Final Form

StringRef has `withNullAsEmpty` which I added a few days ago. It will return an empty StringRef. seems to me that should solve most of those kinds of problems. On Tue, Sep 20, 2016 at 2:31 PM Greg Clayton wrote: > We should avoid crashing if there is a reasonable work around when the > input i

Re: [lldb-dev] LLDB Evolution - Final Form

Also, maybe that code could just return a StringRef. It's like I mentioned a few days ago (don't remember if it was this thread or another), but when you've got StringRefs all the way down, this problem pretty much disappears. On Tue, Sep 20, 2016 at 2:36 PM Zachary Turner wrote: > StringRef ha

Re: [lldb-dev] LLDB Evolution - Final Form

Occasionally (and in my experience *very* occasionally), you need to treat "" as different from null. But the frequency with which that is really necessary is much lower than people realize. It just seems high because of the prevalence of raw pointers. For every other case, you can use withNullA

Re: [lldb-dev] LLDB Evolution - Final Form

On Tue, Sep 20, 2016 at 2:51 PM Greg Clayton wrote: > > > On Sep 20, 2016, at 2:49 PM, Mehdi Amini wrote: > > > > > >> On Sep 20, 2016, at 2:46 PM, Zachary Turner wrote: > >> > >> Occasionally (and in my experience *very* occasionally), you need to > treat "" as different from null. > > doesn't

Re: [lldb-dev] LLDB Evolution - Final Form

BTW, one more comment about this. If you've got a situation where LLDB is using LLVM in a way that makes LLDB crash, there are 3 possibilities: 1) LLVM / Clang is vending a pointer and we're supposed to be checking it for null. 2) We used the LLVM / Clang API incorrectly causing it to return us a

Re: [lldb-dev] LLDB Evolution - Final Form

Adding another thing to my list (thanks to Mehdi and Eric Christopher for the idea). Apply libfuzzer to LLDB. Details sparse on what parse of LLDB and how, but I think it would be easy to come up with candidates. On Mon, Sep 19, 2016 at 1:18 PM Zachary Turner wrote: > Following up with Kate's

Re: [lldb-dev] LLDB Evolution - Final Form

hing as I convert code over to using StringRef and I get crashes: > > if (name == NULL) > > StringRef is nice enough to implicitly construct a StringRef from NULL or > nullptr so that it can crash for me... > > > On Sep 21, 2016, at 11:09 AM, Zachary Turner via ll

Re: [lldb-dev] LLDB Evolution - Final Form

On Wed, Sep 21, 2016 at 2:20 PM Greg Clayton wrote: > > > On Sep 21, 2016, at 1:55 PM, Zachary Turner wrote: > > > > :-/ The same thing happens if you write Foo &f = *nullptr; It's a > reference. > > I might be a good idea to add an overloaded constructor for nullptr and > void * and delete t

Re: [lldb-dev] LLDB Evolution - Final Form

The =delete overload of StringRef is also a great idea. It just helped me catch all the places where we were initializing global option tables from const char *s On Wed, Sep 21, 2016 at 2:28 PM Zachary Turner wrote: > On Wed, Sep 21, 2016 at 2:20 PM Greg Clayton wrote: > > > > On Sep 21, 2016,

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

Does the 4.0 binary not work for you? It is the first release that contains prebuilt lldb binary. Probably you are one of the first people to test it, so if you encounter problems, let me know what they are. The version of windows shouldn't matter as long as you are Win7 or higher. No vista. On

[lldb-dev] Converting global option tables to use ArrayRef

I have a patch I'd like to submit tomorrow which converts all of the global command option tables from C-style arrays to llvm ArrayRefs. Actually they are still declared internally in each translation unit as C-style arrays, but the Option classes are updated so that they return ArrayRefs instead

Re: [lldb-dev] Converting global option tables to use ArrayRef

to try to commit sometime after lunch after I confirm all the tests are passing. On Thu, Sep 22, 2016 at 9:33 AM Greg Clayton wrote: > That sounds like a good patch. I look forward to seeing it. > > > On Sep 21, 2016, at 11:48 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.

Re: [lldb-dev] RFC: Break/Watchpoint refactor

On Tue, Sep 27, 2016 at 1:09 PM Daniel Austin Noland via lldb-dev < lldb-dev@lists.llvm.org> wrote: > 4. All of these classes are "old school" (not necessarily bad, but > potentially a problem). For example: >a. lots of const char* running around. > We should use llvm::StringRef here. >

Re: [lldb-dev] RFC: Break/Watchpoint refactor

FWIW LLVM removed all it's disallow copy / assign macros in favor of explicitly writing it. I agree it's easier to just change the macro, but I would just do what LLVM does as long as you don't mind the extra work. On Tue, Sep 27, 2016 at 3:01 PM Daniel Austin Noland via lldb-dev < lldb-dev@lists

Re: [lldb-dev] RFC: Break/Watchpoint refactor

aving to deduce > it from details scattered through the class definition. > > Jim > > On Sep 27, 2016, at 3:13 PM, Sean Callanan via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Doing it everywhere would be a public service IMO. I don't like macros &g

Re: [lldb-dev] RFC: Break/Watchpoint refactor

llvm::function_ref is preferable to std::function. It's smaller and faster while still allowing lambdas, function pointers, and function objects On Tue, Sep 27, 2016 at 4:35 PM Greg Clayton wrote: > > > On Sep 27, 2016, at 3:43 PM, Zachary Turner via lldb-dev < > lldb-dev@l

Re: [lldb-dev] LLDB Evolution - Final Form

Just want to add new things as I think of them. On Mon, Sep 19, 2016 at 1:18 PM Zachary Turner wrote: > > >1. > >lldb-cli -- lldb interactive command line. > > A great way to test this would be have a tool as mentioned, and you pass an lldb command to the tool. It parses it and spits ou

Re: [lldb-dev] RFC: Break/Watchpoint Callback storage and validation

On Thu, Sep 29, 2016 at 5:34 PM Daniel Austin Noland via lldb-dev < lldb-dev@lists.llvm.org> wrote: > As per discussion in another thread > > (http://lists.llvm.org/pipermail/lldb-dev/2016-September/011397.html) > > I have started refactoring the private side of Break/Watchpoint. > > Mostly this i

Re: [lldb-dev] Asserts in StringRef::front

Thanks for the heads up. I do run with asserts, so I'm not sure why I didn't see this particular failure. In any case i'll go back and look through my changes for any other occurrences of this. Most of the time args were being checked before being used. Like the code would go: const char *arg

Re: [lldb-dev] fate of TimeValue

I'd love to move over to chrono. For Utility functions such as those you propose probably we should consider whether they should go into llvm. Does llvm currently use anything from chrono or have any chrono support functions yet? On Thu, Oct 6, 2016 at 5:39 PM Pavel Labath via lldb-dev < lldb-dev@l

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

He said he did, so I don't know. Vadim, can you elaborate? When you run `lldb -P` from the command line, what do you see? On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I imagine that Hans doesn't have Python 3 installed on his system, so LLDB > d

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

I may know what this is. Can you try setting PYTHONPATH though to point to your Python 3.5 installation though and see if it fixes it? (I don't think it will, but let's try anyway) On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov wrote: > It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

I think it is a problem with the way we built lldb. I will look into what additional steps we need to take when making the prebuilt binary so that it works next time. On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov wrote: > Nope, that didn't help. > > On Tue, Oct 11, 2016 at 5:16 PM, Zachary Tur

Re: [lldb-dev] unaligned cast in TCPSocket::Connect

I believe you are correct. We should create an in_addr on the stack and memcpy into it. On Thu, Oct 13, 2016 at 10:52 AM Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > TCPSocket::Connect has this line: > > host_str = ::inet_ntoa (*(struct in_addr > *)*host_entry->h_add

Re: [lldb-dev] File::Read does not read everything

Can you upload a diff (with context) to phabricator and add lldb-commits as a subscriber and myself / Greg as reviewers? On Mon, Oct 17, 2016 at 4:59 PM Eugene Birukov via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Here is what I am running now: > > > diff --git a/source/Host/common/File.cpp b/

Re: [lldb-dev] File::Read does not read everything

http://reviews.llvm.org. Create an account there and upload patch On Mon, Oct 17, 2016 at 5:15 PM Eugene Birukov wrote: > Sorry for noob's question: what is "phabricator"? > > Sure, I will do it as soon as I understand what you want me to do :) > > > Sent from Outlook >

Re: [lldb-dev] [llvm-dev] GitHub Survey - Results

It would be nice if the slides containing the pie-graphs showed the original question that people were responding to. It's a little hard to make sense of the answers if we can't see (and don't remember) the question. On Wed, Nov 2, 2016 at 12:39 PM Renato Golin via llvm-dev < llvm-...@lists.llvm.

Re: [lldb-dev] unittests/SymbolFile/PDB/Inputs/test-pdb.exe

The source code is here: https://llvm.org/svn/llvm-project/lldb/branches/google/testing/unittests/SymbolFile/PDB/Inputs/test-pdb.cpp And it definitely does nothing. Most of these AV are heuristic, it's probably suspicious about the fact that it's linked with unusual settings (ie /nodefaultlib) wh

[lldb-dev] Bug in StackFrame::UpdateCurrentFrameFromPreviousFrame

I was going through doing some routine StringRef changes and I ran across this function: std::lock_guard guard(m_mutex); assert(GetStackID() == prev_frame.GetStackID()); // TODO: remove this after some testing m_variable_list_sp = prev_frame.m_variable_list_sp; m_variable_list_valu

Re: [lldb-dev] Bug in StackFrame::UpdateCurrentFrameFromPreviousFrame

If the swap is correct, then wouldn't we also need to swap the variable list? On Mon, Nov 14, 2016 at 10:58 AM Jim Ingham wrote: > > > On Nov 13, 2016, at 4:48 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > I was going through d

Re: [lldb-dev] Bug in StackFrame::UpdateCurrentFrameFromPreviousFrame

Mon, Nov 14, 2016 at 10:58 AM Jim Ingham wrote: > > > > > On Nov 13, 2016, at 4:48 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > > > I was going through doing some routine StringRef changes a

Re: [lldb-dev] Code ownership resignation

I'm ok being co-owner of the test suite, but perhaps Todd should be there as well, and perhaps primary owner? He's done a ton of work on the multi-process infrastructure and probably is at least as familiar as I am, if not moreso with everything else. On Thu, Nov 17, 2016 at 9:23 PM Chris Lattner

[lldb-dev] Bug in CommandObjectThreadUntil

CommandObjectThreadUntil::DoExecute() has the following code: for (size_t i = 0; i < num_args; i++) { uint32_t line_number; line_number = StringConvert::ToUInt32(command.GetArgumentAtIndex(0), UINT32_MAX); if (li

[lldb-dev] Bug in OptionValuePathMappings::SetValueFromString

In the switch / case handler for eVarSetOperationRemove, there is the following code: if (num_remove_indexes) { // Sort and then erase in reverse so indexes are always valid std::sort(remove_indexes.begin(), remove_indexes.end()); for (size_t j = num_remove_indexes -

Re: [lldb-dev] Bug in OptionValuePathMappings::SetValueFromString

Also, I just noticed the loop only runs one time, so it appears equivalent to m_path_mappings.Remove(remove_indexes.size() - 1, m_notify_changes); which seems completely wrong On Fri, Nov 18, 2016 at 1:05 PM Zachary Turner wrote: > In the switch / case handler for eVarSetOperationRemove, there

[lldb-dev] Bug in CommandObjectFrameVariable::DoExecute()

On line 708 of CommandObjectFrame.cpp, I'm looking at this code: options.SetRootValueObjectName(name_cstr); This code occurs inside the else block of an if/else. name_cstr is declared prior to the if/else block and initialized to nullptr, but is only ever set to something other than nullptr in t

Re: [lldb-dev] Bug in OptionValuePathMappings::SetValueFromString

BTW, this exact same code seems to have been copied either to or from OptionValueFileSpecList::SetValueFromString, as it appears to have the same bug. Again, not sure how to see it fail in the debugger, but maybe someone knows? On Fri, Nov 18, 2016 at 1:07 PM Zachary Turner wrote: > Also, I jus

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

I believe the way to fix this is going to be building LLDB for the installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time +Ted, since I believe he is one of the few people currently using this flag. On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov wrote: > This is still broken in the October sna

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

So it sounds like you're saying that in order for Python support to work as part of an LLDB shipped in the installer, we need to do set 3 variables at CMake time. 1) -DLLDB_RELOCATABLE_PYTHON=TRUE 2) -DPYTHON_HOME = 3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE Now because of #3, the lldb shipped in the in

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

I overlooked that part of it, but yes that is another separate issue. (BTW, _lldb.pyd is simply a symlink to liblldb.dll). In any case, yea I think the entire lib/site-packages folder needs to be included. On Mon, Nov 28, 2016 at 10:15 AM Vadim Chugunov wrote: > Please correct me if I'm wrong,

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

BTW, _lldb.pyd is just a symlink of liblldb.dll. Perhaps you could try creating the symlink manually and copying the other files (e.g. embedded_interpreter.py, six.py, etc) over to see if it works. If it does, it would at least confirm that this is everything we need to do to get it working for y

Re: [lldb-dev] Refactoring in LLDB Windows Plugin

What would it take to make it so that local and remote process plugins use the same exact interface? I mean in theory they're doing the same thing, just on a different machine. If they shared an identical interface then you could hook the lldb-server up to it and it would work either locally or r

Re: [lldb-dev] Conditionally adding sources to the build

Unfortunately you will need to separate them at the directory levels. On Wed, Nov 30, 2016 at 4:29 PM Dmitry Mikulin via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi, > > I’m trying to conditionally add source files to the lldb build based on a > cmake configure time variable. I get the follow

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

I'm OOO this week, but I can look into that when I get back. What issues are you having with building LLDB with Ninja? On Mon, Dec 5, 2016 at 4:04 PM Vadim Chugunov wrote: > I am having no luck building LLDB with ninja, and there doesn't seem to be > a "package" target in the generated msbuild

Re: [lldb-dev] LLDB 4.0.0 crashes on Windows 7

I have never seen either of those problems, but I can test it out and see if I can reproduce. On Tue, Dec 6, 2016 at 7:59 AM Eli Zaretskii via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > Date: Tue, 15 Nov 2016 18:08:03 +0200 > > Cc: lldb-dev@lists.llvm.org > > From: Eli Zaretskii via lldb-dev

Re: [lldb-dev] logging in lldb

Code review with an unspecified number I think On Tue, Dec 6, 2016 at 8:55 AM Jim Ingham wrote: > Sorry, I'm being dense. What is Dx? > > Jim > > > On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote: > > > > I have created straw-man implementation of such an interface in > > Dx, together wi

Re: [lldb-dev] logging in lldb

Merging the thread over from lldb-commits: On Tue, Dec 6, 2016 at 9:57 AM Jim Ingham via Phabricator < revi...@reviews.llvm.org> wrote: > jingham added a comment. > > I not infrequently have some non-trivial code in the "if (log)" block that > gathers the information that I am then going to pri

Re: [lldb-dev] logging in lldb

On Tue, Dec 6, 2016 at 10:31 AM Greg Clayton wrote: > > > > It should be a formatter option for collections to allow you to print out > different ranges. If I have a target and a target knows how to print the > process and the process knows how to print the threads and the threads know > how to p

Re: [lldb-dev] logging in lldb

Pavel: You might start this effort to improve logging by just adding a Formatv member function to log to replace printf. I suspect many call sites would be made much less verbose this way. I think we'll still need to do the rest too, but this seems like the least amount of work to make incremental

<    1   2   3   4   5   6   7   >