Re: [lldb-dev] [CFP] LLVM devroom @ FOSDEM 2017
Gentle reminder, the deadline is tomorrow, but we may extend to the end of the week. Keep your proposals coming. Thanks! cheers, -renato On 11 October 2016 at 14:25, Renato Golin wrote: > CALL FOR PAPERS / PARTICIPATION > > At FOSDEM 2017, LLVM will again participate with a dedicated devroom. > Complementing the upcoming Euro LLVM 2017, the devroom at FOSDEM > provides a great opportunity for LLVM developers and the wider open > source community to get together, connect and discuss. > > As possibly the largest European Open Source Conference, FOSDEM takes > place in Brussels and attracts with more than 400 lectures every year > over 5000 hackers - many core contributors of the worlds leading open > source projects. > > > = Call for Speakers, Posters, Demos = > > We invite academic, industrial and hobbyist speakers to present their > work on developing or using LLVM, Clang, LLDB, Polly, Compiler-RT, > etc. > > We are looking for: > > 1. Keynote speakers. > 2. Technical presentations (30 minutes plus questions and > discussion) related to development of LLVM, Clang etc. > 3. Presentations about the use of LLVM, Clang in commercial, > academic, hobbyist and other projects. > 4. Tutorials. > 5. Lightning talks (5 minutes). > > The deadline for receiving submissions is December 1st, 2016. > Speakers will be notified of acceptance or rejection by the 15th of > December. Proposals that are not sufficiently detailed (talks lacking > a comprehensive abstract for example) are likely to be rejected. > > Please create an account on the FOSDEM interface ( > https://penta.fosdem.org/user/new_account ) and submit your proposal ( > https://penta.fosdem.org/submission/FOSDEM17 ). Please make sure you > select "LLVM devroom" as the "Track". > > > = Registration = > > FOSDEM does not require any registration and is free of charge. > However, just like last year, a large crowd must be expected. We have > had to refuse entry to the room every year due to health and safety > reasons (a hard requirement from the organisers), with the room > already packed with people standing. > > > = Organization = > > The mailing list llvm-devroom at lists.fosdem.org can be used to > discuss issues of general interest related to the conference > organization. Please, do not reply to this email, as it is cross > posted to many lists. > > > = Financial Support = > > There may be a possibility of limited funding to help students or > contributors who could not otherwise attend the conference. This will > depend on overall sponsorship and companies' interest in supporting > the event. > > If you need funding to attend the meeting, or can help sponsor, please > tell us on llvm-devroom at lists.fosdem.org. > > > = About LLVM = > > LLVM 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. > > Besides LLVM, several projects have been developed on top of it like > Clang, LLDB, LLD or Polly. > > For more information, please visit http://llvm.org/ or the conference > webpage at > > http://llvm.org/devmtg/2017-02/ > > Best regards, > > LLVM @ FOSDEM organisers ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 31214] New: Don't stop on line 0
https://llvm.org/bugs/show_bug.cgi?id=31214 Bug ID: 31214 Summary: Don't stop on line 0 Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: paul_robin...@playstation.sony.com CC: llvm-b...@lists.llvm.org Classification: Unclassified Yesterday I tried committing LLVM r288212, which introduced a number of line-table records with line number 0. The DWARF spec says this means there is no particular source location associated with those instructions. I was expecting LLDB to ignore line-0 records, but apparently it does not. http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/1537 reported 3 test failures: FAIL: TestExitDuringStep.ExitDuringStepTestCase.test_dwarf FAIL: TestExitDuringStep.ExitDuringStepTestCase.test_dwo FAIL: TestExitDuringStep.ExitDuringStepTestCase.test_gmodules And looking at the traces, it seems that there was a single-step expecting to stop on line 30 but found itself stopped on line 0. I thought I had tried this with LLDB before, but apparently I didn't follow the website instructions correctly. (I'm still seeing more failures and other funny stuff than I expected, but if I apply or remove my patch it's still the same 3 tests that get different results, so I'm not going to worry about it.) LLDB should not stop on an instruction associated with line 0. It should proceed to the next instruction with a non-zero line number. -- 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] Refactoring in LLDB Windows Plugin
> On Nov 29, 2016, at 10:16 PM, Zachary Turner wrote: > > What would it take to make it so that local and remote process plugins use > the same exact interface? I mean in theory they're doing the same thing, > just on a different machine. If they shared an identical interface then you > could hook the lldb-server up to it and it would work either locally or > remotely. > > What was the original motivation for having the api design of remote and > local process plugins diverge? The plan was always do remote so we are always using one thing. We started off thinking we wanted to have a native plug-in and a remote GDB server, but when we found we didn't have serious performance issues we went the lldb-server/debugserver route for everything on our end. lldb-server uses NativeProcess and NativeThread as base classes that must be subclassed and we would make a ProcessNative plug-in that used the native compiled version of these (like lldb-server does), but then we have two code paths to test: native and remote. So we either have to run twice the number of tests, one local and one remote, so we can make sure native and remote work correctly, or we just go one route. What would tend to happen is we would 99.9% of people would do local debugging only and all bugs submitted would mostly be bugs with the native implementation and remote would suffer and become neglected. GDB had two different code paths for these so remote really did suffer and we evolved to use remote only on all our systems. Another nice reason for this is you can save the GDB remote packet log traffic when you do encounter a bug and see exactly what happened when a bug happened. So due to history, we started thinking we would need both native and remote plug-ins, but we migrated over time to just one solution for simpler testing, ensuring remote debugging is rock solid since it is always used for local debugging, and for the convenience of being able to completely lop all traffic to/from the process with the GDB remote logs. Greg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 31214] Don't stop on line 0
https://llvm.org/bugs/show_bug.cgi?id=31214 Paul Robinson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paul Robinson --- r288282 made the test work with "line 0" when stepping by instruction. -- 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
[lldb-dev] Conditionally adding sources to the build
Hi, I’m trying to conditionally add source files to the lldb build based on a cmake configure time variable. I get the following type of errors for all sources not included in the build: CMake Error at cmake/modules/LLVMProcessSources.cmake:83 (message): Found unknown source file /homes/dmitrym/buildspace/llvm-tot/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp Please update /homes/dmitrym/buildspace/llvm-tot/llvm/tools/lldb/source/Plugins/Process/FreeBSD/CMakeLists.txt Is there a way to work around/fix it or do I need to separate the files at the directory level? Thanks. Dmitry. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Conditionally adding sources to the build
Unfortunately you will need to separate them at the directory levels. On Wed, Nov 30, 2016 at 4:29 PM Dmitry Mikulin via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi, > > I’m trying to conditionally add source files to the lldb build based on a > cmake configure time variable. I get the following type of errors for all > sources not included in the build: > > CMake Error at cmake/modules/LLVMProcessSources.cmake:83 (message): > Found unknown source file > > /homes/dmitrym/buildspace/llvm-tot/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp > > Please update > > /homes/dmitrym/buildspace/llvm-tot/llvm/tools/lldb/source/Plugins/Process/FreeBSD/CMakeLists.txt > > Is there a way to work around/fix it or do I need to separate the files at > the directory level? > > Thanks. > Dmitry. > > ___ > 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] Refactoring in LLDB Windows Plugin
For what it's worth, we've been using lldb with ds2 to do remote debugging on Windows (x86) and Windows Phone (arm) and the lldb side of things works well with remote Windows targets. Besides porting lldb-server to Windows there shouldn't be any extra effort on the lldb side to do what Greg is talking about. On Wed, Nov 30, 2016 at 9:35 AM, Greg Clayton via lldb-dev wrote: > >> On Nov 29, 2016, at 10:16 PM, Zachary Turner wrote: >> >> What would it take to make it so that local and remote process plugins use >> the same exact interface? I mean in theory they're doing the same thing, >> just on a different machine. If they shared an identical interface then you >> could hook the lldb-server up to it and it would work either locally or >> remotely. >> >> What was the original motivation for having the api design of remote and >> local process plugins diverge? > > The plan was always do remote so we are always using one thing. We started > off thinking we wanted to have a native plug-in and a remote GDB server, but > when we found we didn't have serious performance issues we went the > lldb-server/debugserver route for everything on our end. lldb-server uses > NativeProcess and NativeThread as base classes that must be subclassed and we > would make a ProcessNative plug-in that used the native compiled version of > these (like lldb-server does), but then we have two code paths to test: > native and remote. So we either have to run twice the number of tests, one > local and one remote, so we can make sure native and remote work correctly, > or we just go one route. What would tend to happen is we would 99.9% of > people would do local debugging only and all bugs submitted would mostly be > bugs with the native implementation and remote would suffer and become > neglected. GDB had two different code paths for these so remote really did > suffer and we evolved to use remote only on all our systems. Another nice > reason for this is you can save the GDB remote packet log traffic when you do > encounter a bug and see exactly what happened when a bug happened. > > So due to history, we started thinking we would need both native and remote > plug-ins, but we migrated over time to just one solution for simpler testing, > ensuring remote debugging is rock solid since it is always used for local > debugging, and for the convenience of being able to completely lop all > traffic to/from the process with the GDB remote logs. > > Greg > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev -- Stephane Sezer ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
