Re: [lldb-dev] LLDB Evolution

I just committed another header cleanup commit, which makes lldb clang-format-immune ( = it still compiles after a full reformat) on linux. Other OS's are still likely to have some missed dependencies. However, when I tried running the test suite I got about 150 failures. Based on a sample of the

Re: [lldb-dev] LLDB Evolution

Hi Christian, I don't think we will need to modify clang-format to resolve this. At most we will need to disable the formatting in some regions. Zachary, I think we should first look at what kind of comment modifications is clang-format doing and whether they are preventing us from doing our stu

Re: [lldb-dev] First hand support for musl-libc

On 10 August 2016 at 22:34, Dangling Pointer wrote: > Thanks Pavel! I see the changes made in master branch. > > > By any change can these be back-ported to release38 and 39 branches? Since > llvm38 is the one aports is offering. > I think the 3.8 ship has sailed, but there still may be a chance

Re: [lldb-dev] First hand support for musl-libc

Hi, I do run a basic set of tests (compile+run test suite) on linux from time to time, but unfortunately I don't have time to be more active in this. I have just completed the test on the release branch with these changes cherry-picked and it seems to working fine. But I certainly agree that the r

Re: [lldb-dev] LLDB Evolution

On 12 August 2016 at 00:54, Chris Lattner via lldb-dev wrote: > I recommend approaching this in three steps: > > 1) get the less-controversial changes done that Greg was outlining. > 2) start a discussion in the llvm community about the concept of a > member/global prefix. > 2a) the community coul

Re: [lldb-dev] LLDB Evolution

erent files, but it should be manageable. pl On 12 August 2016 at 18:13, Jim Ingham wrote: > >> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev >> wrote: >> >> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev >> wrote: >>> I recommend appr

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

Hello Benjamin, all, the lldb-server implementation in linux works exactly the same way as debugserver does on osx -- it runs out of process and uses sockets to communicate with the client. The socketpair() optimization that Jim is talking about is not enabled there yet - I want to do some benchma

Re: [lldb-dev] LLDB Evolution

s. > > Kate Stone k8st...@apple.com >  Xcode Low Level Tools > > On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev > wrote: > > On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev > wrote: >> >> I've sampled the python code from the llvm rep

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

On 19 August 2016 at 22:10, Kate Stone via lldb-dev wrote: > Following up from yesterday, everything now builds and runs cleanly with the > configuration described below on macOS. I did have to make one set of minor > changes to preserve #include ordering, but that’s already committed to trunk >

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

