Re: [lldb-dev] test results look typical?

2015-08-25 Thread Pavel Labath via lldb-dev
There is no separate option, it should just work. :) I'm betting you are still missing some package there (we should document the prerequisites better). Could you send the error message you are getting so we can have a look. cheers, pl On 25 August 2015 at 16:20, Todd Fiala via lldb-dev

Re: [lldb-dev] Inquiry for performance monitors

2015-10-21 Thread Pavel Labath via lldb-dev
[ Moving this discussion back to the list. I pressed the wrong button when replying.] Thanks for the explanation Ravi. It sounds like a very useful feature indeed. I've found a reference to the debugserver profile data in GDBRemoteCommunicationClient.cpp:1276, so maybe that will help with your

Re: [lldb-dev] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback

2015-11-16 Thread Pavel Labath via lldb-dev
Thanks for the heads-up Mikhail. Ravi, this looks like your code. Could you take a look at this? pl On 16 November 2015 at 16:24, Mikhail Filimonov via lldb-dev wrote: > Hi guys and thank you for the excellent community project! > > > > Recently I’ve stumbled on a

Re: [lldb-dev] Is it possible to set a python script handler for a signal stop in lldb?

2015-11-16 Thread Pavel Labath via lldb-dev
I believe there is no such thing at the moment. It might be interesting to add one though, to enable "conditional" signal handling. E.g., when an application handles it's own SIGSEGVs, and you want to pass those quietly, but you want to stop for real problems (for some definition of "real"). pl

Re: [lldb-dev] Is there a way to inspect signaled stack?

2015-11-16 Thread Pavel Labath via lldb-dev
Hi Eugene, the libc signal trampoline should have .eh_frame unwind info (I am assuming this is x86_64 btw), and last time I looked at it, it seemed that it should be able to handle sigaltstack(). However, I have never tested this, so it's quite possible there is still some bug hidden there. Could

Re: [lldb-dev] Attaching to a stopped (cored) process hangs lldb-server

2015-11-03 Thread Pavel Labath via lldb-dev
I'm following this discussion, but I don't yet understand what is going on here completely. What I am sure is that the problem here is not the S+ state, as that just means "interruptible sleep, foreground process", and a lot of processes have that state and we attach to them just fine. I would

Re: [lldb-dev] TestRaise.py test_restart_bug flakey stats

2015-10-19 Thread Pavel Labath via lldb-dev
I have created this test to reproduce a race condition in ProcessGDBRemote. Given that it tests a race condition, it cannot be failing 100% of the time, but I agree with Tamas that we should keep it as XFAIL to avoid noise in the buildbots. pl On 19 October 2015 at 12:30, Tamas Berghammer via

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

2015-10-08 Thread Pavel Labath via lldb-dev
Hi, I believe the SIGILL problem you are referring to is the problem described in bug . This was fixed in r244875, but unfortunately, this was after 3.7 branch so this patch did not make it there. I recommend to try the master branch, I think this

Re: [lldb-dev] lldb tests and tear down hooks

2015-10-21 Thread Pavel Labath via lldb-dev
I think we can remove these, provided there is a way to mimic the functionality they are used for now, which I think shouldn't be hard. Anything which was set up in the setUp() method should be undone in tearDown(). Anything which was set up in the test method, can be undone using a try-finally

Re: [lldb-dev] [Lldb-commits] [lldb] r248028 - Make libc++ tests skip themselves if libc++ is not actually loaded in the target

2015-10-21 Thread Pavel Labath via lldb-dev
[moving this to lldb-dev for more visibility.] Sorry, I was in a hurry yesterday, so I did not explain myself fully. Let me try to elaborate. > What I am trying to avoid here is getting useless noise in build automation where test cases proclaim their failure, which however tells us nothing of

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

2015-10-13 Thread Pavel Labath via lldb-dev
Sure, fair enough. If you have made a small repro case already though, it would be great if you could file a bug about it, so we don't forget it. pl On 12 October 2015 at 23:23, Eugene Birukov wrote: > I tried to repro it using standard LLDB client on a simple program

Re: [lldb-dev] Test suite rebuilding test executables many times

2015-08-26 Thread Pavel Labath via lldb-dev
On 26 August 2015 at 06:14, Zachary Turner via lldb-dev lldb-dev@lists.llvm.org wrote: I'll wait and see if anyone can remember which tests rebuild binaries on purpose. Otherwise I will try to look through them and see if I can figure it out. TestInferiorChanged is one that I remember. I

