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

On 27 April 2017 at 19:12, Jim Ingham wrote: > Interesting. Do you have to catch this information as the JIT modules get > loaded, or can you recover the data after-the-fact? For most uses, I don't > think you need to track JIT modules as they are loaded, but it would be good > enough to refr

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

On 27 April 2017 at 00:12, Scott Smith via lldb-dev wrote: > After a dealing with a bunch of microoptimizations, I'm back to > parallelizing loading of shared modules. My naive approach was to just > create a new thread per shared library. I have a feeling some users may not > like that; I think

[lldb-dev] I'm going to break the xcode build

Hello all, I'd like to submit D32434 soon, which adds a dependency on yaml2obj, which I use to test elf file parsing code. This will break the xcode build as it does not provide path to the yaml2obj binary to the unit tests. As far as I can tell, fixing the build should be easy and amounts to add

Re: [lldb-dev] remote server crash -> lldb waits forever in accept()

MainLoop was meant to be a general event multiplexer. One of those events can certainly be "a certain amount of time expiring". So, you could write something like: loop.RegisterAlarm(seconds(N), [&] { loop.RequestTermination() }); which would translate to an appropriate timeout argument to ppoll.

Re: [lldb-dev] Renaming lldb_private::Error

On 1 May 2017 at 19:48, Zachary Turner via lldb-dev wrote: > > > On Mon, May 1, 2017 at 11:28 AM Jim Ingham wrote: >> If it is actually causing confusion (I haven't experienced such yet) I >> don't mind typing some extra letters. > > I think that's in part because llvm::Error isn't very prevalent

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

On 28 April 2017 at 16:04, Scott Smith wrote: > Hmmm ok, I don't like hard coding pools. Your idea about limiting the > number of high level threads gave me an idea: > > 1. System has one high level TaskPool. > 2. TaskPools have up to one child and one parent (the parent for the high > level Task

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

On 1 May 2017 at 22:58, Scott Smith wrote: > On Mon, May 1, 2017 at 2:42 PM, Pavel Labath wrote: >> >> Besides, hardcoding the nesting logic into "add" is kinda wrong. >> Adding a task is not the problematic operation, waiting for the result >> of one is. Granted, generally these happen on the sa

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

On 29 April 2017 at 12:25, Kamil Rytarowski wrote: > I've managed to configure lldb-amd64-ninja-netbsd7 to run the unit > tests. There has been observed a regression as the number of passing > ones dropped recently from 600+/1200+ to 200+. I've reproduced this also > locally. > > http://lab.llvm.o

Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux

What's the cmake command you are using? It sounds like you somehow ended up enabling -Werror, which is confusing the backtrace-detection code (and probably most of the other cmake compile checks). One of the workarounds would be to disable -Werror. pl On 28 April 2017 at 22:36, Andy Gibbs via l

Re: [lldb-dev] NetBSD core(5) files for LLDB's test-suite

Sorry it took me so long. I think it's fine to check a couple of those in. When zipped, they will still be orders of magnitude smaller then the windows minidump exe we are carrying around. For the long term though, I'd like to add the necessary support to llvm's obj2yaml to be able to generate the

Re: [lldb-dev] Setting shared library search paths and core files

Core file debugging is not that well supported right now. I have made a couple of fixes from time to time, mainly because I see it as a possibility for testing other parts of the debugger, but I don't think it get's much use and testing (on linux anyway). I *think* you might be able to get it work

Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux

s > Cc: lldb-dev@lists.llvm.org > Subject: Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux > > This is in cmake detection code though, the options you set for your build > have no bearing there right? > > This looks like a bug in cmake to me, perhaps a newer cmake versio

Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux

; > Sent: 02 May 2017 13:50 >> > To: Pavel Labath; Andy Gibbs >> > Cc: lldb-dev@lists.llvm.org >> > Subject: Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux >> > >> > This is in cmake detection code though, the options you set for

[lldb-dev] lldb-server tests

Hello all, In case you haven't noticed it, I'd like to draw your attention to D32930, where we're proposing a new test framework for lldb-server tests. The discussion has so far been about low-level implementation details, so you don't have to read through it if you don't feel like to (but I do en

Re: [lldb-dev] lldb-server tests

I wasn't forgetting about this -- this is what i meant by a "FileCheck-like utility" in the original email. The thing I am afraid of there is the complexity hidden in the "" in your example. The thing is this will rarely be a fixed string. For example, to set a breakpoint, you need to send other p

Re: [lldb-dev] Python scripting in Windows LLDB

This may cause some issues with the multi-configuration generators. E.g. a single VS build will create both debug and release configurations. I suspect this is the reason why the check is written as it is now. I'm not sure what would be the appropriate behavior in this case if only one of the pyth

Re: [lldb-dev] lldb-server tests

Note to apple folks: The lldb-server test suite is also used for testing debugserver. I'm not sure how much you guys care about these tests (the commit history shows only Todd touched them), but we would be interested in hearing your thoughts on this. On 16 May 2017 at 12:08, Pavel Labath wrote:

Re: [lldb-dev] Python scripting in Windows LLDB

Ok, if it works, I'm all for it. I can't say I'm really familiar with how the multi-configuration generators work. I also wouldn't mind failing more aggresively if a dependency is not available. On 22 May 2017 at 20:54, Ted Woodward wrote: > My dev machine has both debug and release python exe/l

[lldb-dev] Running lit (googletest) tests remotely

Hello all, we are trying to convert some of the lldb tests to lit (for these specific tests we are using the googletest format). One of our requirements is that we are able to run these tests remotely, so that we are able to verify that we can debug e.g. android arm binaries even though our develo

Re: [lldb-dev] A bit of extra-polish for my lldb plugin

I think the cleanest solution would be to actually modify the compiler to emit "correct" dwarf (as in, dwarf representing the code as it actually looks like to user, and not some internal intermediate representation). The dwarf expression in DW_AT_location can easily handle the lookup of some field

Re: [lldb-dev] [llvm-dev] Running lit (googletest) tests remotely

Thank you all for the pointers. I am going to look at these to see if there is anything that we could reuse, and come back. In the mean time, I'll reply to Mathiass's comments: On 26 May 2017 at 19:11, Matthias Braun wrote: >> Based on a not-too-detailed examination of the lit codebase, it does >

Re: [lldb-dev] A bit of extra-polish for my lldb plugin

On 31 May 2017 at 19:40, Jim Ingham wrote: > Pavel, can you say more about your idea? > > In both ObjC and C++ methods, you can refer to an ivar either as "this->ivar" > or just "ivar". But the DWARF for C++ doesn't tell lldb that a particular > language supports referring to ivars transparentl

Re: [lldb-dev] [llvm-dev] Running lit (googletest) tests remotely

My plan was to use it on already-running lldb android bots. These run lldb tests only. They're also currently in "experimental" mode (not sending emails) because they are not reliable enough (main, but not only reason is the flakyness of the physical connection to the android devices). With the new

Re: [lldb-dev] Support for Error Strings in remote protocol

+1 one from me. I like the idea a lot. Specific details below. On 21 June 2017 at 16:31, Ravitheja Addepally via lldb-dev wrote: > Hello all, >Currently the remote protocol in LLDB does not allow sending Error > Strings in response to remote packets, it only allows for "ENN" format where

Re: [lldb-dev] Support for Error Strings in remote protocol

On 22 June 2017 at 00:18, Stephane Sezer via lldb-dev wrote: > What's the specific use case that you're trying to support with error > messages in the protocol? My initial thought on this is that it's not really > the debug server's job to generate human-readable error messages and that > the debu

Re: [lldb-dev] [llvm-dev] RFC: Cleaning up the Itanium demangler

On 22 June 2017 at 15:21, Erik Pilkington wrote: > > > > On June 22, 2017 at 5:51:39 AM, Pavel Labath (lab...@google.com) wrote: > > I don't have any concrete feedback, but: > > - +1 for removing the "FastDemagler" > > - If you already construct an AST as a part of your demangling > process, would

Re: [lldb-dev] Support for Error Strings in remote protocol

On 26 June 2017 at 18:19, Chris Quenelle via lldb-dev wrote: > > My main concern was that *if* strings are added, there's some > clear documentation about the relationship between the string > and the number to explain what's going on. Based on other > emails in this thread it seems like the numb

Re: [lldb-dev] Core file on arm32

Hi Chunseok, I am not aware of any plans for supporting arm core files. However, I think it would be a useful addition, and probably not that hard altogether. It probably just takes a patch similar to the one you quoted above. Currently I think it's just waiting for someone who cares about it enoug

Re: [lldb-dev] www/architecture.html

That sounds fair, we should definitely make sure we're on the same page. I've put up D34872 to better document state of affairs after the recent refactors. I am a bit reluctant to try to document the "direction we're heading towards" because that is something where I am still developing clarity, a

Re: [lldb-dev] Python scripting in Windows LLDB

On 30 June 2017 at 21:34, Ted Woodward via lldb-dev wrote: > I’ve seen crashes on Linux when building with 2.7.6 and using the 2.7.3 > .so/library directory, so I’m not willing to say building on Windows with > 3.6.1 and using the 3.5.2 dll/library directory will work. This is a bit problematic se

Re: [lldb-dev] environment vars not passed through to linux targets

Yes, that looks like a bug. Inheriting the target environment in the default case sounds like a good thing to do. I had a feeling it used to work at some point, but I could be wrong... On 6 July 2017 at 05:04, Christopher Book via lldb-dev wrote: > Yes, exactly. So things like LD_LIBRARY_PATH, P

Re: [lldb-dev] Port LLDB to ppc64le (ABIv2) on linux

Hi Gustavo, I don't see anything which should prevent you from doing that. Probably the first place you should look at is "source/Plugins/Process/Linux/NativeRegisterContext_***". This is the thing which defines what a "register" is and how to read/write it, and it's the main thing you will need

Re: [lldb-dev] check-lldb-single hang

On 7 July 2017 at 09:11, Nitesh Jain via lldb-dev wrote: > Hi, > > > > The “ninja -j1 check-lldb-single” hangs on MIPS-Linux after running all the > tests successfully (0 failures 0 errors) with latest ToT. It doesn’t print > summary message and does not return to prompt. > > Even with “LLDB_TEST

Re: [lldb-dev] Skipping registers when restore register state after a function call

I'm not sure there is a good way to do that currently. However, if you tell us what is the higher level problem you are trying to solve, we may be able to provide an alternative (right now, the only reason I can think of why you would *not* want to save/restore all registers is the orig_rax pseudo

Re: [lldb-dev] Skipping registers when restore register state after a function call

Aha, I see. I take it these are some registers which provide the state of the cpu, but are not modifiable by user code. Presumably the same crash would happen if the user manually issued a "register write" command (?) The fact that the stub crashes after this command sounds like a bug in the stub

Re: [lldb-dev] Skipping registers when restore register state after a function call

We've ran into the same issue when we were adding the "dynamic register size" fields, which is mips thing. I think we need a more flexible way of specifying the register context structs (constexpr constructors?) which will not suffer from these issues. On 14 July 2017 at 16:39, Tatyana Krasnukha

[lldb-dev] Pavel OOO

I will be on parental leave for the next ~three months. I will take a peek on the mailing lists from time to time, but my response times will be unpredictable, and I probably won't be in a position to help with troubleshooting any linux/android issues. For the time being, please direct your linux&

Re: [lldb-dev] lldb-server link failure with shared library configuration

On 30 August 2017 at 13:12, Tamas Berghammer via lldb-dev wrote: > I tried to build using the following command what should be a reasonably > close approximation to the one you used (I don't have ICU installed at the > moment) and it still links fine for me: > CC=/usr/bin/clang CXX=/usr/bin/clang+

Re: [lldb-dev] 64bit atomic ops on 32bit platforms

On 9 August 2017 at 20:18, Joerg Sonnenberger via lldb-dev wrote: > On Wed, Aug 02, 2017 at 03:47:56PM +0200, Joerg Sonnenberger via lldb-dev > wrote: >> (a) Make the mutex explicit if 64bit operations are not lock-free. >> >> or >> >> (b) Weaken the consistency constraints to provide eventually-

Re: [lldb-dev] What's the best way to use "--all-files" option from python?

On 25 October 2017 at 09:41, Greg Clayton via lldb-dev wrote: > Are glob characters legal file characters on any systems? All unix systems accept '*' as file names. In fact, the only system I know of, where that is not a legal filename is windows. ___

[lldb-dev] check-lldb will start using in-tree clang by default

I am going to check in a change (D39215) which causes the check-lldb target to use the just-built clang for compiling the test inferiors (instead of the system compiler, which was the old default). The main reason for this is to provide better reproducibility of test results between different machi

Re: [lldb-dev] check-lldb will start using in-tree clang by default

e/work/build-lldb/tools/lldb/test && >> /usr/bin/python2.7 >> /home/davide/work/llvm-lldb/tools/lldb/test/dotest.py -q --arch=x86_64 >> --executable /home/davide/work/build-lldb/bin/lldb -s >> /home/davide/work/build-lldb/lldb-test-traces -S nm -u CXXFLAGS -u >>

Re: [lldb-dev] check-lldb will start using in-tree clang by default

gt;>> return os.path.isfile(fpath) and os.access(fpath, os.X_OK) >>>> File "/usr/lib64/python2.7/genericpath.py", line 37, in isfile >>>> st = os.stat(path) >>>> TypeError: coercing to Unicode: need string or buffer, NoneType found >

Re: [lldb-dev] check-lldb will start using in-tree clang by default

On 27 October 2017 at 13:28, Zachary Turner wrote: > Maybe make it a dependency of the `check-lldb` target instead of the `lldb` > target? > +1 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] RFC: Adding a JSON library to LLVM Support

On 27 October 2017 at 13:23, Sam McCall wrote: > On Fri, Oct 27, 2017 at 10:06 PM, Pavel Labath wrote: >> >> LLDB has a JSON parser/serializer that we'd like to get rid of. > > Ah, sorry for missing that! > What makes you want to get rid of it? Maintenance/duplication, or things you > don't like

Re: [lldb-dev] check-lldb will start using in-tree clang by default

Ship it. On 27 October 2017 at 13:56, Davide Italiano wrote: > Take 2 (it can't be in the top-level CMakeList because the check-lldb > target is declared elsewhere). > > $ git diff HEAD > diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt > index d5d71d1..958f9f3 100644 > --- a/test/CMakeList

Re: [lldb-dev] purpose of ProcessGDBRemote::m_flags

If it's not used, we should just remove it. Once we have a use case for something like that, we can consider whether the Architecture plugin would be the proper place for it. On 3 November 2017 at 14:27, Tatyana Krasnukha via lldb-dev wrote: > Hello, > > > > I have questions about ProcessGDBRemo

Re: [lldb-dev] purpose of ProcessGDBRemote::m_flags

gone in r317377 On 3 November 2017 at 21:42, Tatyana Krasnukha via lldb-dev wrote: > Sorry, I was unclear – I mean existing recently added plugin “Architecture”. > And “dynamic” configuration is not necessary retrieved from gdb-server. > > > > From: Greg Clayton [mailto:clayb...@gmail.com] > Sent

Re: [lldb-dev] Bot failure with new "in tree compiler" changes (r316728) in llvm.org bot

You probably just need to nuke the build folder. The reason for that is that before the patch the LLDB_TEST_C_COMPILER variable was used for a different purpose (and usually empty), where as now it's set by default to the in-tree clang. However, cmake will not overwrite the cached value by design.

[lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

Hello lldb-dev, We've just updated our mac buildbot to 10.13.1 (from 10.10.x), and we're having trouble with the lldb test suite. All of the tests are failing with the following error: /Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c:15:10: fatal err

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

On a somewhat tangential note: Is anyone actually using this crashinfo hook? It looks like this could be useful in the old dotest days, when we were running all of the tests in a single python process, but now with the parallel test runner spawning a new process for each test file and with piping

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

ad to > subtle errors if you ever try to use Xcode, so I don’t suggest that. > > I think you need to put an Xcode install on your bot. > > Jim > >> On Nov 15, 2017, at 8:20 AM, Pavel Labath via lldb-dev >> wrote: >> >> On a somewhat tangential note: >>

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

gt; /System/Library/Frameworks frameworks; I’m a little surprised you can build >>> anything w/o an Xcode install. There’s a “command line tools” package in >>> the Developer tools that puts some stuff back in /usr but that has had some >>> issues, mostly it overwrites

Re: [lldb-dev] Unable to Locate lldb-server on Ubuntu

I think that's a question for your distro's (or ubuntu's) lldb package maintainer. I think they probably have some custom patches there (if they don't then they probably need them). If I'm not mistaken vanilla lldb does not even support multiple lldb instalations side-by-side (i.e., it will always

Re: [lldb-dev] race condition using gdb-remote over ssh port forwarding

On 27 November 2017 at 20:33, Christopher Book via lldb-dev wrote: > Greetings, I've been using liblldb to remotely debug to a linux server with > port forwarding. To do this, I start lldb-server to with --listen > specifying a localhost port, as well as with min-gdbserver-port and > --max-gd

Re: [lldb-dev] race condition using gdb-remote over ssh port forwarding

On 28 November 2017 at 20:54, Christopher Book wrote: > Hi Pavel, I think you are on the right track in that it already does seem to > wait for the gdbserver to be up using a pipe. > > In StartDebugserverProcess it seems like there is a pipe created to tell > when the server is running. Here is a

Re: [lldb-dev] race condition using gdb-remote over ssh port forwarding

On 28 November 2017 at 18:31, Greg Clayton wrote: > >> On Nov 28, 2017, at 2:25 AM, Pavel Labath via lldb-dev >> wrote: >> The most port-forwarder-friendly solution (and one that I've been >> wanting to implement for a while, but never got around to it) I can

Re: [lldb-dev] Allocation memory is failing in PPC64le

On linux, we allocate memory by setting up the inferior registers to appear as if the inferior called mmap(2) upon resume. This is done in InferiorCallMmap. You should check whether this function sets up the context correctly. Things to look at are: - did it find the mmap address correctly? - are t

Re: [lldb-dev] gdb-remote incompatibility with gdbserver?

On 6 December 2017 at 12:40, Pedro Alves via lldb-dev wrote: > On 12/05/2017 11:17 PM, David Manouchehri wrote: >> Is there a user accessible setting to force on XML target descriptions >> in new-gdbsever? > > In gdbserver? Nope. > > There's a setting in GDB to force it to not fetch descriptions,

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

ed around, as I tried to export > SDKROOT=macosx but that didn't work for me. > Do you have a patch or a series of commands I can run? > > Thanks, > > -- > Davide > > On Thu, Nov 16, 2017 at 4:25 AM, Pavel Labath via lldb-dev > wrote: >> Right, after learning way

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

On 18 December 2017 at 23:51, Adrian Prantl wrote: > I also just hit this and apparently this is an intentional behavior of xcrun. > > Note that this only affects systems that have the so-called command line > tools installed (this is what you get when you install the command line tools > withou

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

On 19 December 2017 at 18:06, Greg Clayton wrote: > > The crash hook is needed since ReportCrash on MacOS knows how to dig up a > crash log line for each shared library that is currently loaded in a process > when it generates a crash report. There are settings that we can enable to > enable al

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

On 19 December 2017 at 17:39, Greg Clayton via lldb-dev wrote: > The apple accelerator tables are only enabled for Darwin target, but there > is nothing to say we couldn't enable these for other targets in ELF files. > It would be a quick way to gauge the performance improvement that these > accel

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

On 20 December 2017 at 18:40, Greg Clayton wrote: > >> On Dec 20, 2017, at 3:33 AM, Pavel Labath wrote: >> >> On 19 December 2017 at 17:39, Greg Clayton via lldb-dev >> wrote: >>> The apple accelerator tables are only enabled for Darwin target, but there >>> is nothing to say we couldn't enable

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

On 21 December 2017 at 12:29, xgsa wrote: > 21.12.2017, 13:45, "Pavel Labath via lldb-dev" : >> On 20 December 2017 at 18:40, Greg Clayton wrote: >>>> On Dec 20, 2017, at 3:33 AM, Pavel Labath wrote: >>>> >>>> On 19 December 2017 at 17

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

On 21 December 2017 at 10:45, Pavel Labath wrote: > I'm not sure now whether you're suggesting to use the dsymutil > approach just to gauge the potential speedup we can obtain and get > people interested, or as a productized solution. If it's the first one > then I fully agree with you. Although I

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

That's not the case, the nested debugger get's stopped in CommandObjectTargetCreate::DoExecute before it even touches the /bin/ls file. I could have passed anything there (probably /bin/ls wasn't the best choice though), it's just this was the easiest thing I came up with for stopping at a place wi

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

On 21 December 2017 at 16:22, Greg Clayton wrote: > > > The main idea is to touch as few pages as possible when doing searches. We > effectively have this scenario right now with Apple DWARF in .o file > debugging. So much time is spent paging in each accelerator table that we > have very long del

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

On 2 January 2018 at 19:20, Jim Ingham wrote: > This is actually using the same mechanism that Greg was describing, but > through a separate route. > > With the crashinfo mechanism in place, if a test crashes the crash log will > show whatever test was being run at the time of the crash. This w

Re: [lldb-dev] Loading object file to target flash memory using vFlashWrite

On 10 January 2018 at 22:17, Owen Shaw via lldb-dev wrote: > Thanks! > > ObjectFileELF::SetLoadAddress(...) is where I already have a change > that got things working, just wasn't sure if I'd be stepping on > anything else that relied on the values set there. > > Looks like I dropped the dev list

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

Hello all, In it was brought up that there are at least two parties interested in having DWARF5 accelerator tables implemented, so I'm writing this email to see if there's anyone else interested in this topic, and to try to synchronize our efforts. Our int

Re: [lldb-dev] Questions about the LLDB testsuite and improving its reliability

Looks like I missed a party. :) I'll try to give my thoughts on some of the things that were said here: > make -C I don't think make -C does what you think it does. "make -C foo" is basically equivalent to "cd foo && make", which is what we are doing now already. Of course, you can make this work

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

Thank you for all the responses. Unfortunately I wasn't able to make any progress on creating the patches today. I'll be sure to add everyone who expressed interest here to the phabricator diff once I have them ready. Jonas, do you have any dsymutil patches I can look at? I am interested in seeing

Re: [lldb-dev] Questions about the LLDB testsuite and improving its reliability

On 18 January 2018 at 17:52, Adrian Prantl wrote: > > >> On Jan 18, 2018, at 5:07 AM, Pavel Labath wrote: >> >> Looks like I missed a party. :) >> >> I'll try to give my thoughts on some of the things that were said here: >> >>> make -C >> I don't think make -C does what you think it does. "make

Re: [lldb-dev] Anybody using the Go/Java debugger plugins?

The Go support for added by Ryan as a 20% project. Now that he's no longer working for Google, it's pretty much abandoned. The Java support was added by us (android folks) to support java debugging (to a certain extent). However, we never really finished the project, so we're not using that code no

Re: [lldb-dev] Huge mangled names are causing long delays when loading symbol table symbols

The mangled name length threshold would be the easiest to implement. However, I fear we may not be able to find a good cutoff length, because it's not the length of it that matters, but the number (and recursiveness) of back-references. For example, I was able to find a mangled name of 757 characte

Re: [lldb-dev] Rust language support question

To these very insightful emails from Greg and Jim, I'd just like to add one request. Please consider the testing strategy of the code you write early on. One of the problems that we have with these language plugins (and why we now have a separate thread considering removal of some of them) is that

Re: [lldb-dev] Rust language support question

On 29 January 2018 at 18:39, Tom Tromey wrote: >> "Pavel" == Pavel Labath writes: > > Pavel> To these very insightful emails from Greg and Jim, I'd just like to > Pavel> add one request. Please consider the testing strategy of the code you > Pavel> write early on. One of the problems that we

Re: [lldb-dev] Anybody using the Go/Java debugger plugins?

e, and the code for it > was pretty thin. I would be okay with pulling that out unless somebody is > actually getting good use out of it. > > Jim > >> On Jan 22, 2018, at 10:17 AM, Pavel Labath via lldb-dev >> wrote: >> >> The Go support for added by Rya

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

Hello all, I am looking for feedback regarding implementation of the case folding algorithm for .debug_names hashes. Unlike the apple tables, the .debug_names hashes are computed from case-folded names (to enable case-insensitive lookups for languages where that makes sense). The dwarf5 document

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

On 30 January 2018 at 15:41, Adrian Prantl wrote: > > >> On Jan 30, 2018, at 7:35 AM, Pavel Labath wrote: >> >> Hello all, >> >> I am looking for feedback regarding implementation of the case folding >> algorithm for .debug_names hashes. >> >> Unlike the apple tables, the .debug_names hashes are

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

On 30 January 2018 at 16:39, Jan Kratochvil wrote: > On Wed, 17 Jan 2018 17:13:36 +0100, Pavel Labath via lldb-dev wrote: >> so I'm writing this email to see if there's anyone >> else interested in this topic, and to try to synchronize our efforts. > > I am sure int

Re: [lldb-dev] Anybody using the Go/Java debugger plugins?

On 30 January 2018 at 23:21, Davide Italiano wrote: > I agree. Just to check: Does that apply to Tamas's paragraph below, as in that's the guidelines we should be giving to new language plugin implementors? If that's the case, then I agree as well, although I think we should be a bit more clean

[lldb-dev] Querying build configuration of (lib)lldb from tests.

Hello all, In we have a feature that only works when lldb was built with xml support. To test this, we need the test to know whether we were build with xml support. The typical llvm solution would be to generate some dotest equivalent of lit.site.cfg at build ti

Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions

On 6 February 2018 at 04:11, Davide Italiano via lldb-dev wrote: > Hi, > in the last couple of months a lot of people put a lot of attentions > and energy into lldb and we're starting to see the first results. I > decided to sit down and write this e-mail to state where we are and > what are some

Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions

On 6 February 2018 at 15:41, Davide Italiano wrote: > On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath wrote: >> On 6 February 2018 at 04:11, Davide Italiano via lldb-dev >> >> So, I guess my question is: are you guys looking into making sure that >> others are also able to reproduce the 0-fail+0-xpa

Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions

enting a whole test framework. So, I'm not sure where you were heading with that question.. On 6 February 2018 at 18:53, Zachary Turner wrote: > > > On Tue, Feb 6, 2018 at 8:19 AM Pavel Labath via lldb-dev > wrote: >> >> On 6 February 2018 at 15:41, Davide Italiano

Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions

On 7 February 2018 at 14:20, Zachary Turner wrote: > > As someone who gave up on trying to set up a bot due to flakiness, I have a > different experience. I did not say it was easy to get to the present point, and I am certain that the situation is much harder on windows. But I believe this is du

Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions

On 6 February 2018 at 15:51, Davide Italiano wrote: > > FWIW, I strongly believe we should all agree on a configuration to run > tests and standardize on that. > It's unfortunate that we have two build systems, but there are plans > to move away from manually generating xcodebuild, as many agree i

Re: [lldb-dev] hashing pointers to strings

[ Clang's emission of pubnames/pubtypes is controlled by the "debugger tuning" parameter. With -glldb they don't get emitted, with -ggdb, they do. (-glldb is default on mac, -ggdb elsewhere). In dwarf5 these sections have been dropped in favour of the new .debug_names section. ] On 10 February 201

Re: [lldb-dev] How to test lldb-vscode?

Mocking the VS side (in python or C++) sounds like the way to go. I don't know much smartness is in this code (as in, something other than "take this json, translate it to an appropriate SB call and serialize the results back"), but if there is some non-trivial logic in there (perhaps the code for

Re: [lldb-dev] Pending breakpoints to dlsym()ed functions

+ eugene as the "most recent person who worked on the DYLD plugin" :D Hi Dmitry, I've tried your sample, and I was indeed able to reproduce the problem. What makes your case special is that "sin" and "cos" are indirect functions (STT_GNU_IFUNC), so we have to do some extra work (call the resolver

Re: [lldb-dev] Pending breakpoints to dlsym()ed functions

Yes, it looks that way, but I cannot reproduce this on my side (which is not surprising as it involves parsing debug info from your dynamic linker). I'd need the relevant portions of that file (or just the whole file) to see what's going on there. That said, this shouldn't impact you unless you pl

Re: [lldb-dev] Querying build configuration of (lib)lldb from tests.

going to be a problem, and the >> info is constant for the run of lldb, so you can cache the result. >> >> Jim >> >> >>> On Feb 5, 2018, at 4:01 AM, Pavel Labath via lldb-dev >>> wrote: >>> >>> Hello all, >>> >>>

Re: [lldb-dev] problem with TestLoadUnload.py

A couple of things here: - there should be no performance difference between doing build in setUp and the test function as setUp is called once per test function - my change was to run have the paralelization at a file level (previously it was at folder-level). All test functions in a single file a

Re: [lldb-dev] Current state of the unit tests

On 23 February 2018 at 15:17, Vedant Kumar wrote: > Second, TestClient::SendMessage is generating quite a lot of "INFO" output > which clutters up the terminal. Pavel, would you mind if I removed this > logging? > Yeah, we should probably do that. The idea here was that the packet log would pro

Re: [lldb-dev] Current state of the unit tests

Yeah, if a lit test fails, the dotest tests will not get run. That is fine, but having a target which only runs dotest tests would probably be nice as well. On 23 February 2018 at 16:15, Vedant Kumar wrote: > check-lldb-lit should just be a dependency of check-lldb, so the dotest.py > tests shoul

Re: [lldb-dev] Current state of the unit tests

On 23 February 2018 at 16:19, Adrian McCarthy wrote: > I'm also seeing windows appear and quickly vanish a several times while > running the lit tests. That's because the tests run inferiors and lldb on windows will always run them in a separate console window. IIRC, there is a special hack in do

Re: [lldb-dev] FreeBSD LLDB buildbot

On 26 February 2018 at 19:32, Ed Maste via lldb-dev wrote: > 5. I copied the scripts (updateScripts.sh, checkoutSource.sh, etc.) > from the previous buildbot installation (into scratch/scripts/). I > think we should host all scripts for the builders in either the lldb > or zorg repo - is there a r

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

This probably isn't arch-dependent. More likely you just have a different version of libstdc++. Can you share how the std::unique_ptr layout looks like for you. This is how my std::unique_ptr looks like (from libstdc++.so.6.0.22): (lldb) fr var X -R -T (std::unique_ptr >) X = { (std::unique_ptr

<    1   2   3   4   5   6   >