Sounds like a good idea. After the reformat, we can try it out and see if it works well enough (I don't know how smart that thing is, but I can imagine it could end up quite confused by all the line breaking that clang-format will do). If it works, I will definitely use it. pl On 23 August 2016 a

Re: [lldb-dev] LLDB Evolution

I would definitely welcome more prolific usage of early returns, but I don't think we can do that before the big reformat. At least some of those changes will be pretty non-trivial and risky. I'd vote for making these changes after the reformat. Hopefully the uglyness of the code will also encourag

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

We don't have any immediate plans to make lldb work with python 3 on linux. However, I would be willing to guide you through making that work. As Zachary pointed out, it should be fairly simple, given that it already works on windows. I don't think you'll be able to avoid building your own copy of

Re: [lldb-dev] [OS X] debugserver SETUID root?

On 1 September 2016 at 10:01, René J.V. Bertin via lldb-dev wrote: > - does the debugserver application do anything which makes it a really bad > idea to make it SETUID root? It listens on a tcp connection, and takes control of random applications. debugserver is the ultimate remote code execut

Re: [lldb-dev] [OS X] debugserver SETUID root?

On 1 September 2016 at 11:37, René J.V. Bertin wrote: > On Thursday September 01 2016 10:14:16 Pavel Labath wrote: > >> security safeguards on osx (there certainly aren't any on linux), but > > There's the codesigning bit. But that's just more a nuisance than a real > protection, from what I can

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

Hi Ed, which bots are you referring to? Our bots were red overnight, but we've been cleaning them up now, and they should get green shortly. As far as we're concerned, the reformat can go on as planned. pl On 6 September 2016 at 13:06, Ed Maste via lldb-dev wrote: > On 3 September 2016 at 00:30

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

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 Maste wrote: > On 6 September 2016 at 08:51, Pavel Labath wrote: >> Hi Ed, >> >> which bots are you referring to? Our bots were red over

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

I am still seeing errors when building windows unittests. I'll have a change for fixing that soon. Apart from that everything else looks good on our side. I'll send an all clear once the unit tests get green on windows. pl On 6 September 2016 at 23:26, Zachary Turner via lldb-dev wrote: > I thin

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

On 6 September 2016 at 22:21, Zachary Turner via lldb-dev wrote: > 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 >

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

Windows unit tests passing now. All clear. On 7 September 2016 at 09:54, Pavel Labath wrote: > I am still seeing errors when building windows unittests. I'll have a > change for fixing that soon. Apart from that everything else looks > good on our side. I'll send an all clear once the unit tests

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

; >>> clang-formatting of my patch changed the style outside the patch (diff: >>> https://reviews.llvm.org/D24331?vs=70653&id=70654). Am I doing something >>> wrong? >>> >>> On Wed, Sep 7, 2016 at 1:06 PM, Pavel Labath via lldb-dev >>>

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

Hi Rene, building lldb on osx with cmake should work fine when you're doing it as a part of llvm (our buildbot is doing it ). What you are asking for is called a "standalone" build of LLDB. I don't think anyone has tried it on a mac, but

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

Sounds great, I am glad to hear python3 is working on linux as well. As for pexpect, could we just make sure our own copy of pexpect is not on the path in this case, and have the user install a python3-compatible version via usual means (apt-get install python3-pexpect, in case of ubuntu). pl On

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

On 15 September 2016 at 16:15, Zachary Turner wrote: > 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

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

On 22 September 2016 at 04:51, Chunseok Lee via lldb-dev wrote: > Actually, I am trying to remote-debug from lldb(win host) to > lldb-server(arm/x64 linux). In my case, The problem is that no > lldb-sever-4.0 is available(I only have lldb-server 3.8 for arm/x64 linux). > Q) lldb 4.0 and lldb-serve

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

I am a bit late to the party, but anyways, here are my thoughts on the issues here: On 19 September 2016 at 21:18, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Difficulty / Effort: 3 (5 if we have to add enhanced mode support) > > Use llvm streams instead of lldb::StreamString >

[lldb-dev] fate of TimeValue

Hello all, in line with the "deinventing the wheel" movement, I'd like to remove the TimeValue class from LLDB. I've done some research on a flight this week, and as far as I can tell all functionality can be easily replaced with appropriate usage of std::chrono::duration and time_point. The only

Re: [lldb-dev] fate of TimeValue

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@lists.llvm.org> wrote: > >> Hello all, >> >> in line with the "deinventing the wheel" movement, I&

Re: [lldb-dev] fate of TimeValue

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 >> wrote: >>> >>&g

Re: [lldb-dev] fate of TimeValue

On 7 October 2016 at 21:42, Mehdi Amini wrote: > >> On Oct 7, 2016, at 9:30 PM, Pavel Labath via lldb-dev >> wrote: >> >> The llvm-dev thread seems to have fizzed out - I would assume they are >> not interested in std::chrono. > > I suggest a totally

Re: [lldb-dev] fate of TimeValue

>> On Oct 7, 2016, at 10:29 PM, Mehdi Amini via lldb-dev >> wrote: >> >>> >>> On Oct 7, 2016, at 10:19 PM, Pavel Labath wrote: >>> >>> On 7 October 2016 at 21:42, Mehdi Amini wrote: >>>> >>>>> On Oct 7, 2016, at 9:30

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

fine by me. We should probably also stop using inet_ntoa as it is not thread-safe (I don't know what is the safe alternative off-hand). pl On 13 October 2016 at 19:00, Zachary Turner via lldb-dev wrote: > I believe you are correct. We should create an in_addr on the stack and > memcpy into it.

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

Our buildbot runs the test suite with a selection of compilers, one of which is clang ToT (test3, test4). You should get an email from it if anything breaks. pl On 20 October 2016 at 00:24, Eric Christopher via lldb-dev wrote: >

[lldb-dev] LLGS for Free/NetBSD (was: Re: [PATCH] D25756: FreeBSD ARM support for software single step.)

Moving the discussion to lldb-dev. On 21 October 2016 at 18:55, Dmitry Mikulin wrote: > Thanks Pavel! I'll start working on it. Do you know when lldb-server Linux > changes were committed? I want to use those patches as a template, but it's > hard to locate them digging through thousands of com

Re: [lldb-dev] Returning multiple values in Python API function

On 22 October 2016 at 00:17, Francis Ricci via lldb-dev wrote: > On Fri, Oct 21, 2016 at 3:30 PM, Greg Clayton wrote: >> >>> On Oct 21, 2016, at 1:03 PM, Francis Ricci via lldb-dev >>> wrote: >>> >>> Hi all, >>> >>> I'm looking to add Platform::LaunchGDBServer() to the SBPlatform API, >>> but i

[lldb-dev] liblldb linking proposals

This is just an FYI email. I've made two proposals to address linking issues that have been troubling us lately. If you are interested in that, please take a look at and , and let me know what you think. pl ___

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

Nice catch. You should be able to reproduce the bug like this: (lldb) set append target.source-map 0 /tmp 1 /tmp 2 /tmp 3 /tmp 4 /tmp 5 /tmp 6 /tmp (lldb) set show target.source-map target.source-map (path-map) = [0] "0" -> "/tmp" [1] "1" -> "/tmp" [2] "2" -> "/tmp" [3] "3" -> "/tmp" [4] "4" -> "

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

The way we have done this with Linux native register contexts was to notionally leave the files in the build, but completely #ifdef out their contents (see NativeRegisterConextLinux_arm.cpp). It's not very nice, but I think it's better than having six subfolders, each with a single cpp file. If you

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

I'm curious, can you share how did you deal with the fact that the gdb-remote protocol is very signal-centric? E.g. every stop-reply ($T) has to have a specific signal associated with it, and some signals have special meaning in lldb. Do you just fake the signal numbers when you need to? Or is the

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

I am glad to see freebsd is making progress on this front. If you need any help with understanding how lldb-server works, feel free to shoot me a question. pl On 1 December 2016 at 23:00, Dmitry Mikulin wrote: > Thanks for the suggestions. > I’m working on native support for FreeBSD lldb-server

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

Hi, I am not aware of anyone ever trying that. In theory it should work if you copy the build and source folders to the other machine and run dotest.py with the right arguments there, but I guess that is not what you meant by "easy". The thing that I would try in this situation is to set it up so

[lldb-dev] logging in lldb

Hello all, I've been thinking about how to simplify the way we do logging in lldb. The main two problems I see are: a) inability to print complex types easily - this was always tricky, but lately has become even more problematic, as we're starting to introduce llvm::StringRef, chrono, and other no

Re: [lldb-dev] fate of TimeValue

needed. >> >> Greg >> >>> On Oct 7, 2016, at 10:29 PM, Mehdi Amini via lldb-dev >>> wrote: >>> >>>> >>>> On Oct 7, 2016, at 10:19 PM, Pavel Labath wrote: >>>> >>>> On 7 October 2016 at 21:42, Mehdi Ami

Re: [lldb-dev] fate of TimeValue

needed. >>> >>> Greg >>> >>>> On Oct 7, 2016, at 10:29 PM, Mehdi Amini via lldb-dev >>>> wrote: >>>> >>>>> >>>>> On Oct 7, 2016, at 10:19 PM, Pavel Labath wrote: >>>>> >>>>>

Re: [lldb-dev] logging in lldb

On 6 December 2016 at 16:51, 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 with some examples of how it's used, and I'd like to >

Re: [lldb-dev] logging in lldb

Ah, I totally forgot about the llvm DEBUG macro. I would be open to trying merge these two approaches together. However, I think our's is a much more heavy-weight system, so it might be too heavy for llvm, and I am not sure how much would we be willing to lose in the process: - we have two level lo

Re: [lldb-dev] logging in lldb

On 6 December 2016 at 17:39, Jim Ingham wrote: > >> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote: >> >> Hello all, >> >> I've been thinking about how to simplify the way we do logging in >> lldb. The main two problems I see are: >> a) inability to print complex types easily - this was always tr

Re: [lldb-dev] logging in lldb

On 6 December 2016 at 18:30, Jim Ingham wrote: > >> On Dec 6, 2016, at 10:20 AM, Pavel Labath wrote: >> >>> I think having a convenience to add function name decorators is fine, but >>> we need a way not to do it all the time. We have logs that don't have >>> function names because they log ov

Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

Hello Eugene, this sounds troubling, and I'd like to get to the bottom of this. If you can get me a bit more information about this, I believe we can figure it out: - could you get a backtrace of lldb-server when it is in the "stuck" state (just attach with lldb/gdb after it hangs and do "bt")? I

Re: [lldb-dev] logging in lldb

Sorry, I have been derailed today by trying to make format member detection work more reasonably. I plan to come up with the next iteration of the proposal soon, but I am not sure if it will be today, as it is quite late here already. I do think this needs to be done in incremental steps, but I'd l

Re: [lldb-dev] logging in lldb

Hello again, I have updated the example code to reflect some of the results from this discussion. I think we are generally converging XXX, I am going to try to summarize it here, to see if we have any issues left to discuss. - everyone seemed to prefer the formatv-based api, so that should be the

Re: [lldb-dev] logging in lldb

There were additional comments on the lldb-commits thread. I am moving them here and responding: Jason Molenda wrote on the lldb-commits thread: > A couple of thoughts / two cents. > I don't mind the current if (log) { ... } style of logging, even with the > PRIx64's and having to do filepath.Get

Re: [lldb-dev] logging in lldb

Hello again, I'd to get back to the question of unifying llvm's and lldb's logging mechanisms that Chris asked about. In the way these two are implemented now, they have a number of similarities, but also a number of differences. Among the differences, there is one that I think will be most painfu

Re: [lldb-dev] Shared Process plugin between Linux and BSD

I am communicating with Kamil about the possibility of sharing code between the two plugins. We plan to have a common base class for the shared functionality between the OSs. I have asked Kamil to perform this experiment, so we can identify which parts of the code can be shared in the first place.

Re: [lldb-dev] Shared Process plugin between Linux and BSD

On 15 December 2016 at 14:14, Kamil Rytarowski wrote: > On 15.12.2016 14:14, Pavel Labath wrote: 2. PTRACE_SETSIGINFO - equivalent currently unsupported, I will need to add support for it in ptrace(2). >> This value is currently only used in logging code, so we can just >> remove it

Re: [lldb-dev] logging in lldb

Just to let you know, I will be on vacation until the end of the year, so probably will not respond to any comments until January. If you have any concerns, do let me know, as I'd like to get started when I get back. pl On 13 December 2016 at 16:32, Pavel Labath wrote: > Hello again, > > I'd to

Re: [lldb-dev] [RFC] Delete the "testcases" symlink

On 15 December 2016 at 19:11, Zachary Turner via lldb-dev wrote: > It's definitely possible to (at worst) shorten the path if we say we don't > care about supporting other languages (i'm fine saying that for now unless > someone comes along with a serious committment to support and maintaining > o

Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

Nice catch. I think this backtrace should be enough to bring the problem to the attention of the kernel developers. Have you tried contacting them already? I can help you with that if you want. On 6 January 2017 at 23:34, Eugene Birukov wrote: > Hi, > > > It seems the problem is related to trans

Re: [lldb-dev] logging in lldb

Happy new year everyone. :) I have refreshed the implementation at with something more polished. I consider this almost-ready, I just need feedback on a couple of details: - log->Warning/Debug/Error/Verbose: Currently we have a large number of printf-style loggin

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

Hello Eugene, I have been aware of this problem for a while, but I haven't found a really good solution so far, partially due to lack of a good repro case -- I think your analysis has helped me with this, and I am finally starting to piece together the sequence of events leading to the crash. If y

Re: [lldb-dev] ELF header does not hold big modules

Hello Eugene, On 21 January 2017 at 00:42, Eugene Birukov wrote: > Hello, > > > I have a core dump that LLDB cannot open because it contains more than 64K > sections. The "readelf" utility gives me the output in the end of this > message. It seems that the actual number of program headers and the

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

On 20 January 2017 at 18:34, Eugene Birukov wrote: > Hello Pavel, > > > Thanks for the reply. Unfortunately I cannot share the core dump with you. > No problem, I think this discussion has helped me understand the problem, and it shouldn't be too hard to reproduce it locally. Now I just need to f

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

My fix was just correcting places Kamil forgot to update (or updated over-excessively). It does not touch the root problem. That said, our windows bot is building lldb with vs2015. It does not seem to have a problem with this. On 8 Februar

Re: [lldb-dev] [cfe-dev] [Release-testers] [4.0.0 Release] Release Candidate 2 has been tagged

Ed may be able to elaborate on lldb+freebsd state of things. All I can say is these tests did not exist in 3.9, so I wouldn't call this a regression. (Well... technically, a similar test existed, but it was run by a different test runner which I believe is not hooked up to the command you are runn

Re: [lldb-dev] Why is function not present in target?

On 10 February 2017 at 12:30, Ramkumar Ramachandra via lldb-dev wrote: > Hi, > > This has been the source of much frustration, but I can't quite figure out > why my toString() member function is not present in the target, according to > lldb. The other functions in the compile unit are used and pr

Re: [lldb-dev] Why is function not present in target?

Interesting. So it looks like something was removing your function. I don't know much about how linking works on mac, so I cannot say whether that's supposed to be like that or not. Maybe one of the apple folks will jump in and enlighten us. cheers, pavel On 10 February 2017 at 16:24, Ramkumar Ra

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

Every time you use the "expr" command, we compile a tiny c++ code snippet inject it into the target process and execute it. If you type "log enable lldb expr" you should be able to follow how exactly that works. You can use pretty much any c++ construct in the expression including declaring variabl

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

Making the code persist is easy - that's sort of what expr --top-level does. The tricky part is getting your code to execute. When you evaluate expressions interactively, we manually modify the registers (PC being the most important one) to point to the code you want to execute. If you want it to

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

Try this for size: $ bin/lldb /tmp/a.out (lldb) target create "/tmp/a.out" Current executable set to '/tmp/a.out' (x86_64). (lldb) b main Breakpoint 1: where = a.out`main + 4 at a.cc:6, address = 0x00400531 (lldb) pr la Process 22550 launched: '/tmp/a.out' (x86_64) Process 22550 stopped *

Re: [lldb-dev] About lldbHost

I agree that the next module that needs figuring on is the host one. However I am not sure if the decision on what to put in what module should be motivated by the FileSpec class, as I think it's current interface has a some issues, and our choice on how to resolve them can greatly affect what thin

Re: [lldb-dev] About lldbHost

Right, I see. In that case, I guess my response would be "let's wait and see how things look like after FileSpec is moved". I kinda like how we have the all the host code in a separate module (I expect we will have a lot more of it than llvm), but I am not against it if it turns out there is no ot

Re: [lldb-dev] About lldbHost

I prefer free functions as well, but I think switching FileSpec to that would be a non-trivial task. If you want to try it out I would encourage it, but I don't think it's a requirement. On 15 February 2017 at 15:41, Zachary Turner wrote: > Having FileSpec in Utility and FileSystem in Host would

Re: [lldb-dev] About lldbHost

On 15 February 2017 at 18:20, Greg Clayton wrote: > > On Feb 15, 2017, at 10:14 AM, Zachary Turner wrote: > > I think the main improvement that it provides is that you need *something* > which represents only a path. Because we use FileSpecs to refer to paths on > remote machines, and then what

[lldb-dev] Too many ModuleSP references

Hello all, I've been debugging the newly added TestStepOverBreakpoint.py, which has been failing on windows, for a very prosaic reason: after the test completes, we are unable to run "make clean" because lldb still holds the file open. After some debugging, I've found that this happens because th

Re: [lldb-dev] Too many ModuleSP references

Thank you for the feedback. I'll look into how to get the expressions cleared when the breakpoint locations get unresolved. I can also switch the breakpoints to a weak_ptr if you think that is worthwhile, but one of the two fixes is enough for me at the moment. regards, pavel On 22 February 2017

Re: [lldb-dev] DWARF v5 unit headers

Thanks for the heads up Paul. I've tried your change on linux, and I don't see any regressions, so it should be safe to land. Regarding the test failures you were seeing: what is the system you were testing this on? If it is linux, could you send me the list of failures -- I'd be interested in get

Re: [lldb-dev] Recent Linux test failures

Thank you Paul. Could you paste the output of the "check-lldb" command? The LogTest.cpp thing looks like a gcc issue I ran into earlier, I'll have that fixed shortly. cheers, pl On 28 February 2017 at 17:39, Robinson, Paul via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Also, if I do 'ninja c

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

On 16 March 2017 at 00:43, Kamil Rytarowski wrote: > On 01.03.2017 10:13, Kamil Rytarowski wrote: >> Hello, >> >> The contract for the LLDB port on NetBSD has been prolonged by The >> NetBSD Foundation. The additional time will cover the features that were >> delayed in order to address blockers t

Re: [lldb-dev] C++ method declaration parsing

I think clang-format's parser would be a better candidate for code reuse, but even that might be too much, as we don't need that level of detail (basically we just need to split the name into function name, return type and argument list), and we can make a lot of simplifying assumptions here (e.g.

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

On 16 March 2017 at 21:43, Kamil Rytarowski wrote: > On 16.03.2017 11:55, Pavel Labath wrote: >> What kind of per-process events >> are we talking about here? > > I'm mostly thinking about ResumeActions - to resume the whole process, > while being able single-stepping desired thread(s). > > (We al

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

On 17 March 2017 at 16:23, Ted Woodward wrote: > > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of > Pavel Labath via lldb-dev > Sent: Friday, March 17, 2017 4:48 AM > > > On 16 March 2017 at 21:43, Kamil Rytarowski wrote: > >> I imagine

Re: [lldb-dev] process launch fail with msg "not contain any host architecture"

Hello Chunseok, lldb-server went through a lot of changes since 3.8. Could you check whether it works for you with latest master (or at least 4.0). I can't guarantee it will work, but I'm sure you'll at least get a different error message. Then we can start figuring out what's going wrong. cheers

Re: [lldb-dev] Temporary log channel...

That looks like one of my changes. While refactoring the channels (I am done with that now btw), I deleted some unused categories, mostly in the "posix" channel, but this I deleted this one as well.. I didn't call that out explicitly during review, as it seemed easy to add back those that turn out

Re: [lldb-dev] Linux issues where I am not getting breakpoints...

Are you sure this is not just an artifact of stdio buffering? I tried the same experiment, but I placed a real log statement, and I could see that all the LoadModuleAtAddress calls happen between the $T and $c packets in the gdb-remote packet sequence. The module loading should be synchronous, so

Re: [lldb-dev] Linux issues where I am not getting breakpoints...

On 11 April 2017 at 15:56, Greg Clayton wrote: > > On Apr 11, 2017, at 5:33 AM, Pavel Labath wrote: > > Are you sure this is not just an artifact of stdio buffering? I tried the > same experiment, but I placed a real log statement, and I could see that > all the LoadModuleAtAddress calls happen

Re: [lldb-dev] Linux issues where I am not getting breakpoints...

While definitely not a prime example of StringRef usage, it is not strictly a bug either. Future calls of getopt will modify the value of optarg, but the actual string it points to (will have pointed to) remains unchanged as that is just some member of the initial argv array. That said, I have no

Re: [lldb-dev] Improve performance of crc32 calculation

Improving the checksumming speed is definitely a worthwhile contribution, but be aware that there is a pretty simple way to avoid computing the crc altogether, and that is to make sure your binaries have a build ID. This is generally as simple as adding -Wl,--build-id to your compiler flags. +1 to

Re: [lldb-dev] Parallelize loading of shared libraries

I've have looked at paralelization of the module loading code some time ago, albeit with a slightly different use case in mind. I eventually abandoned it (at least temporarily) because I could not get it to work correctly for all use cases. I do think that doing this is a good idea, but I think it

Re: [lldb-dev] LLDB performance drop from 3.9 to 4.0

Bisecting the performance regression would be extremely valuable. If you want to do that, it would be very appreciated. On 12 April 2017 at 20:39, Scott Smith via lldb-dev wrote: > For my app I think it's largely parsing debug symbols tables for shared > libraries. My main performance improveme

Re: [lldb-dev] Improve performance of crc32 calculation

What we need is the ability to connect a stripped version of an SO to one with debug symbols present. Currently there are (at least) two ways to achieve that: - build-id: both SOs have a build-id section with the same value. Normally, that's added by a linker in the final link, and subsequent stri

Re: [lldb-dev] Running check-lldb

It looks like we are triggering an assert in llvm on a debug build. I'll try to track this down ASAP. On 18 April 2017 at 21:24, Scott Smith via lldb-dev wrote: > I'm trying to make sure some of my changes don't break lldb tests, but I'm > having trouble getting a clean run even with a plain ch

Re: [lldb-dev] Running check-lldb

It is on purpose, although whether that purpose is worthwhile is debatable... We chose to run release builds there so to align the bots closer to the binaries we release. Unfortunately, it does mean we run into situations like these... In any case, I have now a patch up for fixing one of the cras

Re: [lldb-dev] LLDB performance drop from 3.9 to 4.0

Thank you very much for tracking this down. +1 for making UniqueCStringMap speak ConstString -- i think it just makes sense given that it already has "unique" in the name. ConstString already has a GetStringRef accessor. Also adding a conversion operator may be a good idea, although it probably w

Re: [lldb-dev] Running check-lldb

On 19 April 2017 at 19:15, Scott Smith wrote: > A combination of: > 1. Updating to a known good release according to buildbot > 2. using Ubuntu 14.04 > 3. compiling release using clang-4.0 > I'd hope that the compiler used to build lldb does not matter. If you see any differences due to this fact

Re: [lldb-dev] Running check-lldb

On 20 April 2017 at 15:01, Tamas Berghammer wrote: > AFAIK the Ubuntu 14.04 cmake builder runs tests using ToT clang (built on > the build bot) as step test3 and test4 and it seems to be green so if you > are seeing different result then I would expect it to be caused by a > configuration differe

Re: [lldb-dev] LLDB-MI remote debugging on Linux

Hi, this is a known problem and somewhat embarrassing problem, but unfortunately we haven't had time to look at that yet. The code that is doing that was added to support loading of the vdso, which is only present in the application memory (and it is a full elf file). I don't think anybody has rea

Re: [lldb-dev] Running check-lldb

On 20 April 2017 at 19:42, Scott Smith wrote: > Sorry, I take that back. I forgot to save the buffer that ran the test > script. Oops :-( > > I get a number of errors that make me think it's missing libc++, which > makes sense because I never installed it. However, I thought clang > automatica

Re: [lldb-dev] New build machine in the cluster lldb-amd64-ninja-netbsd8

On 22 April 2017 at 23:57, Kamil Rytarowski via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello, > > I'm in process of attaching new build machine lldb-amd64-ninja-netbsd8. > > It will run prerelease of NetBSD/amd64 8.0 (as of today 7.99.70) with > the GNU toolchain. > > Once the new one setup

Re: [lldb-dev] LLDB-MI remote debugging on Linux

On 20 April 2017 at 18:59, Scott Funkenhauser wrote: > Hey Pavel, > > What would be a reasonable solution? > > Does having the lldb-server read the shared libraries from disk (instead > of from the process's memory) sound sensible? > > What you are describing should already be the case -- lldb k

Re: [lldb-dev] Parallelizing loading of shared libraries

It's the gdb jit interface breakpoint. I don't think there is a good way to scope that to a library, as that symbol can be anywhere... On 27 April 2017 at 18:35, Jim Ingham via lldb-dev wrote: > Somebody is probably setting an internal breakpoint for some purpose w/o > scoping it to the shared

Re: [lldb-dev] New build machine in the cluster lldb-amd64-ninja-netbsd8

Indeed, master restart is needed every time you update the zorg repository. cheers, pl On 28 April 2017 at 03:40, Kamil Rytarowski wrote: > On 24.04.2017 11:42, Pavel Labath wrote: >> >> >> On 22 April 2017 at 23:57, Kamil Rytarowski via lldb-dev >> mailto:lldb-dev@lists.llvm.org>> wrote: >> >>

<    1   2   3   4   5   6   >