Re: [lldb-dev] lldb::SBDebugger::Terminate() hangs in deadlock

2015-09-28 Thread Pavel Labath via lldb-dev
Hi, Thanks for the report. Since you are suspecting a deadlock, could you post a backtrace of all the threads (thread apply all backtrace). It would be best to move this discussion to a bug in llvm.org/bugs. > I am currently using svn revision 247535 of llvm and lldb, and I know that my > code

[lldb-dev] correct event sequence on process detach

2015-09-28 Thread Pavel Labath via lldb-dev
Hello all, The following question came up while fixing up handling of process detach. when detaching from a running process, on some platforms LLDB needs to stop it first. Is this stop something that should be hidden from the public view or not? I.e. if the process state is Running, and I do a

Re: [lldb-dev] possible test runner speedup

2015-09-28 Thread Pavel Labath via lldb-dev
Hi, Interesting results. We were discussing the same thing last week. I was somewhat skeptical to the ideal as I am afraid of increased flakyness -- LLDB has hardcoded timeout values in a lot of places, and with increased cpu contention, we might start to see this code failing because the other

Re: [lldb-dev] Exclusively build and install LLDB?

2015-12-02 Thread Pavel Labath via lldb-dev
On 2 December 2015 at 16:19, Todd Fiala wrote: > Sorry for being late the the party here. > > Sean Callanan and some of the other members can comment more on this, but > LLDB's expression parser for C/C++ is going to need access to the clang > include headers, so somehow

Re: [lldb-dev] New test summary results formatter

2015-12-03 Thread Pavel Labath via lldb-dev
There is already code that enforces unique names (see dotest.py:1255). I added this a while back because we were getting test flakyness because of that. I don't remember the exact reason but I think it had something to do with the log file names clashes, as all logs are placed in the same folder.

Re: [lldb-dev] BasicResultsFormatter - new test results summary

2015-12-09 Thread Pavel Labath via lldb-dev
If it's not too much work, I think the extra bit of noise will not be a problem. But I don't think it is really necessary either. I assume the actual flip will be a small change that we can back out easily if we notice troubles... After a sufficient grace period we can remove the old formatter

Re: [lldb-dev] Separating test runner and tests

2015-12-11 Thread Pavel Labath via lldb-dev
Sounds like a reasonable thing to do. A couple of tiny remarks: - when you do the move, you might as well rename dotest into something else, just to avoid the "which dotest should I run" type of questions... - there is nothing that makes it obvious that "engine" is actually a "test running

Re: [lldb-dev] BasicResultsFormatter - new test results summary

2015-12-11 Thread Pavel Labath via lldb-dev
Todd, I've had to disable the new result formatter as it was not working with the expected timeout logic we have for the old one. The old XTIMEOUT code is a massive hack and I will be extremely glad when we get rid of it, but we can't keep our buildbot red until then, so I've switched it off. I

Re: [lldb-dev] marking new summary output for expected timeouts

2015-12-14 Thread Pavel Labath via lldb-dev
Hi, we've had an unrelated breaking change, so the buildbots were red over the weekend. I've fixed it now, and it seems to be turning green. We've also had power outage during the weekend and not all of the buildbots are back up yet, as we need to wait for MTV to wake up. I'd like to give this at

Re: [lldb-dev] BasicResultsFormatter - new test results summary

2015-12-14 Thread Pavel Labath via lldb-dev
Hi, thanks a lot for fixing the timeout issue on such a short notice. I didn't think I'd find myself defending them, as I remember being quite upset when they went in, but they have proven useful in stabilising the build bots, and I think it's likely you may need them as well. I'll try to now add

Re: [lldb-dev] BasicResultsFormatter - new test results summary

2015-12-14 Thread Pavel Labath via lldb-dev
On 14 December 2015 at 16:19, Todd Fiala wrote: >> We would lose the ability to individually expect "failures" and >> "timeouts", but I don't think that is really necessary, and I think it >> will be worth the extra maintainability we get from the fact of having >> fewer

Re: [lldb-dev] Patch for addressing format warnings on 32-bit

2016-01-04 Thread Pavel Labath via lldb-dev
I believe %z will not work on MSVC 2013, which we are still using on windows. pl On 28 December 2015 at 18:32, William Dillon via lldb-dev wrote: > Hi Todd, > > The example I put in my last email is one of a few (maybe one more) > instances where the existing code casts

