Re: [lldb-dev] Issue: print std unique pointer

becomes how can we identify the STL that is being used > correctly so we can do the right thing. I worry that if std::unique_ptr > isn't working that many many other STL things won't work as well. We are > tuned for a specific STL > > On Feb 27, 2018, at 2:12 PM, Pavel Labath

Re: [lldb-dev] increase timeout for tests?

On Thu, 8 Mar 2018 at 18:40, Davide Italiano wrote: > On Thu, Mar 8, 2018 at 10:29 AM, Greg Clayton wrote: > > It would be great to look into these and see what is taking so long. > Some tests are doing way too much work and should be split up. But it would > be great to see if we have any tests

Re: [lldb-dev] lldb compiled from source 5X slower than homebrew or default lldb

I would start by looking at https://reviews.llvm.org/D32598, which adds a bunch of work we do up-front. I remember looking at this a while back and not being sure whether all of that work is relevant for osx, actually. (I'm specifically thinking of the SymbolFileDWARF::Index call, which is done unc

Re: [lldb-dev] increase timeout for tests?

I think we should get some data before pulling numbers out of our sleeves. If we can get some numbers on the slowest machine that we have around, then we should be able to specify the timeout as some multiple of the slowest test. For example, for me the slowest test takes around 110 seconds. The ti

Re: [lldb-dev] increase timeout for tests?

Aha, in that case, it definitely sounds like increasing the timeout is in order. I would still go for something less than 30 minutes, but I don't care about that much. I may just export LLDB_TEST_TIMEOUT locally to lower it if tests taking long to time out start bugging me. BTW, do you know which

Re: [lldb-dev] increase timeout for tests?

+1 On deleting the lldb-mi tests and increasing the timeout. On Wed, 14 Mar 2018 at 02:27, Jim Ingham wrote: > It is unfortunate that we have to set really long test timeouts because we > are timing the total Test class run, not the individual tests. It is > really convenient to be able to gr

Re: [lldb-dev] settings set target.source-map question

