Re: [lldb-dev] CFP for the 6th European LLVM conference on March 17-18, 2016 in Barcelona, Spain
Reminder: the deadline for submitting papers for the EuroLLVM 2016 in Barcelona is in 2 weeks. Kind regards, -- Arnaud A. de Grandmaison On Sun, Dec 13, 2015 at 11:42 PM, Arnaud Allard de Grandmaison < arnaud.ad...@gmail.com> wrote: > We are pleased to announce the 6th European LLVM conference on March > 17-18, 2016 in Barcelona, Spain. > > This will be a full two-day conference which aims to present the latest > developments around LLVM and help strengthen the network of LLVM developers > and users. The format will be similar to that of the previous meetings, > with ample time for presentations, discussion, and networking between > participants. The meeting is open to anyone whether from industry or > academia, professional or enthusiast and is not restricted to those from > Europe - attendees from all regions are welcome ! > > EuroLLVM 2016 will be held at Princesa Sofia Hotel ( > http://www.princesasofia.com/en), collocated with the International > Compiler Construction conference (http://cc2016.eew.technion.ac.il/) and > CGO (http://cgo.org/cgo2016/) > > We invite academic, industrial and hobbyist speakers to present their work > on developing or using LLVM, Clang, etc. Proposals for technical > presentations, posters, workshops, demonstrations and BoFs are welcome. > Material will be chosen to cover a broad spectrum of themes and topics at > various depths, some technical deep-diving, some more community focused. > > We are looking for: > - Keynote speakers. > - Technical presentations (30 minutes plus questions and discussion) > related to the development of LLVM, Clang, LLD, LLDB, Polly, ... > - Presentations relating to academic or commercial use of LLVM, Clang > etc. > - Lightning talks (5 minutes, no questions, no discussion). > - Workshops and in-depth tutorials (1-2 hours - please specify in your > submission). > - Poster presentations. > - Birds of a Feather sessions (BoFs). > > **Important dates** > The deadline for receiving submissions is January 25, 2016. > Speakers will be notified of acceptance or rejection by February 15th, > 2016. > > **Submissions** > Submissions should be done using the Easychair platform: > - https://easychair.org/conferences/?conf=eurollvm2016 > > Please note that presentation materials and videos for the technical > sessions will be posted on llvm.org after the conference. We have > reserved additional spots for speakers, such that they can attend the > conference even though we have reached our registration limit. > > In terms of submission style, we are looking for: > - A title and an extended abstract, > OR > - A title, abstract and slides. > > Please make clear the status of the slides (are they a skeleton of your > presentation with the detail missing ?), or, perhaps a section of detail > that lacks introduction and conclusions? Also make sure to give enough > information in the extended abstract: the more you can give us and tell us > the easier it will be for us to be positive about your submission. > > Proposals that are not sufficiently detailed (talks lacking a > comprehensive abstract for example) are likely to be rejected. Slides and > posters must be in PDF format. > > **About LLVM** > The LLVM Infrastructure is a collection of libraries and tools that make > it easy to build compilers, optimizers, Just-In-Time code generators, and > many other compiler-related programs. LLVM uses a single, > language-independent virtual instruction set both as an offline code > representation (to communicate code between compiler phases and to run-time > systems) and as the compiler internal representation (to analyse and > transform programs). > > This persistent code representation allows a common set of sophisticated > compiler techniques to be applied at compile-time, link-time, install-time, > run-time, or "idle-time" (between program runs). The strengths of the LLVM > infrastructure are its extremely simple design (which makes it easy to > understand and use), source-language independence, powerful mid-level > optimizer, automated compiler debugging support, extensibility, and its > stability and reliability. > > LLVM is currently being used to host a wide variety of Academic Research > projects and commercial projects. > > For more information, please visit: > - http://llvm.org/devmtg/2016-03/ > > We are looking forward to seeing you in Barcelona ! > -- > Arnaud A. de Grandmaison > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
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
> current trunk, you should not experience this problem anymore. If you
> still notice the problem with the trunk lldb, then please let me know.
>
>> Has anything changed in the API over the past year? It looks like LLDB is
>> creating a server internally; it is terminating quickly for some reason, and
>> the LLDB parent is waiting forever for its server.
> LLDB now spawns a server which performs the actual debugging work
> (which means you can now debug remotely as well), but that should not
> affect the API in any noticeable way.
>
> cheers,
> pl
>
>
> On 9 January 2016 at 01:42, David Jones via lldb-dev
> wrote:
>> I have some code which worked under LLVM+LLDB 3.6.0 which runs as follows:
>> its purpose is to run some code, and print a backtrace if the code
>> segfaults. My approach was:
>> - fork
>> - the child runs the main part of the program.
>> - the parent creates a debugger and attaches to the child. The child is
>> continued and allowed to run until either it terminates or faults.
>>
>> This code worked in 3.6.0:
>>
>> switch (pid = fork()) {
>> case -1:
>> return; // no trace
>>
>> case 0:
>> // child
>> fprintf(stderr, "child 1\n");
>> //pause();
>> fprintf(stderr, "child 2\n");
>> signal(SIGUSR1, SIG_DFL);
>> fprintf(stderr, "child 3\n");
>> return;
>>
>> default:
>> // parent: create debugger
>> {
>> StateType state;
>> //SBAttachInfoai(pid);
>>
>> SBDebugger::Initialize();
>> m_Debugger = SBDebugger::Create(false);
>> if (!m_Debugger.IsValid())
>> fprintf (stderr, "error: failed to create a debugger
>> object\n");
>> m_Debugger.SetAsync(false);
>> m_Listener = m_Debugger.GetListener();
>> m_Target = m_Debugger.CreateTarget(exec_name);
>> fprintf(stderr, "parent 1\n");
>> //m_Target.Attach(ai, m_Error);
>> m_Target.AttachToProcessWithID(m_Listener, pid, m_Error);
>> fprintf(stderr, "parent 2\n");
>>
>>
>> Under LLVM+LLDB 3.7.1, I see the following instead:
>> - the child runs to completion (child 1/2/3 messages print out).
>> - the parent hangs in attach (parent 1 prints out but parent 2 does not)
>>
>> Debugging the whole thing under GDB (unsure how reliable this is, but the
>> hang happens w/o GDB as well) shows:
>>
>> child 1
>> child 2
>> child 3
>> [ child prints out other stuff and runs happily ]
>> parent 1
>> [ child terminates ]
>> [New Thread 0x7fffed043700 (LWP 470)]
>> [New Thread 0x7fffec842700 (LWP 472)]
>> [Thread 0x7fffec842700 (LWP 472) exited]
>> ^C
>> Program received signal SIGINT, Interrupt.
>> 0x72bd566b in pthread_join (threadid=140737169864448,
>> thread_return=0x0)
>> at pthread_join.c:92
>> 92 pthread_join.c: No such file or directory.
>> (gdb) bt
>> #0 0x72bd566b in pthread_join (threadid=140737169864448,
>> thread_return=0x0) at pthread_join.c:92
>> #1 0x75f8247c in lldb_private::HostThreadPosix::Join(void**) ()
>>from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #2 0x75f7034d in lldb_private::HostThread::Join(void**) ()
>>from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #3 0x7610802e in
>> lldb_private::process_gdb_remote::GDBRemoteCommunication::StartDebugserverProcess(char
>> const*, unsigned short, lldb_private::ProcessLaunchInfo&, unsigned short&)
>> () from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #4 0x7612f5c0 in
>> lldb_private::process_gdb_remote::ProcessGDBRemote::LaunchAndConnectToDebugserver(lldb_private::ProcessInfo
>> const&) ()
>>from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #5 0x7612fbde in
>> lldb_private::process_gdb_remote::ProcessGDBRemote::DoAttachToProcessWithID(unsigned
>> long, lldb_private::ProcessAttachInfo const&) ()
>>from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #6 0x7623efa5 in
>> lldb_private::Process::Attach(lldb_private::ProcessAttachInfo&) () from
>> /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #7 0x77025cc4 in
>> PlatformPOSIX::Attach(lldb_private::ProcessAttachInfo&,
>> lldb_private::Debugger&, lldb_private::Target*, lldb_private::Error&) ()
>>from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #8 0x7626ef52 in
>> lldb_private::Target::Attach(lldb_private::ProcessAttachInfo&,
>> lldb_private::Stream*) () from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #9 0x75d4a4d7 in (anonymous
>> namespace)::AttachToProcess(lldb_private::ProcessAttachInfo&,
>> lldb_private::Target&) ()
>>from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #10 0x75d4a149 in
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 feature? ;) If so, I know a couple of people, who would be very pleased by that. :) cheers, pl On 9 January 2016 at 20:06, Ori Avtalion via lldb-dev wrote: > Hi, > > I tried using lldb (and the Swift repl, which uses it), and found it > very annoying that the CTRL+left/right arrow key sequence isn't > handled correctly, spewing ;5D and ;5C instead. > > I'm used to be able to hit Ctrl+left/right to jump between words in > almost any editing software. > > Is it a feature that would be welcome? > > Thanks, > Ori > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Using control+left/right arrow to jump between words in the prompt
On Mon, Jan 11, 2016 at 11:40 AM, Pavel Labath wrote: >> Is it a feature that would be welcome? > Is this an offer to implement the feature? ;) > If so, I know a couple of people, who would be very pleased by that. :) I'm willing to implement it (or at least try :P), but first I wanted to gauge interest and get approval, as I don't know how the project decides on new features. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 25921] 3.7 LLDB is broken on i686, while 3.8 (trunk) is just fine
https://llvm.org/bugs/show_bug.cgi?id=25921 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from lab...@google.com --- I'm gonna close the issue then. It would still be good if you could check out 3.8 early to make sure it works for you. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB build at windows
thanks. i build successefuly llvm and lldb with ninja and cl compiler. If i build VS solution without options on CMake then i have ever more errors around unittests in llvm. like that: "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) -> "d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj.metaproj" (целевой объект по умолчанию) (749) -> "d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj" (целевой объект по умолчани ю) (750) -> (Целевой объект ClCompile) -> D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error C2327: 'll vm::PointerEmbeddedInt::Value': is not a type name, static, or enume rator (compiling source file D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedInt Test.cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj] D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error C2065: 'Va lue': undeclared identifier (compiling source file D:\code\llvm\llvm\unittests\ ADT\PointerEmbeddedIntTest.cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxp roj] D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error C2327: 'll vm::PointerEmbeddedInt::Value': is not a type name, static, or enumerato r (compiling source file D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest .cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj] D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(34): error C2338: Can not embed more bits than we have in a pointer! (compiling source file D:\code\l lvm\llvm\unittests\ADT\PointerEmbeddedIntTest.cpp) [d:\code\llvm\build\unittest s\ADT\ADTTests.vcxproj] D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error C2327: 'll vm::PointerEmbeddedInt::Value': is not a type name, static, or enumerato r (compiling source file D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest .cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj] D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error C2065: 'Va lue': undeclared identifier (compiling source file D:\code\llvm\llvm\unittests\ ADT\PointerEmbeddedIntTest.cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxp roj] 2016-01-11 0:56 GMT+03:00 Zachary Turner : > I have never built with -DLLVM_INCLUDE_TESTS=OFF > -DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF before, so that > could be related. Can you try removing those options on CMake to see if > that fixes it? > > The other thing I do differently is I use ninja generator. So I use -G > Ninja instead of -G "Visual Studio 14 2015". Building from within Visual > Studio like you're doing is supposed to work, I just don't know if anyone > tests it. My command line is usually: > > cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DPYTHON_HOME= python\x86 from dest variable> ..\llvm > > ninja > > > On Sun, Jan 10, 2016 at 4:02 AM Red Skotina wrote: > >> thanks. >> i still have 5 errors while linking >> "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) -> >> "d:\code\llvm\build\tools\lldb\unittests\LLDBUnitTests.vcxproj.metaproj" >> (целев >> ой объект по умолчанию) (741) -> >> >> "d:\code\llvm\build\tools\lldb\unittests\Utility\UtilityTests.vcxproj.metaproj" >> (целевой объект по умолчанию) (742) -> >> "d:\code\llvm\build\tools\lldb\unittests\Utility\UtilityTests.vcxproj" >> (целевой >> объект по умолчанию) (743) -> >> LINK : fatal error LNK1181: cannot open input file 'gtest.lib' >> [d:\code\llvm\ >> build\tools\lldb\unittests\Utility\UtilityTests.vcxproj] >> >> my commands: >> >> cmake -G "Visual Studio 14 2015" -DCMAKE_BUILD_TYPE=Release >> -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFF >> -DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF >> -DPYTHON_HOME= ..\llvm >> >> msbuild LLVM.sln /p:Configuration=Release;Platform=Win32 >> >> i look to llvm\tools\lldb\gtest and cant find any file. here is only >> empty directories. >> should i download something or should skip unittests ? >> >> 2016-01-10 6:28 GMT+03:00 Zachary Turner : >> >>> Should look like this: >>> >>> llvm >>> |__ tools >>> |__ clang >>> |__ lld >>> |__ lldb >>> >>> You will need clang because lldb needs to link against it, and you will >>> need lld because lldb on Windows doesn't (yet) understand PDB, so you have >>> to compile your programs with clang.exe -fuse-ld=lld >>> >>> >>> >>> On Sat, Jan 9, 2016 at 1:29 PM Red Skotina via lldb-dev < >>> lldb-dev@lists.llvm.org> wrote: >>> If i want compile as part of llvm then what is destination directory for lldb trunk sources ? I has placed this in llvm/projects/lldb and has much errors while compiling lldb with MSVC 2015. "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) -> "d:\code\llvm\build\ALL_BUILD.vcxproj.metaproj" (целевой объект по умолчанию) ( 2) -> "d:\code\llvm\build\projects\lldb\finish_swig.vcxproj.metaproj" (целевой объект по умолчанию) (482) -> "d:\code\llvm\build\projects\lldb\source\API\liblldb.vcxproj.metaproj" (целевой объект по умолча
Re: [lldb-dev] LLDB build at windows
Yea, unfortunately the way things work is that the person who is affected by the problem and who needs it fixed is usually the one that needs to fix it. Right now we don't have any Windows people building inside Visual Studio, so nobody has fixed that. But you're welcome to submit a patch :) FWIW, I actually generate CMake twice, into two separate folders. I have build/vs and build/ninja. In the vs directory I generate using "Visual Studio 14 2015" generator, and in ninja I generate using Ninja generator. I build from the Ninja folder, and I use the vs folder just for opening a solution, source browsing, and debugging (i.e. change the Debugger settings to point the executable into the ninja folder). This way you still do everything from vs, just not the compile step. On Mon, Jan 11, 2016 at 9:16 AM Red Skotina wrote: > thanks. i build successefuly llvm and lldb with ninja and cl compiler. > > If i build VS solution without options on CMake then i have ever more > errors around unittests in llvm. > > like that: > > "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) -> > "d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj.metaproj" (целевой > объект по > умолчанию) (749) -> > "d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj" (целевой объект по > умолчани > ю) (750) -> > (Целевой объект ClCompile) -> > D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error > C2327: 'll > vm::PointerEmbeddedInt::Value': is not a type name, static, or > enume > rator (compiling source file > D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedInt > Test.cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj] > D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error > C2065: 'Va > lue': undeclared identifier (compiling source file > D:\code\llvm\llvm\unittests\ > ADT\PointerEmbeddedIntTest.cpp) > [d:\code\llvm\build\unittests\ADT\ADTTests.vcxp > roj] > D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error > C2327: 'll > vm::PointerEmbeddedInt::Value': is not a type name, static, or > enumerato > r (compiling source file > D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest > .cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj] > D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(34): error > C2338: Can > not embed more bits than we have in a pointer! (compiling source file > D:\code\l > lvm\llvm\unittests\ADT\PointerEmbeddedIntTest.cpp) > [d:\code\llvm\build\unittest > s\ADT\ADTTests.vcxproj] > D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error > C2327: 'll > vm::PointerEmbeddedInt::Value': is not a type name, static, or > enumerato > r (compiling source file > D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest > .cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj] > D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error > C2065: 'Va > lue': undeclared identifier (compiling source file > D:\code\llvm\llvm\unittests\ > ADT\PointerEmbeddedIntTest.cpp) > [d:\code\llvm\build\unittests\ADT\ADTTests.vcxp > roj] > > > 2016-01-11 0:56 GMT+03:00 Zachary Turner : > >> I have never built with -DLLVM_INCLUDE_TESTS=OFF >> -DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF before, so that >> could be related. Can you try removing those options on CMake to see if >> that fixes it? >> >> The other thing I do differently is I use ninja generator. So I use -G >> Ninja instead of -G "Visual Studio 14 2015". Building from within Visual >> Studio like you're doing is supposed to work, I just don't know if anyone >> tests it. My command line is usually: >> >> cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DPYTHON_HOME=> to python\x86 from dest variable> ..\llvm >> >> ninja >> >> >> On Sun, Jan 10, 2016 at 4:02 AM Red Skotina >> wrote: >> >>> thanks. >>> i still have 5 errors while linking >>> "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) -> >>> "d:\code\llvm\build\tools\lldb\unittests\LLDBUnitTests.vcxproj.metaproj" >>> (целев >>> ой объект по умолчанию) (741) -> >>> >>> "d:\code\llvm\build\tools\lldb\unittests\Utility\UtilityTests.vcxproj.metaproj" >>> (целевой объект по умолчанию) (742) -> >>> "d:\code\llvm\build\tools\lldb\unittests\Utility\UtilityTests.vcxproj" >>> (целевой >>> объект по умолчанию) (743) -> >>> LINK : fatal error LNK1181: cannot open input file 'gtest.lib' >>> [d:\code\llvm\ >>> build\tools\lldb\unittests\Utility\UtilityTests.vcxproj] >>> >>> my commands: >>> >>> cmake -G "Visual Studio 14 2015" -DCMAKE_BUILD_TYPE=Release >>> -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFF >>> -DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF >>> -DPYTHON_HOME= ..\llvm >>> >>> msbuild LLVM.sln /p:Configuration=Release;Platform=Win32 >>> >>> i look to llvm\tools\lldb\gtest and cant find any file. here is only >>> empty directories. >>> should i download something or should skip unittests ? >>> >>> 2016-01-10 6:28 GMT+03:00 Zachary Turner : >>> Should look like this: llvm |_
Re: [lldb-dev] Using control+left/right arrow to jump between words in the prompt
On OS X Ctrl left & right arrow are taken over by the system to move between virtual desktops. Instead, option left & right are the equivalent gesture for move by word on OS X, and in the OS X lldb, option left & right do indeed move by word. LLDB doesn't do most of this stuff by hand, it lets editline handle it, and so Ctrl-Arrow may be an optional feature you need to enable. I'd have no objection to turning this on for Linux and Windows if that is appropriate. The appropriate equivalent already works for OS X so this seems only fair. Jim > On Jan 11, 2016, at 2:50 AM, Ori Avtalion via lldb-dev > wrote: > > On Mon, Jan 11, 2016 at 11:40 AM, Pavel Labath wrote: >>> Is it a feature that would be welcome? >> Is this an offer to implement the feature? ;) >> If so, I know a couple of people, who would be very pleased by that. :) > > I'm willing to implement it (or at least try :P), but first I wanted to > gauge interest and get approval, as I don't know how the project decides > on new features. > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Using control+left/right arrow to jump between words in the prompt
So anything that is missing can be added to your ~/.editrc file since LLDB uses the editline library and that reads .editrc file. Examples of what you can add to your .editrc file: lldb:bind '^[[5C' vi-next-word lldb:bind '^[[5D' vi-prev-word lldb:bind '^D' ed-delete-next-char lldb:bind '^B' ed-command lldb:bind '^P' ed-search-prev-history lldb:bind '^N' ed-search-next-history For more info, just type "man editrc" at your shell command line. If you think any such bindings should be included by default, please file a bug and suggest what you think should be added by default. If you do add something you should think if the binding should be for vi or emacs bindings by default as these bindings often would differ between the two. > On Jan 9, 2016, at 12:06 PM, Ori Avtalion via lldb-dev > wrote: > > Hi, > > I tried using lldb (and the Swift repl, which uses it), and found it > very annoying that the CTRL+left/right arrow key sequence isn't > handled correctly, spewing ;5D and ;5C instead. > > I'm used to be able to hit Ctrl+left/right to jump between words in > almost any editing software. > > Is it a feature that would be welcome? > > Thanks, > Ori > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Using control+left/right arrow to jump between words in the prompt
On Mon, Jan 11, 2016 at 9:07 PM, Greg Clayton wrote: > If you think any such bindings should be included by default, please file a > bug and suggest what you think should be added by default. If you do add > something you should think if the binding should be for vi or emacs bindings > by default as these bindings often would differ between the two. OK. Pavel, perhaps you should open a separate bug about the arrow behavior in incremental search mode. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB build at windows
thanks for workaround 2016-01-11 21:48 GMT+03:00 Zachary Turner : > Yea, unfortunately the way things work is that the person who is affected > by the problem and who needs it fixed is usually the one that needs to fix > it. Right now we don't have any Windows people building inside Visual > Studio, so nobody has fixed that. But you're welcome to submit a patch :) > > FWIW, I actually generate CMake twice, into two separate folders. I have > build/vs and build/ninja. In the vs directory I generate using "Visual > Studio 14 2015" generator, and in ninja I generate using Ninja generator. > I build from the Ninja folder, and I use the vs folder just for opening a > solution, source browsing, and debugging (i.e. change the Debugger settings > to point the executable into the ninja folder). > > This way you still do everything from vs, just not the compile step. > > On Mon, Jan 11, 2016 at 9:16 AM Red Skotina wrote: > >> thanks. i build successefuly llvm and lldb with ninja and cl compiler. >> >> If i build VS solution without options on CMake then i have ever more >> errors around unittests in llvm. >> >> like that: >> >> "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) -> >> "d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj.metaproj" (целевой >> объект по >> умолчанию) (749) -> >> "d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj" (целевой объект по >> умолчани >> ю) (750) -> >> (Целевой объект ClCompile) -> >> D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error >> C2327: 'll >> vm::PointerEmbeddedInt::Value': is not a type name, static, or >> enume >> rator (compiling source file >> D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedInt >> Test.cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj] >> D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error >> C2065: 'Va >> lue': undeclared identifier (compiling source file >> D:\code\llvm\llvm\unittests\ >> ADT\PointerEmbeddedIntTest.cpp) >> [d:\code\llvm\build\unittests\ADT\ADTTests.vcxp >> roj] >> D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error >> C2327: 'll >> vm::PointerEmbeddedInt::Value': is not a type name, static, or >> enumerato >> r (compiling source file >> D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest >> .cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj] >> D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(34): error >> C2338: Can >> not embed more bits than we have in a pointer! (compiling source file >> D:\code\l >> lvm\llvm\unittests\ADT\PointerEmbeddedIntTest.cpp) >> [d:\code\llvm\build\unittest >> s\ADT\ADTTests.vcxproj] >> D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error >> C2327: 'll >> vm::PointerEmbeddedInt::Value': is not a type name, static, or >> enumerato >> r (compiling source file >> D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest >> .cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj] >> D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error >> C2065: 'Va >> lue': undeclared identifier (compiling source file >> D:\code\llvm\llvm\unittests\ >> ADT\PointerEmbeddedIntTest.cpp) >> [d:\code\llvm\build\unittests\ADT\ADTTests.vcxp >> roj] >> >> >> 2016-01-11 0:56 GMT+03:00 Zachary Turner : >> >>> I have never built with -DLLVM_INCLUDE_TESTS=OFF >>> -DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF before, so that >>> could be related. Can you try removing those options on CMake to see if >>> that fixes it? >>> >>> The other thing I do differently is I use ninja generator. So I use -G >>> Ninja instead of -G "Visual Studio 14 2015". Building from within Visual >>> Studio like you're doing is supposed to work, I just don't know if anyone >>> tests it. My command line is usually: >>> >>> cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DPYTHON_HOME=>> to python\x86 from dest variable> ..\llvm >>> >>> ninja >>> >>> >>> On Sun, Jan 10, 2016 at 4:02 AM Red Skotina >>> wrote: >>> thanks. i still have 5 errors while linking "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) -> "d:\code\llvm\build\tools\lldb\unittests\LLDBUnitTests.vcxproj.metaproj" (целев ой объект по умолчанию) (741) -> "d:\code\llvm\build\tools\lldb\unittests\Utility\UtilityTests.vcxproj.metaproj" (целевой объект по умолчанию) (742) -> "d:\code\llvm\build\tools\lldb\unittests\Utility\UtilityTests.vcxproj" (целевой объект по умолчанию) (743) -> LINK : fatal error LNK1181: cannot open input file 'gtest.lib' [d:\code\llvm\ build\tools\lldb\unittests\Utility\UtilityTests.vcxproj] my commands: cmake -G "Visual Studio 14 2015" -DCMAKE_BUILD_TYPE=Release -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFF -DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF -DPYTHON_HOME= ..\llvm msbuild LLVM.sln /p:Configuration=Release;Platform=Win32 i look to llvm\tools\lldb\gtest and cant find any file