Re: [lldb-dev] Linux core dump doesn't show listing when loaded

2015-11-25 Thread Pavel Labath via lldb-dev
There has been some discussion in , as to what get's printed when, but I don't think any changes went in yet. I wouldn't be opposed to bringing back the old behavior (or keeping the current one, for that matter), but I feel that any change here should consistent

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

2015-11-18 Thread Pavel Labath via lldb-dev
On 18 November 2015 at 09:02, Zachary Turner via lldb-dev wrote: > On Tue, Nov 17, 2015 at 8:03 PM Todd Fiala wrote: >> >> Nothing concrete at the moment; however, it could be interesting to look >> at the clang community and see what could be done

Re: [lldb-dev] Exclusively build and install LLDB?

2015-11-23 Thread Pavel Labath via lldb-dev
I believe that for purposes of building distribution packages you should use the out-of-tree mode of building lldb. This means, you build llvm and clang separately, and then point your LLDB build to their installation path with LLDB_PATH_TO_LLVM_BUILD and LLDB_PATH_TO_CLANG_BUILD variables. This

Re: [lldb-dev] --no-stdin mode kicks in without warning (?)

2015-11-24 Thread Pavel Labath via lldb-dev
It more likely has something to do with LLDB being multi-threaded and failing to push the process IO handler on stack. It sounds like a bug, but it's hard to diagnose without more info. Could you try enabling logging (log enable -f some_file.txt lldb process) and send that over when this problem

Re: [lldb-dev] Using control+left/right arrow to jump between words in the prompt

2016-01-11 Thread Pavel Labath via lldb-dev
LLDB's command line editing leaves a lot to be desired. The thing which annoys me the most is that you get bogus characters inserted if you press the wrong character (e.g. left arrow) in the incremental search (^R) mode. > Is it a feature that would be welcome? Is this an offer to implement the

Re: [lldb-dev] Hang during attach

2016-01-11 Thread Pavel Labath via lldb-dev
Also including the list... On 11 January 2016 at 09:30, Pavel Labath wrote: > Hi, > > there was a race condition in 3.7, which sometimes caused a hang > during process attach. This should be fixed in r246756, but this fix > is not available in the 3.7 branch. I think if you

Re: [lldb-dev] LLDB testsuite failing to import lldb python module

2016-06-09 Thread Pavel Labath via lldb-dev
Hi, from your description, it sounds to me like you are copying the the liblldb library into another location that the one it was built. Is that right? My guess would be that you are not copying all the necessary files. Specifically, it sounds like you have missed the lib/pythonX.Y folder, which

Re: [lldb-dev] Incorrect libclang dependency in standalone build

2016-06-10 Thread Pavel Labath via lldb-dev
This is a side-effect of the cmake version bump to 3.4. Cmake now errors out on non-existing targets. You'll need to figure out a way to avoid adding this target to the dependency list. Patches welcome. :) pl On 10 June 2016 at 16:20, Eugene Zelenko via lldb-dev wrote:

Re: [lldb-dev] Incorrect libclang dependency in standalone build

2016-06-13 Thread Pavel Labath via lldb-dev
I don't think you need to concern yourself with that comment. We should make the dependency graph cleaner, but that is not something related to your current problem. IIUC, in case of a standalone build, you can assume that the relevant target was already built, and you don't need to add it to the

Re: [lldb-dev] Ubuntu buildbot timing after -gmodules

2016-05-26 Thread Pavel Labath via lldb-dev
That's good news. We probably have some reserves left in there due to the scheduling of tests of different size. On 26 May 2016 at 16:30, Todd Fiala wrote: > Hi Pavel, > > FYI - > > I took a look at the ubuntu 14.04 x86_64 cmake buildbot before and after the > -gmodules

Re: [lldb-dev] Does LLDB work on Ubuntu 14.04 x86_64?

2016-01-18 Thread Pavel Labath via lldb-dev
Hi, thanks for the report. Lldb does indeed work on linux x86_64 (and plenty more), but I think noone tests it with your given combination of cmake flags. I've managed to reproduce your problem and fix it with , but please give it a go to make sure it works for

Re: [lldb-dev] lldb tests and tear down hooks

2016-01-15 Thread Pavel Labath via lldb-dev
On 14 January 2016 at 21:52, Zachary Turner via lldb-dev wrote: > So what if tests could be *either* a method *or* a nested class. If it's a > nested class, it could provide setUp, tearDown, and run methods. These > setup and teardown methods can do whatever they want