Sounds like a good idea to me. (For testing I'd recommend a .ll file with the paths you need hard coded and lldb-test breakpoint.) On Wed, 14 Mar 2018 at 05:16, Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > When using "settings set target.source-map", when we try to set > breakpo

Re: [lldb-dev] cmake incremental OSX is red

That check was separated out from a larger test so we could put skipIfLinux around it (in r327977). I'm not sure why it's failing, but it's probably some silly typo. Unfortunately I don't have time to look at it today. I am hoping that the fix is obvious. If it's not, you can revert that patch, an

Re: [lldb-dev] NativeThreadProtocol

Yes, they indeed seem to be inverted. Thanks for noticing this. It turns out this was not noticed because the functions were never used, so I just deleted them in r328761. On Wed, 28 Mar 2018 at 19:44, Tatyana Krasnukha via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello, > > > > I glanced c

Re: [lldb-dev] GDB RSPs non-stop mode capability in v5.0

Hi, On Thu, 29 Mar 2018 at 10:09, Ramana via lldb-dev wrote: > Hi, > > It appears that the lldb-server, as of v5.0, did not implement the GDB > RSPs non-stop mode ( > https://sourceware.org/gdb/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop). > Am I wrong? > > The non-stop proje

Re: [lldb-dev] GDB RSPs non-stop mode capability in v5.0

On Mon, 2 Apr 2018 at 16:28, Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > On Apr 2, 2018, at 6:18 AM, Ramana wrote: > > > > On Thu, Mar 29, 2018 at 8:02 PM, Greg Clayton wrote: > >> >> >> On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev >> wrote: >> >> Hi, >> >> It appears

Re: [lldb-dev] Can I call a python script from LLDB c++ code?

The easiest solution may be turn your python script into a full-fledged forwarder (instead of just a port-number-finder). Then, from lldb's point of view it would just be launching a debugserver (that happens to be implemented in python) and communicating with it. And all the forwarding magic would

Re: [lldb-dev] [llvm-dev] lldb stops on every call to dlopen

[+lldb-dev] Hello Steve, thanks for the report. The fact that you see the rendezvous breakpoint being hit many times is not surprising. We get those every time the library is loaded (we need that to load relevant debug info and set potential breakpoints). However, they should generally not be su

Re: [lldb-dev] [llvm-dev] lldb stops on every call to dlopen

nt. But it looks like we got a signal while single-stepping, but the stop reason was misreported by somebody. > Jim > On Apr 17, 2018, at 6:00 AM, Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > [+lldb-dev] > Hello Steve, > thanks for the report. > The fact

Re: [lldb-dev] [llvm-dev] lldb stops on every call to dlopen

. That's what you would expect returning from the single-step to > step over the breakpoint. But it looks like we got a signal while > single-stepping, but the stop reason was misreported by somebody. > Jim > On Apr 17, 2018, at 6:00 AM, Pavel Labath via lldb-dev < > lld

[lldb-dev] Proposal: Using LLD in tests

Hello all, currently we have a couple of tests, in-tree or under review, which are very close to being host-independent. The only part they are missing is the ability to link a intermediate object file: - the ppc64 test in https://reviews.llvm.org/D44437 needs a linker to resolve relocations in th

Re: [lldb-dev] Proposal: Using LLD in tests

eg Clayton wrote: > The last I knew LLD doesn't work on mach-o very well, so be sure to not require LLD for linking any Darwin executables. > > On Apr 19, 2018, at 6:42 AM, Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > > Hello all, > > >

Re: [lldb-dev] Proposal: Using LLD in tests

On Thu, 19 Apr 2018 at 18:19, Leonard Mosescu wrote: >>the PDB tests under lit/SymbolFile/PDB need a linker to produce the program database > With this proposal, would we preserve any coverage for MSVC produced debug information? Well.. the question there is what are you trying to test? I

Re: [lldb-dev] FileSpec and normalization questions

On Thu, 19 Apr 2018 at 19:20, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > On Thu, Apr 19, 2018 at 11:14 AM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: >> Also, looking at the tests for normalizing paths I found the following pairs of pre-normalized and post-

Re: [lldb-dev] FileSpec and normalization questions

On Fri, 20 Apr 2018 at 17:14, Greg Clayton wrote: > > On Apr 20, 2018, at 1:08 AM, Pavel Labath wrote: > > > > > > So, I can see the case for both, and I don't really have a clear > > preference. All I would say is, whichever way we choose, we should make it > > very explicit so that the users of

Re: [lldb-dev] r329889 - Use in-tree dsymutil on Darwin

On Fri, 20 Apr 2018 at 16:46, Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > r329889 says "Use in-tree dsymutil on Darwin", but it's got these change in > test/CMakeLists.txt: > -set(LLDB_TEST_DEPS lldb) > +set(LLDB_TEST_DEPS lldb dsymutil) Shouldn't this just be llvm-dsymutil, whi

Re: [lldb-dev] FileSpec and normalization questions

The llvm patches have been posted as: , < https://reviews.llvm.org/D45942>. On Fri, 20 Apr 2018 at 22:12, Greg Clayton wrote: > > On Apr 20, 2018, at 12:17 PM, Pavel Labath wrote: > > > > On Fri, 20 Apr 2018 at 17:14, Greg Clayton wrote: > >>> On Apr 20, 2018,

Re: [lldb-dev] Dlopen extremely slow while LLDB is attached

On Wed, 25 Apr 2018 at 19:59, Scott Funkenhauser via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Thanks Greg and Jason for pointing me in the right direction! > The results from my original tests were due to a timeout being triggered: > 1524681484.092825651 (x86_64) /tmp/liblldb.so.7.0.0: Readi

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

On Thu, 26 Apr 2018 at 22:58, Leonard Mosescu via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I just did a clean build (debug) on Linux, and I noticed that the LLDB tests seem to consistently get stuck: > -- Testing: 1002 tests, 12 th

Re: [lldb-dev] Dlopen extremely slow while LLDB is attached

On Mon, 30 Apr 2018 at 20:13, Scott Funkenhauser wrote: > I messed up my test setup and incorrectly attributed the additional time. Parsing the DWARF sections does add additional time, but only increases by a small percentage. > By pure chance I noticed that the latency between the client and se

Re: [lldb-dev] Proposal: Using LLD in tests

ndation Collaborative Project > > -Original Message- > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel > > Labath via lldb-dev > > Sent: Thursday, April 19, 2018 12:45 PM > > To: Leonard Mosescu > > Cc: aaron.lee.sm...@gmail.com; LLDB

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

Right, I see what's going on now. Yes, you're right, the commit you mention has added extra packets which are not handled in the mock. The reason this is hanging for you is because you are using a debug build, which has a much larger packet timeout (1000s i think). In the release build this passes,

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

Ok, r331374 ought to fix that. The situation was a bit more complicated then I thought, because the function was behaving differently if one builds lldb with xml support, so i've had to update the test to work correctly in both situations. On Wed, 2 May 2018 at 16:34, Pavel Labath wrote: > Right,

[lldb-dev] What should SymbolFile::FindFunctions(..., eFunctionNameTypeFull, ...) do ?

Hello all, /This may or may not be related to the "Issue with expression parser finding the correct types" thread from last week./ As you probably know, I am working on adding DWARF v5 accelerator tables to lldb. To make that happen, I've been trying to understand how the two existing indexing me

Re: [lldb-dev] What should SymbolFile::FindFunctions(..., eFunctionNameTypeFull, ...) do ?

Thank you for the detailed response. My replies are below. On Thu, 3 May 2018 at 16:53, Greg Clayton wrote: > On May 3, 2018, at 7:38 AM, Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > - for the manual case (SymbolFileDWARF.cpp:2626), the function will look > into

Re: [lldb-dev] What should SymbolFile::FindFunctions(..., eFunctionNameTypeFull, ...) do ?

On Fri, 4 May 2018 at 17:31, Greg Clayton wrote: > > On May 4, 2018, at 4:58 AM, Pavel Labath wrote: > > Is it really OK? If our indexes will never contain the demangled names, > > then the IRExecutionUnit lookups using the demangled names will always > > fail. (Right now they will only succeed f

[lldb-dev] clang::VersionTuple

While moving Args around, I noticed that we have a bunch of functions/classes that pass/store version numbers as a triplet of integers (e.g. Platform::GetOSVersion). I got halfway into creating a wrapper class for that when I noticed clang::VersionTuple, which is pretty much what I wanted out of th

Re: [lldb-dev] clang::VersionTuple

the that drives community decisions). > Fred > Greg > On Tue, May 8, 2018 at 9:26 AM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: >> No issues from me. >> > On May 8, 2018, at 9:11 AM, Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: &

Re: [lldb-dev] What should SymbolFile::FindFunctions(..., eFunctionNameTypeFull, ...) do ?

On Tue, 8 May 2018 at 10:51, Pavel Labath wrote: > On Fri, 4 May 2018 at 17:31, Greg Clayton wrote: > > > On May 4, 2018, at 4:58 AM, Pavel Labath wrote: > > > Is it really OK? If our indexes will never contain the demangled names, > > > then the IRExecutionUnit lookups using the demangled nam

Re: [lldb-dev] Advice on architectures with multiple address spaces

The Address class may be suitable for the higher layers of lldb, but I don't think the it can ever be a blanket replacement for lldb::addr_t. It has way too much smartness built-in. We use addr_t in a lot of places that don't/shouldn't care about Targets, ExecutionContexts or Sections. All of lldb-

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

On Tue, 5 Jun 2018 at 01:18, Ryan Lovelett via lldb-dev wrote: > > So I've found a capability on Linux to be notified about new processes. I > have an example of listening for these new processes running on my machine > now [1] and I can see when my desired user process spawns. Though > documen

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

There is some documentation on the packets in docs/lldb-gdb-remote.txt in the lldb repo, though for this particular packet it does not say much about the encoding (patches welcome). That said, it looks like the format is just that we send the process name hex-encoded. For that you can simply use S

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

There are other options available as well, but for this particular scenario, I'd go with the following: - start debugging the client, set a breakpoint just before it sends the vAttach packet - when the client reaches this breakpoint, attach a debugger to the server (it will already be running at th

Re: [lldb-dev] MacOS minidump debugging

We don't have support for reading mac minidumps presently. That said, it probably wouldn't be too hard to add one, as we already have windows and linux minidumps working (to some degree, at least). It would probably require adding parsing support for some OS-specific structures (I recall some thing

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

sleep_for is definitely better than usleep because of portability (and we use it elsewhere already). Could you attach the patch to phabricator instead ? It's easier to make comments and iterate there. When you upload the patch be sure to include full contex

Re: [lldb-dev] LLDB fails to load C++ Plugin (sharedlib) - error: this file does not represent a loadable dylib

I would expect the issue is that dlopen fails to locate the dependent libraries of your plugin. Can you lookup the actual dlopen call which opens your library and see what is the exact error it fails with? On Fri, 8 Jun 2018 at 10:52, Bewoayia Kebianyor via lldb-dev wrote: > > Hello Everyone, > >

Re: [lldb-dev] Adding DWARF5 accelerator table support to llvm

Hello again, It's been nearly six months since my first email, so it's a good time to recap what has been done here so far. I am happy to report that stages 1-3 (i.e. producer/consumer in llvm and integration with lldb) of my original plan are now complete with one caveat. The caveat is that the

Re: [lldb-dev] Adding DWARF5 accelerator table support to llvm

Thank you all. I am going to try to reply to all comments in a single email. Regarding the .apple_objc idea, I am afraid the situation is not as simple as just flipping a switch. (If it was, I don't think I would have embarked on this adventure in the first place -- I would just emit .apple_*** e

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

On Thu, 14 Jun 2018 at 17:58, Greg Clayton wrote: > > > > On Jun 14, 2018, at 9:36 AM, Adrian Prantl wrote: > > > > On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev > wrote: > > Thank you all. I am going to try to reply to all comments in a single email. > > Regarding the .apple_objc ide

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

On Thu, 14 Jun 2018 at 19:26, David Blaikie wrote: > > > > On Thu, Jun 14, 2018 at 11:24 AM Pavel Labath wrote: >> >> On Thu, 14 Jun 2018 at 17:58, Greg Clayton wrote: >> > >> > >> > >> > On Jun 14, 2018, at 9:36 AM, Adrian Prantl wrote: >> > >> > >> > >> > On Jun 14, 2018, at 7:01 AM, Pavel La

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

On Thu, 14 Jun 2018 at 19:29, Pavel Labath wrote: > > On Thu, 14 Jun 2018 at 19:26, David Blaikie wrote: > > > > > > > > On Thu, Jun 14, 2018 at 11:24 AM Pavel Labath wrote: > >> > >> On Thu, 14 Jun 2018 at 17:58, Greg Clayton wrote: > >> > > >> > > >> > > >> > On Jun 14, 2018, at 9:36 AM, Adri

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

I wasn't using type units (those don't work at all right now). I've done a bit of digging, and i found this patch which explicitly disables template member function parsing (though it seems it didn't really work before either). The patch contains a quite long ex

Re: [lldb-dev] clang::VersionTuple

ssues for many that have > repositories that link against older llvm/clang. Doesn't affect me anymore, > but Apple will be affected. > > > > I’m not sure I understand what issues you’re referring to, we don’t link > new LLDBs to old clangs (and even if we did, it wouldn’t be s

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

On Fri, 15 Jun 2018 at 20:14, David Blaikie wrote: > > How do you handle name lookup for nested classes? They have the same problem > (they don't appear in all definitions) - don't appear in all descriptions of > the outer/parent class. (in theory we could ensure there's always at least a > dec

Re: [lldb-dev] clang::VersionTuple

Thanks. I am going to submit the patch then. On Fri, 15 Jun 2018 at 19:56, Jim Ingham wrote: > > On Jun 15, 2018, at 3:44 AM, Pavel Labath via lldb-dev > > wrote: > > > > Hello again, > > > > Just a quick update on the state of this. > > > > I&#x

Re: [lldb-dev] LLDB does not support the default 8 byte build ID generated by LLD

Thanks for the heads up Scott. I was not aware that lld generates build-ids with different length. Padding would be one option (we already do that to handle the crc pseudo-build-ids), but perhaps a better one would be to teach the class how to handle arbitrary-sized UUIDs (or up to 20 bytes, at le

Re: [lldb-dev] LLDB does not support the default 8 byte build ID generated by LLD

From the looks of it, the patch stalled on the part whether we can consider all-zero UUIDs as valid or not. I've dug around the code a bit now, and I've found this comment in ObjectFileMachO.cpp. // "main bin spec" (main binary specification) data payload is // formatted:

Re: [lldb-dev] LLDB does not support the default 8 byte build ID generated by LLD

That sounds like a plan. I have started cleaning up the class a bit (removing manual uuid string formatting in various places and such), and then I'll send a patch which implements that. Leonard, I'm not going to use your patch, as it's a bit un-llvm-y (uses std::ostream and such). However, I want

Re: [lldb-dev] Handling callable addresses

+1 While creating the architecture plugin, I noticed that this code could be moved there, but never got around to doing that. If the code is indeed equivalent, then we can make a utility function or a common base class that both plugins can then reuse. On Thu, 21 Jun 2018 at 23:34, Greg Clayton vi

Re: [lldb-dev] Linux: Failing lldb unit tests and TestLinuxCore.py

Hello Gabor, The error message (Option 'help-list' registered more than once) leads me to believe that this is caused by an uncommon (for lldb, at least) build configuration. Can you share your cmake configuration? I suspect TestLinuxCore is also failing due to unexpected build configuration, spe

Re: [lldb-dev] Linux: Failing lldb unit tests and TestLinuxCore.py

The BUILD_SHARED_LIBS part is likely to be the issue. LLDB libraries have cyclic dependencies, which don't play well with shared libraries. I think somebody "fixed" it some time ago (i.e., just made the flag be ignored for lldb), but I'm not sure if he also checked the unit tests. I'll see if I can

Re: [lldb-dev] RFC: libtrace

On Wed, 27 Jun 2018 at 01:14, Zachary Turner via lldb-dev wrote: > > Yes that’s what I’ve been thinking about as well. > > One thing I’ve been giving a lot of thought to is whether to serialize the > handling of trace events. I want to balance the “this is a library and you > should be able to

Re: [lldb-dev] RFC: libtrace

On Wed, 27 Jun 2018 at 14:11, Zachary Turner wrote: > > suppose process A (single threaded) is tracing process B (2 threads). If > trace events happen on both threads of B, then the second thread can’t > continue until both threads’ trace events have been fully handled, > synchronously. If proc

Re: [lldb-dev] building only lldb with debug symbols

On Thu, 28 Jun 2018 at 04:34, Adrian Harris via lldb-dev wrote: > > Hi Everyone, > > I'm writing a gdb-server for a new architecture and need to be able to debug > lldb to track down issues. Unfortunately disk space is tight here and the > llvm debug build consumes north of 40Gb with debug symbo

Re: [lldb-dev] Linux: Failing lldb unit tests and TestLinuxCore.py

The core file tests should be fixed as of r335859. I tried reproing the python unit tests problem, but I couldn't get it to fail that way. I can help you get to the bottom of it if you're interested, but it's going to take some interactive debugging (for start I'd need to see the link command for t

Re: [lldb-dev] Linux: Failing lldb unit tests and TestLinuxCore.py

Hi Gábor, thanks for sending me that link line. Unfortunately, I don't see anything immediately obvious there. (I was expecting there would be something pulling in LLVMSupport twice, but I don't see anything like that there). To fix this, we need to figure out where is the second definition of th

Re: [lldb-dev] Linux: lldb tests are failed

Hello Konstantin, that sounds like a good idea. We've had reports of this in the past, but so far noone dug into it to find out what's going on (thank you for that). Can you create a review for this (https://reviews.llvm.org/differential/)? pl On Mon, 9 Jul 2018 at 14:17, k.baladurin via lldb-dev

Re: [lldb-dev] MI Handle events.

The eStateSuspended state is used for threads (you can set it via SBThread::Suspend/Resume). It controls whether a "continue" operation on the process will run the thread or not. I am not sure if you can ever see that state on the process itself. On Sat, 14 Jul 2018 at 15:39, Adrian Prantl via l

Re: [lldb-dev] Linux: Failing lldb unit tests and TestLinuxCore.py

Hi Gábor, sorry for the late reply, I have been OOO. Thanks for the detailed report. I think the fact that we load the system lldb from the unit tests should be considered a bug. I am going to try to find some time fix this issue. thanks, pl On Fri, 29 Jun 2018 at 15:35, Gábor Márton wrote: > >

Re: [lldb-dev] LLDB tests duplicated between lldb-suite and lit

+1 for removing. I've been wanting to do that for a while now... >> >> Looking at the other duplicated tests, we have the potential for similar >> issues. They also all use CHECK rather then CHECK-DAG, so we should at least >> update them to use CHECK-DAG. Could you elaborate on this? I don't s

Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

Instead of "image search-paths add" you should be able to do a "settings append target.exec-search-paths /your/sysroot". That one should not require a running target or anything like that. However, I agree that it would be nice for the platform sysroot to work out of the box. Particularly, as we c

Re: [lldb-dev] MI Handle events.

Well, judging by this snippet = tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp- case lldb::eStateStopped: tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp-pEventType = "eStateStopped"; tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp-bOk = HandleProcessEventStateStopped(vEvent, bShouldB

Re: [lldb-dev] LLDB Demangling

Hello Stefan, thank you for working on this. I believe this work will bring a huge improvement to LLDB. Adding something like DemangleWithRichNameIndexInfo to the Mangled class makes sense to me. However, I don't think that function should be taking an ItaniumPartialDemangler as an argument. The

Re: [lldb-dev] LLDB Demangling

On Wed, 25 Jul 2018 at 19:15, Stefan Gränitz wrote: > > right now the Symtab class builds a table containing all > > demangled names. This is mostly unnecessary, and > What exact table are you referring to here? The m_name_to_index map does > store both, demangled and mangled strings. Not sure to

Re: [lldb-dev] Phabricator repository

Sounds like a good idea, though I'm not sure what specifically needs to be done to make that happen. Eric might know more... On Wed, 1 Aug 2018 at 03:17, Raphael Isemann via lldb-dev wrote: > > Could we get LLDB into this repository list here? > https://reviews.llvm.org/diffusion/ > > Beside that

Re: [lldb-dev] buildbot deployment: gsutil: Anonymous caller does not have storage.objects.create access to lldb_test_traces

This step is very specific to our (android studio) buildbot setup, and it uploads the test results to a google cloud account only accessible to our team. If you wanted to do something like that, you'd have to create your own account and set it up similarly. However, I strongly suspect that you do

Re: [lldb-dev] buildbot deployment: gsutil: Anonymous caller does not have storage.objects.create access to lldb_test_traces

On Thu, 2 Aug 2018 at 13:39, Jan Kratochvil wrote: > > On Thu, 02 Aug 2018 13:47:25 +0200, Pavel Labath wrote: > > However, I strongly suspect that you do not want this, > > Right. > > > > *However*, for setting up a new bot, I'd recommend not using this > > particular slave factory (getLLDBScript

Re: [lldb-dev] Firewall complaint about hosttests.exe

Yes, we have a couple of tests there, which verify that our socket communication works. It seems there is one test which specifically opens a non-localhost socket (TCPListen0GetPort (*)), so I would bet it's that's the one the firewall is having problems with. Or, if you have a particularly paranoi

Re: [lldb-dev] run tests with ASAN (dotest.py)

When I looked into this in the past (two years ago), the problem was that the sanitizer runtimes were expected to be linked into the main executable. For the dotest tests, the main executable is "python", so unless you have built an asanified python, you will not have them. You might be able to ge

Re: [lldb-dev] run tests with ASAN (dotest.py)

Hi Gábor, That error is kind of correct. As far as c++ standard is concerned, this is an ODR violation, as both lldb and liblldb link in a copy of LLVMSupport.a. However, all LLVM symbols in liblldb have "hidden" visibility (and we make sure we don't pass around llvm objects on the SO boundary), s

Re: [lldb-dev] Handling of the ELF files missing build-ids?

Hello Leonard, while I'm in principle supportive of this idea, I think it's not going to be as easy as you might imagine. There are currently at least two mechanisms which rely on this crc UUID. 1. .gnu_debuglink separate file pointer

[lldb-dev] Pavel's status

Hello all, as some of you may know, this week is my last week at Google. However, I am not planning to disappear from the LLDB/LLVM communities as a result. You should still see me around, only with a new address (pavel AT labath DOT sk). I plan to continue looking out for the linux side of lldb (

Re: [lldb-dev] Remove "Either" or not?

I'd vote for removal. This kind of functionality would be better off in llvm's ADT anyway. On Tue, 7 Aug 2018 at 09:18, Tatyana Krasnukha via lldb-dev wrote: > > Hello, > > > > lldb\include\lldb\Utility\Either.h seems dead, at least I couldn’t find any > usages. > > I could enhance it with Bind f

Re: [lldb-dev] Handling of the ELF files missing build-ids?

Sounds like a plan. On Tue, 7 Aug 2018 at 01:30, Leonard Mosescu wrote: >> >> I am fine with all the above except some reservations about case C. No need >> to calculate something if it isn't useful. For case C it should be fine to >> never match as if a file has a UUID to begin with it typical

Re: [lldb-dev] [CMake] LLDB framework / shared library

Hello Stefan, first off, I want to point out that although I spent a lot of time digging through our cmake files, I am not using the framework build, nor am familiar with it's details. I also don't know why the framework was split into multiple targets. What I do know is that we then ended up add

Re: [lldb-dev] New target; where to start with thread plans

On 28/11/2018 21:05, Jim Ingham via lldb-dev wrote: The main complication would be if your new target didn't support hardware-single-step. If that's the case you will have to have a Disassembler that can predict the target PC of all instructions (when stopped at that instruction) since you'll

[lldb-dev] Adding breakpad "symbol" file support

Hello all, I'd like to propose adding support for reading breakpad symbol files to LLDB. The breakpad files are textual files, which contain just enough information to produce a backtrace from a crash dump. This information includes: - UUID, architecture and name of the module - line tables -

Re: [lldb-dev] Adding breakpad "symbol" file support

On 03/12/2018 23:54, Leonard Mosescu wrote: Yay! In case anyone is interested in the details, the Breakpad symbol format is documented here: https://chromium.googlesource.com/breakpad/breakpad/+/master/docs/symbol_files.md Thanks, Leonard, I actually didn't know about that document. :) (Th

Re: [lldb-dev] The lit test driver gets killed because of SIGHUP

On 05/12/2018 03:49, Jonas Devlieghere via lldb-dev wrote: Hi everyone, Since we switched to lit as the test driver we've been seeing it getting killed as the result of a SIGHUP signal. The problem doesn't reproduce on every machine and there seems to be a correlation between number of occurre

Re: [lldb-dev] The lit test driver gets killed because of SIGHUP

On 05/12/2018 18:36, Jonas Devlieghere wrote: I believe that posix doesn't make this guarantee, but that in reality neither linux nor darwin recycles pids before they wrap around? Yes, linux tries pretty hard to not recycle pids, but this is hampered by the fact that the default pid limit is

Re: [lldb-dev] When should ArchSpecs match?

On 07/12/2018 01:22, Jason Molenda via lldb-dev wrote: Oh sorry I missed that. Yes, I think a value added to the OSType for NoOS or something would work. We need to standardize on a textual representation for this in a triple string as well, like 'none'. Then with arm64-- and arm64-*-* as Un

Re: [lldb-dev] [RFC] Using Sphinx to generate documentation

On 06/12/2018 18:02, Jonas Devlieghere via lldb-dev wrote: Hi everyone, The current LLDB website is written in HTML which is hard to maintain. We have quite a bit of HTML code checked in which can make it hard to differentiate between documentation written by us and documentation generated by

Re: [lldb-dev] [ASTImporter][macOS] Cannot link debugserver, keychain error

On 10/12/2018 20:28, Gábor Márton via lldb-dev wrote: Hi, Recently I have updated the LLDB source and now I cannot link the debugserver. I guess, the problem is started in one of the commits at last week, because before that I had not experienced it. Any help would be appreciated. I'd like to

Re: [lldb-dev] New test failures on Linux

On 17/12/2018 13:36, Gábor Márton via lldb-dev wrote: Hi, I have discovered new test failures on Linux, on trunk. They seem to fail when DWO is used (DWARF test cases pass). https://bugs.llvm.org/show_bug.cgi?id=40048 https://bugs.llvm.org/show_bug.cgi?id=40049 https://bugs.llvm.org/show_bug.c

Re: [lldb-dev] [CMake] cross compiling lldb-server

On 30/12/2018 00:36, Joel Winarske via lldb-dev wrote: Hi, I'm looking at cross compiling lldb-server for a Linux target.  My use case only needs lldb-server cross-compiled for the target.  I'm finding it's expecting a cross-compiled clang. It would be great to have a build option to support

Re: [lldb-dev] Unreliable process attach on Linux

On 04/01/2019 17:38, Florian Weimer via lldb-dev wrote: Consider this example program: #include #include #include #include #include #include int main(void) { // Target process for the debugger. pid_t pid = fork(); if (pid < 0) err(1, "fork"); if (pid == 0) while (tr

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On 04/01/2019 22:19, Jonas Devlieghere via lldb-dev wrote: Hi Everyone, In September I sent out an RFC [1] about adding reproducers to LLDB. Over the past few months, I landed the reproducer framework, support for the GDB remote protocol and a bunch of preparatory changes. There's still an ope

Re: [lldb-dev] Unreliable process attach on Linux

On 07/01/2019 09:29, Florian Weimer wrote: * Pavel Labath: On 04/01/2019 17:38, Florian Weimer via lldb-dev wrote: Consider this example program: #include #include #include #include #include #include int main(void) { // Target process for the debugger. pid_t pid = fork();

Re: [lldb-dev] Unreliable process attach on Linux

On 07/01/2019 13:22, Florian Weimer wrote: * Pavel Labath: Thanks. I think this is what I suspected. The server is extremely slow in responding to the qHostInfo packet. This timeout for this was recently increased to 10 seconds, but it looks like 7.0 still has the default (1 second) timeout. I

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On 07/01/2019 19:26, Jonas Devlieghere wrote: On Mon, Jan 7, 2019 at 1:40 AM Pavel Labath > wrote: I've been thinking about how could this be done better, and the best (though not ideal) way I came up with is using the functions address as the key. That's gu

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On 07/01/2019 22:45, Frédéric Riss wrote: On Jan 7, 2019, at 11:31 AM, Pavel Labath via lldb-dev mailto:lldb-dev@lists.llvm.org>> wrote: On 07/01/2019 19:26, Jonas Devlieghere wrote: On Mon, Jan 7, 2019 at 1:40 AM Pavel Labath <mailto:pa...@labath.sk><mailto:pa...@la

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On 07/01/2019 22:13, Jonas Devlieghere wrote: On Mon, Jan 7, 2019 at 3:52 AM Tamas Berghammer > wrote: One problem is when the behavior of LLDB is not deterministic for whatever reason (e.g. multi threading, unordered maps, etc...). Lets take SBModul

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On 08/01/2019 21:57, Jonas Devlieghere wrote: Before I got around to coding this up I realized you can't take the address of constructors in C++, so the function address won't work as an identifier. You gave up way too easily. :P I realized that constructors are going to be tricky, but I di

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On 09/01/2019 17:15, Jonas Devlieghere wrote: On Wed, Jan 9, 2019 at 5:05 AM Pavel Labath > wrote: On 08/01/2019 21:57, Jonas Devlieghere wrote: > Before I got around to coding this up I realized you can't take the > address of constructors in C++, so the

Re: [lldb-dev] RFC: Simplifying SymbolFile interface

On 09/01/2019 20:59, Zachary Turner via lldb-dev wrote: The Native PDB symbol file plugin I think is mostly complete.  It's at least almost as good as the old Windows-only PDB plugin in 90% of ways, while actually being significantly better in other ways (for example, there was a test that took

<    1   2   3   4   5   6   >