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

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 need

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

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 O

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

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] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback

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 pesky, but trivial Invalid i

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

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 for llvm-based language >> implementations. The

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

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 wa

Re: [lldb-dev] Fwd: lldb doesn't work on centos7

HI, a couple of random shots in the dark: - could you paste the output of "frame variable --raw-output s"? (This disables lldb's type formatters. The goal is to see if the problem is in the formatter, or in lldb not finding the variable in the first place). - could you compile your test executab

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

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 hi

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

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 with

Re: [lldb-dev] serialized, low-load test pass in parallel test runner

I think it sounds like something that would be useful in general. I'd even go a step further and say that we can replace the current flakey test mechanism with your proposed solution. If we do that (remove the current flakey mechanism when this is in place), then I think it would be super-great as

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

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 lldb has to be able to fin

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

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

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 alt

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

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 engine",

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

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 am

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

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

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

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 test decorators. >> > > OT

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

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 to 64-bit and uses PRIu64

Re: [lldb-dev] Hang during attach

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 try this with the > c

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

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 fe

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

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 specific to the > individua

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

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 you.

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

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 tha

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

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] Getting lldb tests working on Hexagon

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 t

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

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 /* clang-

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

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

+ 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 stri

[lldb-dev] Module Cache improvements - RFC

Hello all, we are running into limitations of the current module download/caching system. A simple android application can link to about 46 megabytes worth of modules, and downloading that with our current transfer rates takes about 25 seconds. Much of the data we download this way is never actual

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

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 (de

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

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 from you, and you can carry

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

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 triple. Could you point me to

Re: [lldb-dev] How to get SBTarget before AttachToProcessWithID?

Hi, it's a bit un-intuitive, but you should be able to create a target with a null pointer for the executable, and use that to attach (see CommandObjectProcessAttach::DoExecute). BTW, if you find the existing API documentation too vague, we'd be happy to accept any improvements. cheers, pl On

Re: [lldb-dev] Inquiry for performance monitors

s (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 process the data. >> > > >> > > If this all goes well we can think about bui

Re: [lldb-dev] Inquiry for performance monitors

ow to create new lldb command line >> >> > > commands in >> >> > > python, see the section named "CREATE A NEW LLDB COMMAND USING A >> >> > > PYTHON >> >> > > FUNCTION" on the http://lldb.llvm.org/python-reference.

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

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 SBDebugger::SetAsync(true), the

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

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 else,

Re: [lldb-dev] Inquiry for performance monitors

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 correctly, the idea is the ru

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

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 succeedin

Re: [lldb-dev] Inquiry for performance monitors

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 for the > inferior to st

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

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

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 t

Re: [lldb-dev] Race condition crashes during launching LLDB

On 5 February 2016 at 05:09, Jeffrey Tan via lldb-dev wrote: > After adding some logging I figured out that the race condition is caused by > process.Continue() did not guarantee process has been really resumed yet in > async mode, so the second wait_for_process_stop() is skipped immediately to >

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

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 > > On Thu, Feb 18, 2016 at

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

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 thin

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

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] Module Cache improvements - RFC

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 agree with you that we shoul

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

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, even

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

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] How to use the C++ API? No useful documentation?

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] How to use the C++ API? No useful documentation?

Thanks for the explanation. I'll look this over tomorrow. cheers, pl On 3 March 2016 at 15:23, Paul Peet wrote: > Hi Pavel, > > This is the code: > > int main() { > using namespace lldb; > > SBDebugger::Initialize(); > SBDebugger debugger = SBDebugger::Create(true); > > if(!debugger.IsVa

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

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 "restart

Re: [lldb-dev] Inquiry about Load Address

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 or a set of API's that > co

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

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] What's the purpose of the TestStarted-XXX and TestFinished-XXX files?

I don't think anyone is relying on these. We should just stop creating them altogether. We are using the *.log files to track test results over time, but we don't need these files there. You can detect crashing tests by the fact that the log files don't have a "TestResult-" (Success, Failure, Erro

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

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 work

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

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 no

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

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 10

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

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 (SBHos

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

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 have to reimplement the log

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

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 3.8.0 release on a Debian 8

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

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 launc

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

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, Jeffre

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

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

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] SBProcess::Detach kills target

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 runn

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

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

> 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: io

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

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 changes breaking the unittest

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

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 small-scoped C++ unit > test (v

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

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 ld-li

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

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 packet definitions for tra

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

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 reviewed

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

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 t

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

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] Enabling logging from the host gdbserver

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] Ubuntu nightly package for lldb 3.8 has no binary

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 scripts

Re: [lldb-dev] Bug fixes for release_38 branch

As Tamas said, little effort has gone into the to stabilization of the 3.8 branch. Right now, you're the only one looking into it, so I think we'll just defer to your judgement. It is a bit of a duplication of effort but, I think it is very worthwhile for lldb project as a whole. For the multithre

Re: [lldb-dev] Redundant six.py copy

We could have a cmake option, say -DUSE_BUILTIN_SIX=true|false (default being whatever you like, but I'd like to avoid autodetection, as that can produce unexpected results). Distrubution maintainers can set it to false (which will prevent six.py from being installed by lldb altogether) and just ma

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

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 2016

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

Hi Stefan, what you are describing should work out of the box, so the fact that you are having to add the symbols manually is a bug. I haven't tried it with the apache binary specifically, but lldb can certainly find external debug symbols for libc (definitely on ubuntu 14.04, as that's what I use

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

You can also use SBCommandInterpreter::HandleCommand, which gives you a bit more control over what happens. good luck with your thesis. pl On 9 May 2016 at 10:00, Stefan Kratochwil wrote: > Hi Pavel, > > thanks for your quick reply. I am currently using a release build, so it may > take a momen

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

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 the

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

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 separately, but they could

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

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 sinc

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

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 check-lldb" on > the upstr

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

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 (and

Re: [lldb-dev] netbsd7 buildbot broken

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 fix

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

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 change landed, and it look

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

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

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: > Hi! > > I got next messa

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

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] Remote debugging - unix socket and/or specific port

Hi Adrien, I think your diagnosis is correct here. LLDB does indeed create an additional connection to the gdb-server instance which is started by the platform instance when you start debugging. In case of android platforms we already include code to forward this port automatically, but there is n

Re: [lldb-dev] Can someone help me getting the thread local variable tests on Linux passing after my changes in 274366?

The correct incantation for the behavior you want should be now: @expectedFailureAll(oslist=no_match(lldbplatformutil.getDarwinOSTriples())). We are trying do drop the "Unless" versions of the decorators, as the approach does not scale well. I've put the decorator in place now. I'll put the tls is

Re: [lldb-dev] Typing in lldb is broken

Hi, This is probably some interaction between LLDB *and* your terminal. Hard to say why without knowing your environment. Could you check how is your terminal configured (unicode yes/no, which emulation mode, codepage, ...). Also try running "env" in your terminal and check for anything out of pla

[lldb-dev] Introductions

Hello everyone, I'd like to introduce Dimitar. He will be with us as an intern for the next few months and will be looking into adding minidump support for platforms other than windows. Basically, we'd like to add a new process plugin which does not depend on native windows api's to parse the mini

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

Hi, thanks for the patch. I took the opportunity to clean up the code there, so I have committed a somewhat modified version, but I believe you should get the result you were trying to achieve. Let me know how it works. cheers, pl On 2 August 2016 at 13:53, Dangling Pointer via lldb-dev wrote:

Re: [lldb-dev] LLDB Evolution

I fully welcome this move and agree with the timeline. Woohoo. I also agree with assessment of the situation regarding testing. I think we're going to need to devote thought to testing if we're going to move closer towards llvm. pl On 9 August 2016 at 16:42, Zachary Turner via lldb-dev wrote: >

Re: [lldb-dev] LLDB Evolution

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 si

  1   2   3   4   5   6   >