Re: [lldb-dev] Inquiry for performance monitors

2016-02-04 Thread Pavel Labath via lldb-dev
On 4 February 2016 at 10:04, Ravitheja Addepally wrote: > Hello Pavel, > In the case of expression evaluation approach you mentioned > that: > 1. The data could be accessible only when the target is stopped. why is that > ? If I understand the approach

Re: [lldb-dev] Problem running the test suite on Linux.

2016-02-04 Thread Pavel Labath via lldb-dev
In addition to flaky tests, I think some of these are just decorated too broadly (e.g. it's marked expectedFailureLinux, but fails only on i386 with gcc). I occasionally enable tests that I see are passing consistently, but I am currently more worried about tests failing unexpectedly than

Re: [lldb-dev] Inquiry for performance monitors

2016-02-04 Thread Pavel Labath via lldb-dev
On 4 February 2016 at 12:49, Abhishek Aggarwal wrote: > Hello Pavel > > As per my understanding, instead of doing it by expression evaluation > if the code (to enable pt and gathering the raw traces) is written on > lldb-server side, then also lldb-server will have to wait

Re: [lldb-dev] Sending input to the process being debugged

2016-02-04 Thread Pavel Labath via lldb-dev
Hi, I think you will have to provide a bit more context to get help. I.e., what is the full sequence of debugger commands you are issuing, and what is the inferior process doing? cheers, pl On 3 February 2016 at 22:03, John Lindal via lldb-dev wrote: > When I use

Re: [lldb-dev] Debug events in synchronous mode?

2016-02-04 Thread Pavel Labath via lldb-dev
Hi, I am not sure what are the "official" rules, but the general idea is that you need not concern yourself too much with events when you are in synchronous mode. In synchronous mode, you can be sure that by the time target.Launch() returns, the process will be stopped (or dead, or something

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

2016-02-04 Thread Pavel Labath via lldb-dev
Hi all. we (android lldb team) are starting to transition to VS2015 as well. For now, the plan is to stick to python 2.7, but if we encounter problems there, the backup plan is to go to python 3 as well. Until then (I estimate that will take 1--2 weeks) our buildbot

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

2016-02-04 Thread Pavel Labath via lldb-dev
The patch is in the attachment. The timezone part seems pretty non-controversial. The _PyVerify_fd thing seems more scary, but I basically copied that part out of python3, so I assume they know what they are doing. With this I can compile and run the python and it appears to be working. The real

Re: [lldb-dev] Understanding debugger launch events sequence

2016-01-29 Thread Pavel Labath via lldb-dev
Hi Jeffrey, I see a couple of problems with the way you are using the lldb's API. The main problem is you are launching the target via the command-line API, which does not allow you to specify the listener upon creation. When you start it this way all events go to the default debugger listener

Re: [lldb-dev] Patch to fix REPL for ARMv7 & ARMv6 on linux

2016-01-26 Thread Pavel Labath via lldb-dev
+ Omair I don't really understand arm (sub)-architectures or REPL. The patch seems mostly harmless, but it also feels like a hack to me. A couple of questions: - why does this only pose a problem for REPL? - If I understand correctly, the problem is that someone is looking at the architecture

Re: [lldb-dev] Bad state of release 3.7.1?

2016-01-26 Thread Pavel Labath via lldb-dev
Hello Jeffrey, we did test 3.7 before letting it out, bug this bug was fixed only after the release date, so the fix is not present in 3.7. I think you have a couple of options now: - backport the patch to 3.7: should be pretty easy and I expect it to "just work" - llvm 3.7 + lldb 3.8: this won't

Re: [lldb-dev] Patch to fix REPL for ARMv7 & ARMv6 on linux

2016-02-01 Thread Pavel Labath via lldb-dev
On 30 January 2016 at 00:13, William Dillon wrote: > In a very real sense, no information is lost here. That is exactly the reason why it looks very hackish. :) It looks to me like you are trying to work around some other bug, probably in the code that consumes the

Re: [lldb-dev] Inquiry for performance monitors

2016-02-01 Thread Pavel Labath via lldb-dev
-pt-dump" could just give a raw dump all of >> > > history for one or more threads (again, add options and arguments as >> > > needed >> > > to this command). The python code could bridge to C and use the intel >> > > libraries that know how to p

Re: [lldb-dev] Understanding debugger launch events sequence

2016-02-01 Thread Pavel Labath via lldb-dev
On 29 January 2016 at 18:43, Jeffrey Tan wrote: > Thanks Jim. Is this true for other platforms? Our IDE is going to support > Mac and Linux and may extend to Windows some time later. AFAIK, windows spawns a separate thread to do the actual debugging, but this is hidden

Re: [lldb-dev] Inquiry for performance monitors

2016-02-01 Thread Pavel Labath via lldb-dev
be added to any target that supports this. The plug-in could >> >> > > install a set >> >> > > of LLDB commands. To see how to create new lldb command line >> >> > > commands in >> >> > > python, see the section named "CREATE A

Re: [lldb-dev] Module Cache improvements - RFC

2016-02-25 Thread Pavel Labath via lldb-dev
Thanks for the feedback, and sorry about the slow response. After some internal discussions, it looks like we are not going to go forward with this approach at the moment. cheers, pl On 24 February 2016 at 11:16, Tamas Berghammer via lldb-dev wrote: > I completely

Re: [lldb-dev] No stopping event during launch(stop_at_entry=True) on Linux?

2016-02-24 Thread Pavel Labath via lldb-dev
This is a known bug (bugzilla is slugish right now, so I can't look up the number). The stopped event does not seem to get through most of the times, although the stop is actually performed. I am afraid I can't offer any workaround for the time being... On 24 February 2016 at 07:36, Jeffrey.fudan

Re: [lldb-dev] clang-format now supports return type on separate line

2016-01-22 Thread Pavel Labath via lldb-dev
Apparently, you can also disable the formatting of a piece of code by a magic comment. Could be quite useful for those tables. From the docs: - Clang-format understands also special comments that switch formatting in a delimited range. The code between a comment // clang-format off or /*

Re: [lldb-dev] Getting lldb tests working on Hexagon

2016-01-20 Thread Pavel Labath via lldb-dev
What is the sequence of lldb commands you use to innitiate a hexagon debug session normally? Do you need to set a custom platform (platform select XXX)? If so, then you need to look into --platform-name (and possibly --platform-url, --platform-working-dir) parameter, and possibly add some support

Re: [lldb-dev] marking new summary output for expected timeouts

2016-01-20 Thread Pavel Labath via lldb-dev
Hi, I have removed all of our expected timeouts from dosep.py (there are still some freebsd and darwin ones left, but I don't know If anyone is looking at those), so I think we're not using any part of the old test runner at the moment. All clear for removal on our part. pl On 14 December 2015

Re: [lldb-dev] Spurious process state change events

2016-01-20 Thread Pavel Labath via lldb-dev
Hello, thanks for confirming my suspicions. Sending the extra running event seems quite annoying to me as well, but it is how things work at the moment. And the problem does not seem to be linux-specific. This is the sequence of events I get on a Mac, when running over a conditional breakpoint

Re: [lldb-dev] Details on rdar://18684408?

2016-02-19 Thread Pavel Labath via lldb-dev
Linux is ok as well. I've enabled the tests everywhere except windows. Please add your arch back if you notice problems. pl On 18 February 2016 at 19:37, Zachary Turner via lldb-dev wrote: > Does not work on Windows yet, so please leave it xfail'ed on windows for now >

Re: [lldb-dev] problem with quoted strings in setting target.run-args

2016-02-19 Thread Pavel Labath via lldb-dev
Hi Ted, I did some improvements in this area a year ago, which (I hope) made things better, but they are still not perfect (hint: try running: settings set target.run-args '"') [that's ]. I tried to finish the job, but it ended up being too complicated, for the reasons you mention above... I

Re: [lldb-dev] lldb-server stripped binary size: AArch64 ~16Mb vs ARM ~9 Mb

2016-03-01 Thread Pavel Labath via lldb-dev
Hi, so the problem here is that we are currently relying on the linker to remove code that we don't need, and it can't always do a good job in figuring out which code is not used due to complex dependencies. So, innocent-looking changes in the code can pull in lots of transitive dependencies,

Re: [lldb-dev] LLDB + UE4 on Android

2016-03-10 Thread Pavel Labath via lldb-dev
Hi Mikhail, Modifying the build tool to include the build ID would probably be the easiest solution to your problem. Please not that both the stripped AND unstripped versions of the module need to have the (same) .note.gnu.build-id section. I am not familiar with the build tool, but "fixing" this

Re: [lldb-dev] LLDB + UE4 on Android

2016-03-11 Thread Pavel Labath via lldb-dev
So, from the error message it looks like lldb is getting confused by the debug information inside the executable. I don't have any special hints for debugging that, I think the usual process of attaching the debugger, examining the backtrace, and seeing what data is triggering the assert would

Re: [lldb-dev] unable to build lldb 3.8

2016-03-16 Thread Pavel Labath via lldb-dev
This is just a wild guess, but could you try running cmake with -DLLVM_LIBDIR_SUFFIX=64. I remember we've had a need for that in the past for systems which store libraries in lib64. Some provisions were put in place to autodetect it, but i'm not sure if they completely work. On 16 March 2016 at

Re: [lldb-dev] unable to build lldb 3.8

2016-03-16 Thread Pavel Labath via lldb-dev
Hi Peter, thank you for the report, you are writing to the right list. Unfortunately, I am not aware of anyone in LLDB, who actually uses the "make install" functionality, so it's very well possible that it's broken. I can take a look at it, but I won't be able to do that for a couple of weeks

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

2016-03-29 Thread Pavel Labath via lldb-dev
Zachary, all, after overcoming some problems, mostly unrelated to MSVC, we have finally managed to switch to VS2015. I think that means there are no more VS2013 users remaining. Given that, shall we start the process to formally allow c++ features, which were blocked due to VS2013 until now? I am

Re: [lldb-dev] SBProcess::Detach kills target

2016-03-31 Thread Pavel Labath via lldb-dev
We are not sending the SIGHUP, it is automatically getting sent by the OS when the master end of the pty gets closed. The reason you are not seeing this in the attach scenario is that we do not intercept inferior stdio in this case (it's not possible, or desirable, since the process is already

Re: [lldb-dev] Green Dragon LLDB Xcode build update: TSAN support

2016-04-06 Thread Pavel Labath via lldb-dev
On 6 April 2016 at 06:23, Todd Fiala wrote: > Okay, thanks all. > > FWIW I am running them on the OS X side. I haven't seen any stability > problems yet. I'd also expect them to be very stable, much more like a > compiler test, since there are far fewer parts in a

Re: [lldb-dev] [RFC] Contributing platform support for Linux on SystemZ

2016-04-11 Thread Pavel Labath via lldb-dev
Hello Ulrich, It's exciting to see support for new platforms being added to LLDB. I've had a brief glance at the patch set and I was surprised at how few changes you had actually needed to make to lldb core to support this. The patches look good at a first glance, but they will need to be

Re: [lldb-dev] Review of API and remote packets

2016-04-11 Thread Pavel Labath via lldb-dev
I think we should reuse packets from the gdb protocol whereever it makes sense. So, if they fit your needs (and a quick glance seems to confirm that), then I think you should use them. On 11 April 2016 at 15:28, Ravitheja Addepally wrote: > Hello, >Regarding the

Re: [lldb-dev] Review of API and remote packets

2016-04-13 Thread Pavel Labath via lldb-dev
Do we need the server to know about the user ids we handed out to the SB API client? AFAIK, you cannot have multiple traces of the same thread running concurrently, so a thread-id should uniquely identify a trace. The user id can then stay a client thing for abstracting the concrete implementation

Re: [lldb-dev] Weird stop stack while hitting breakpoint

2016-04-08 Thread Pavel Labath via lldb-dev
Ok, so the reason for this behavior seems to be that the process hits two breakpoints simultaneously: - the breakpoint you have set and you are expecting to hit - an internal shared library breakpoint we use to get notified of new shared libraries * thread #1: tid = 33390, 0x7ff7dcd9f970

Re: [lldb-dev] Review of API and remote packets

2016-04-12 Thread Pavel Labath via lldb-dev
LLDB already has the QThreadSuffixSupported extension, which adds the ";thread:" suffix to a bunch of packets. We could say that if the client requests this extension, we will support it on these packets as well. Otherwise we fall back to the "Hg" thingy. I haven't looked at how hard it would be

Re: [lldb-dev] Is it ok to use lldb_private from the driver?

2016-03-20 Thread Pavel Labath via lldb-dev
Are using we using any other signal that SIGINT on windows currently? I seem to remember all the fancy signals (SIGTSTP, SIGWINCH,...) being ifdef-ed out on windows. If the only signal we are interested about if SIGINT, then I think the API should be more higher-level than a signal() wrapper

Re: [lldb-dev] Weird stop stack while hitting breakpoint

2016-03-20 Thread Pavel Labath via lldb-dev
If you send me a small repro case, I can try to look at why is Linux different here. On 19 March 2016 at 00:46, Jim Ingham via lldb-dev wrote: > All this logic is handled in Process::HandleProcessStateChangedEvent (see > around line 1215 in Process.cpp) You shouldn’t

Re: [lldb-dev] Inquiry about Load Address

2016-03-08 Thread Pavel Labath via lldb-dev
Hi, could you give us a bit more background about what are you trying to do? It's hard to answer the question without knowing a bit more... On 8 March 2016 at 10:42, Ravitheja Addepally via lldb-dev wrote: > Hello, > I wanted to know if there is any existing API

Re: [lldb-dev] How to use the C++ API? No useful documentation?

2016-03-04 Thread Pavel Labath via lldb-dev
Hi Paul, I believe you are experiencing the same problem as a couple of other people before you (see , ). Basically, you need to ignore the events with the

Re: [lldb-dev] How to use the C++ API? No useful documentation?

2016-03-03 Thread Pavel Labath via lldb-dev
Hi Paul, I haven't followed this discussion from the start, and I am now having trouble understanding what is the issue at hand here. Could you just briefly repeat what is the problem, and maybe send the code for reproducing the problem again? Maybe I'll be able to help... pl On 3 March 2016 at

Re: [lldb-dev] Problems with core load on Linux and proposed solution

2016-03-01 Thread Pavel Labath via lldb-dev
Hi, Thanks for the report. I've had my eye set on this for a while, but unfortunately it hasn't gotten to the top of the list yet. The main reasons i was slow to respond are: - there is no test included. - I am not entirely sure about the proposed solution. It looks a bit hackish (the stop reason

Re: [lldb-dev] Green Dragon LLDB Xcode build update: TSAN support

2016-04-05 Thread Pavel Labath via lldb-dev
We're not running them yet. I'd like to add that at some point, but I haven't gotten around to that yet... On 5 April 2016 at 09:39, Tamas Berghammer wrote: > I think we don't. If we consider them stable enough for enabling them on a > buildbot AND we agree to revert

Re: [lldb-dev] SBProcess::Detach kills target

2016-03-30 Thread Pavel Labath via lldb-dev
So I have made a small test program (which does nothing but spin in a loop), and indeed it is the SIGHUP that kills it after detach. If the test program blocks the signal, then it continues running even after detach: $ cat a.c #include #include int main() { signal(SIGHUP, SIG_IGN); for

Re: [lldb-dev] Review of API and remote packets

2016-04-01 Thread Pavel Labath via lldb-dev
I second Greg's suggestions, and I have some thoughts of my own: - with the proposed API, it is not possible to get a trace for newly created threads - the process needs to be stopped first, so you can enable trace collection. There certainly are cases where this could be problematic, e.g. if you

Re: [lldb-dev] SBProcess::Detach kills target

2016-04-01 Thread Pavel Labath via lldb-dev
> It might be also possible to run an expression that will route > stdin/stdout/stderr to /dev/null before detaching if we know that we have a > master/slave pty hooked up the the inferior's in/out/err. We could run an > expression like: (At least on linux) you would also need something like:

Re: [lldb-dev] How to detach from stop mode without causing signal in inferior on Linux?

2016-03-29 Thread Pavel Labath via lldb-dev
Hi, are you doing a SBProcess.Detach() before you kill the debugger? If that doesn't help could you send me the gdb-remote packet form (execute command: log enable -f /some/file.log gdb-remote packets), so I can get a better idea of what is going on. cheers, pl On 29 March 2016 at 00:21,

Re: [lldb-dev] Hang of LLDB 3.8.0 on Debian 8

2016-03-29 Thread Pavel Labath via lldb-dev
Hi, I suspect this may be related to . Could you try removing the -DLLVM_LINK_LLVM_DYLIB=ON option and trying again? cheers, pl On 24 March 2016 at 14:52, David Jones via lldb-dev wrote: > I am trying to run LLDB from the

Re: [lldb-dev] SBProcess::Detach kills target

2016-03-29 Thread Pavel Labath via lldb-dev
There is no system restriction which prevents you from doing this. (Without any investigation) my guess would be that your inferior is dying of SIGHUP, which it receives when we close the master end of its pty. Could you check whether the behavior persists if your app blocks SIGHUP and/or you

Re: [lldb-dev] Ubuntu nightly package for lldb 3.8 has no binary

2016-04-27 Thread Pavel Labath via lldb-dev
Hi, last time I tried the prebuilt packages (it was quite a while ago), they did not work, but I had no time to figure out what's wrong with them. I think it would be super-great if someone would take a look and make sure the prebuilt lldb packages work. I haven't seen any mention of these

Re: [lldb-dev] How to link lldb on i386

2016-05-24 Thread Pavel Labath via lldb-dev
Is it only lldb-server you are having problems with? (i.e., are you able to link liblldb.so?) If so, then you might be able to make it link by reducing the number of things that go into it. Right now lldb-server uses only a fraction of its linker input, but we still need to pass in everything

Re: [lldb-dev] Loading debug symbols (C++, Ubuntu 14.04)

2016-05-11 Thread Pavel Labath via lldb-dev
Hi, thank you for investigating this. So, what you are describing should normally work. Generally obj_file->GetDebugSymbolFilePaths() (SymbolVendorELF.cpp:99) should return the correct name to look for the debug file. E.g., in my case for libpthread it returns "libpthread-2.19.so", and indeed

Re: [lldb-dev] Standalone build broken after r269332

2016-05-17 Thread Pavel Labath via lldb-dev
Ok, I see what the problem is now. If you run llvm-config from the build folder, it will print out the correct path for the llvm headers, but this will not be correct for the clang headers as it points directly to the subfolder of the source llvm checkout. In Kamil's use case this will be fine

Re: [lldb-dev] Standalone build broken after r269332

2016-05-16 Thread Pavel Labath via lldb-dev
Hi Eugene, my thoughts on this are inline. On 14 May 2016 at 01:46, Eugene Zelenko via lldb-dev wrote: > Hi! > > I tried to build standalone LLDB after r269332 change in > LLDBStandalone.cmake and encountered next problems: > > It implies that LLVM and Clang were built

Re: [lldb-dev] Enabling tests on the Windows LLVM buildbot

2016-05-18 Thread Pavel Labath via lldb-dev
HI, I am glad to see more automated testing of lldb. I think it's very valuable as a lot of people don't have access to that platform. On 17 May 2016 at 20:54, Zachary Turner via lldb-dev wrote: > Hi all, > > I'm going to be submitting a change shortly to enable "ninja

Re: [lldb-dev] [cfe-dev] [llvm-dev] Fwd: Raising CMake minimum version to 3.4.3

2016-05-06 Thread Pavel Labath via lldb-dev
Adding lldb-dev to the loop. I don't think there should be major issues there as lldb supports a strict subset targets, just making sure everyone is aware of the plans. Our team manages a couple of lldb buildbots still using cmake 2.8. We'll get started on upgrading them though. pl On 5 May

Re: [lldb-dev] Enabling logging from the host gdbserver

2016-04-18 Thread Pavel Labath via lldb-dev
Hi, you can set environment variables when lunching the "platform" instance to enable logging in the "gdbserver" instance: LLDB_DEBUGSERVER_LOG_FILE=/path/to/log/file LLDB_SERVER_LOG_CHANNELS="lldb all:gdb-remote all" Also, depending on what you are trying to achieve, it may be easier to run the

Re: [lldb-dev] netbsd7 buildbot broken

2016-05-25 Thread Pavel Labath via lldb-dev
I modified those scripts recently (it's these scripts , for those who don't know what we are talking about), and I accidentally broke that. I am sorry about that, it should be

Re: [lldb-dev] LLDB Evolution

2016-08-10 Thread Pavel Labath via lldb-dev
I've started to do some cleanup of the include header order (r278222). It doesn't get everything compiling after a clang-format, but it got me about half way. +1 on the include order proposed by Zach. I agree that better modularization would improve testability and have a positive impact on the

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Pavel Labath via lldb-dev
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

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Pavel Labath via lldb-dev
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

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

2016-08-11 Thread Pavel Labath via lldb-dev
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,

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

2016-08-12 Thread Pavel Labath via lldb-dev
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

Re: [lldb-dev] LLDB Evolution

2016-08-15 Thread Pavel Labath via lldb-dev
files, but it should be manageable. pl On 12 August 2016 at 18:13, Jim Ingham <jing...@apple.com> wrote: > >> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev >> <lldb-dev@lists.llvm.org> wrote: >> >> On 12 August 2016 at 00:54, Chris Lattner via lldb

Re: [lldb-dev] LLDB Evolution

2016-08-12 Thread Pavel Labath via lldb-dev
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

  1   2   3   4   5   >