Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 3 has been tagged
On 25 August 2016 at 04:42, Hans Wennborg via Release-testers wrote: > Dear testers, > > 3.9.0-rc3 was just tagged from the branch at r279704. ARM and AArch64 seem fine, binaries uploaded: ARM sha1sum: d1bc90d475f8d764f1ff7524ba2f3e26acb8a463 AArch64 sha1sum: 5e4e3bdf747aa2ac50c588cea5d67f89637691c6 cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 29138] New: lldb uses internal lib/Support/regex_impl.h LLVM header
https://llvm.org/bugs/show_bug.cgi?id=29138 Bug ID: 29138 Summary: lldb uses internal lib/Support/regex_impl.h LLVM header Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: mgo...@gentoo.org CC: llvm-b...@lists.llvm.org Classification: Unclassified When attempting to build lldb stand-alone, I hit the following error: [ 91%] Building CXX object tools/lldb-mi/CMakeFiles/lldb-mi.dir/MICmdCmdData.cpp.o cd /home/mgorny/llvm-standalone/lldb/_build/tools/lldb-mi && /usr/bin/c++ -DGTEST_HAS_RTTI=0 -DHAVE_PROCESS_VM_READV -DHAVE_ROUND -DLIBXML2_DEFINED -DLLDB_DISABLE_CURSES -DLLDB_DISABLE_LIBEDIT -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/home/mgorny/llvm-standalone/lldb/_build/tools/lldb-mi -I/home/mgorny/llvm-standalone/lldb/tools/lldb-mi -I/home/mgorny/llvm-standalone/lldb/include -I/home/mgorny/llvm-standalone/lldb/_build/include -I/home/mgorny/llvm-standalone/install/include -I/usr/include/python3.4m -I/home/mgorny/llvm-standalone/lldb/tools/clang/include -I/home/mgorny/llvm-standalone/lldb/_build/../clang/include -I/usr/include/libxml2 -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -ffunction-sections -fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension-fno-exceptions -fno-rtti -o CMakeFiles/lldb-mi.dir/MICmdCmdData.cpp.o -c /home/mgorny/llvm-standalone/lldb/tools/lldb-mi/MICmdCmdData.cpp In file included from /home/mgorny/llvm-standalone/lldb/tools/lldb-mi/MICmdCmdData.cpp:45:0: /home/mgorny/llvm-standalone/lldb/tools/lldb-mi/MIUtilParse.h:13:39: fatal error: ../lib/Support/regex_impl.h: Nie ma takiego pliku ani katalogu compilation terminated. Please avoid using internal LLVM API since this makes it impossible to build lldb without a copy of LLVM sources around. -- 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] Linux ELF header e_ident[EI_OSABI] value
FWIW, I've taken a few whacks at getting Linux detected better over the last few years, and haven't yet found a reliable way to detect it from quite a few samples of cores from a number of different systems. We can spend more time looking into it, but that stone has been turned over several times. On Tue, Aug 23, 2016 at 6:49 AM, Howard Hellyer via lldb-dev < lldb-dev@lists.llvm.org> wrote: > "Ted Woodward" wrote on 22/08/2016 21:03:02: > > > We don't want to make ELFOSABI_NONE mean Linux. ELFOSABI_NONE is > > historically ELFOSABI_SYSV, and used by a lot of things. So not all > > core files identified as ELFOSABI_NONE are Linux. > > I agree that other OS's may use it or have used it in the past but I don't > know if any of those are supported by LLDB at the moment. (If they are then > they probably have the same problem.) > It's definitely annoying that Linux doesn't seem to use the value that > makes sense but as it stands the case statement in ArchSpec.cpp won't > actually hit its Linux case at the moment (which is quite confusing). I > guess I just didn't want to bypass the trivial fix if it didn't affect > anything else in practise. > > > ObjectFileELF::RefineModuleDetailsFromNote looks for a note with > > type NT_FILE, then looks in that for a path that starts with "/lib/ > > x86_64-linux-gnu". If it finds that, it will set the core file's OS > > to Linux. Teaching that to speak the Linux dialect you're interested > > in is probably the right way to go. > > The problem with that is the Redhat cores I have to hand (from various > test machines) have the FILE note section but the library files are in > /usr/lib (32 bit) or /usr/lib64 (64 bit). That looks sufficiently generic > that identifying the OS as Linux based on those would probably have the > same effect as using ELFOSABI_NONE. The paths LLDB currently knows about > (and match my Ubuntu box) are /lib/i386-linux-gnu and > /lib/x86_64-linux-gnu. Since they have "linux" in them they a much safer > bet. > > I also have some other cores taken from Ubuntu running in a containerised > environment where the library path in the core is actually the full path > from outside the container, so it only ends in /lib/x86_64-linux-gnu, the > full path is /packages/rootfs_cflinuxfs2/[very long UID > value]/rootfs/lib/x86_64-linux-gnu/[library].so. (This may be a container > problem though, I'm not sure if using core dumps to discover this path is > actually a bug.) > *Howard Hellyer* > IBM Runtime Technologies, IBM Systems > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB Evolution
On Mon, Aug 8, 2016 at 2:57 PM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> LLDB has come a long way since the project was first announced. As a >> robust debugger for C-family languages and Swift, LLDB is constantly in use >> by millions of developers. It has also become a foundation for bringing up >> debugger support for other languages like Go and RenderScript. In addition >> to the original macOS implementation the Linux LLDB port is in active use >> and Windows support has made significant strides. IDE and editor >> integration via both SB APIs and MI have made LLDB available to even more >> users. It’s definitely a project every contributor can be proud of and I’d >> like to take a moment to thank everyone who has been involved in one way or >> another. >> >> It’s also a project that shows some signs of strain due to its rapid >> growth. We’ve accumulated some technical debt that must be paid off, and >> in general it seems like a good time to reflect on where we'll be headed >> next. We’ve outlined a few goals for discussion below as well as one more >> short-term action. Discussion is very much encouraged. >> >> *Forward-Looking Goals* >> >>1. Testing Strategy Evaluation >> >> Keeping our code base healthy is next to impossible without a robust >> testing strategy. Our existing suite of tests is straightforward to run >> locally, and serves as a foundation for continuous integration. That said, >> it is definitely not exhaustive. Obvious priorities for improvement >> include gathering coverage information, investing in more conventional unit >> tests in addition to the suite of end-to-end tests, and introducing tests >> in code bases where we depend on debugger-specific behavior (e.g.: for >> expression evaluation.) >> >> I know this is going to be controversial, but I think we should at least > do a serious evaluation of whether using the lit infrastructure would work > for LLDB. Conventional wisdom is that it won't work because LLDB tests are > fundamentally different than LLVM tests. I actually completely agree with > the latter part. They are fundamentally different. > > However, we've seen some effort to move towards lldb inline tests, and in > a sense that's conceptually exactly what lit tests are. My concern is that > nobody with experience working on LLDB has a sufficient understanding of > what lit is capable of to really figure this out. > > I know when I mentioned this some months ago Jonathan Roelofs chimed in > and said that he believes lit is extensible enough to support LLDB's use > case. The argument -- if I remember it correctly -- is that the > traditional view of what a lit test (i.e. a sequence of commands that > checks the output of a program against expected output) is one particular > implementation of a lit-style test. But that you can make your own which > do whatever you want. > > I have some interest in looking into this. Kate and I had talked about it as a possible investigation back a few months ago. I'd be happy if we could reduce the overall complexity of building high quality tests. I'd be particularly interested in learning more about the alternative workflow that isn't just "run/check/run/check", as I don't think we can map everything to that model. I may take an action item on this in the near future. > This would not just be busy work either. I think everyone involved with > LLDB has experienced flakiness in the test suite. Sometimes it's flakiness > in LLDB itself, but sometimes it is flakiness in the test infrastructure. > It would be nice to completely eliminate one source of flakiness. > > I think it would be worth having some LLDB experts sit down in person with > some lit experts and brainstorm ways to make LLDB use lit. > > Certainly it's worth a serious look, even if nothing comes of it. > > > >>4. Good Citizenship in the LLVM Community >> >> Last, but definitely not least, LLDB should endeavor to be a good citizen >> of the LLVM community. We should encourage developers to think of the >> technology stack as a coherent effort, where common code should be >> introduced at an appropriate level in the stack. Opportunities to factor >> reusable aspects of the LLDB code base up the stack into LLVM will be >> pursued. >> >> One arbitrary source of inconsistency at present is LLDB’s coding >> standard. That brings us to… >> >> *Near-Term Goal: Standardizing on LLVM-style clang-format Rules* >> >> We’ve heard from several in the community that would prefer to have a >> single code formatting style to further unify the two code bases. Using >> clang-format with the default LLVM conventions would simplify code >> migration, editor configuration, and coding habits for developers who work >> in multiple LLVM projects. There are non-trivial implications to >> reformatting a code base with this much history. I
Re: [lldb-dev] LLDB Evolution
Definitely agree we can't map everything to that model. I can imagine a first step towards lit being where all our tests are literally exactly the same as they are today, with Makefiles and all, but where lit is used purely to recurse the directory tree, run things in multiple processes, and spawn workers. Lit should be flexible enough to support this. As a further step, imagine rewriting most tests as inline tests like lldbinline. Lit can support this too, the parsing and file commands are all up to the implementation. So the existing model of run tool and grep output is just one implementation of that, but you could design one that has build commands, c++ source, and Python all in one file, or even intermingled like in an lldbinline test On Thu, Aug 25, 2016 at 12:54 PM Todd Fiala wrote: > On Mon, Aug 8, 2016 at 2:57 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> >> >> On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >>> LLDB has come a long way since the project was first announced. As a >>> robust debugger for C-family languages and Swift, LLDB is constantly in use >>> by millions of developers. It has also become a foundation for bringing up >>> debugger support for other languages like Go and RenderScript. In addition >>> to the original macOS implementation the Linux LLDB port is in active use >>> and Windows support has made significant strides. IDE and editor >>> integration via both SB APIs and MI have made LLDB available to even more >>> users. It’s definitely a project every contributor can be proud of and I’d >>> like to take a moment to thank everyone who has been involved in one way or >>> another. >>> >>> It’s also a project that shows some signs of strain due to its rapid >>> growth. We’ve accumulated some technical debt that must be paid off, and >>> in general it seems like a good time to reflect on where we'll be headed >>> next. We’ve outlined a few goals for discussion below as well as one more >>> short-term action. Discussion is very much encouraged. >>> >>> *Forward-Looking Goals* >>> >>>1. Testing Strategy Evaluation >>> >>> Keeping our code base healthy is next to impossible without a robust >>> testing strategy. Our existing suite of tests is straightforward to run >>> locally, and serves as a foundation for continuous integration. That said, >>> it is definitely not exhaustive. Obvious priorities for improvement >>> include gathering coverage information, investing in more conventional unit >>> tests in addition to the suite of end-to-end tests, and introducing tests >>> in code bases where we depend on debugger-specific behavior (e.g.: for >>> expression evaluation.) >>> >>> I know this is going to be controversial, but I think we should at least >> do a serious evaluation of whether using the lit infrastructure would work >> for LLDB. Conventional wisdom is that it won't work because LLDB tests are >> fundamentally different than LLVM tests. I actually completely agree with >> the latter part. They are fundamentally different. >> >> However, we've seen some effort to move towards lldb inline tests, and in >> a sense that's conceptually exactly what lit tests are. My concern is that >> nobody with experience working on LLDB has a sufficient understanding of >> what lit is capable of to really figure this out. >> >> I know when I mentioned this some months ago Jonathan Roelofs chimed in >> and said that he believes lit is extensible enough to support LLDB's use >> case. The argument -- if I remember it correctly -- is that the >> traditional view of what a lit test (i.e. a sequence of commands that >> checks the output of a program against expected output) is one particular >> implementation of a lit-style test. But that you can make your own which >> do whatever you want. >> >> > I have some interest in looking into this. Kate and I had talked about it > as a possible investigation back a few months ago. I'd be happy if we > could reduce the overall complexity of building high quality tests. I'd be > particularly interested in learning more about the alternative workflow > that isn't just "run/check/run/check", as I don't think we can map > everything to that model. I may take an action item on this in the near > future. > > >> This would not just be busy work either. I think everyone involved with >> LLDB has experienced flakiness in the test suite. Sometimes it's flakiness >> in LLDB itself, but sometimes it is flakiness in the test infrastructure. >> It would be nice to completely eliminate one source of flakiness. >> >> I think it would be worth having some LLDB experts sit down in person >> with some lit experts and brainstorm ways to make LLDB use lit. >> >> Certainly it's worth a serious look, even if nothing comes of it. >> >> >> >>>4. Good Citizenship in the LLVM Community >>> >>> Last, but definitely not least, LLDB should endeavor to be a good >>> citizen of
Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 3 has been tagged
On 25 Aug 2016, at 05:42, Hans Wennborg via Release-testers wrote: > > 3.9.0-rc3 was just tagged from the branch at r279704. > > This one is very similar to rc2. These are the only new commits: > > r279224 - Minor change to OpenCL release notes > r279260 - [lld] Add a note that 3.9 is a major milestone for us > r279468, r279474 - Fix gather-root.ll SLP vectorizer test to not expose UB > r279476 - [lld] Add R_386_TLS_LE as a relocation having an implicit addend. > r279471 - [msan] Disable prlimit test on glibc < 2.13 > r279477 - [CloneFunction] Don't remove unrelated nodes from the CGSSC > r279647 - [SCCP] Don't delete side-effecting instructions > > Please take this for a spin. If there are no hiccups, the plan is to > promote this to 'final' on Friday and ship the release early next > week. Built and tested OK on FreeBSD 10 again. Uploaded: SHA256 (clang+llvm-3.9.0-rc3-i386-unknown-freebsd10.tar.xz) = 32a2c03ca51223baf93baf35261254d50f8a948db3cfd17963a540e7a6aa1b36 SHA256 (clang+llvm-3.9.0-rc3-amd64-unknown-freebsd10.tar.xz) = feae733036a3932dcb96a807e9ab626d0ece1642323d207815816725c0b5 -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
