[lldb-dev] [Bug 36013] New: LLDB: StandardStartupTest.TestStopReplyContainsThreadPcs fails on (32-bit) x86
https://bugs.llvm.org/show_bug.cgi?id=36013 Bug ID: 36013 Summary: LLDB: StandardStartupTest.TestStopReplyContainsThreadPcs fails on (32-bit) x86 Product: lldb Version: 6.0 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 Blocks: 35804 This one seems specific to 32-bit x86 (it fails in my 32-bit chroot, and passes in 64-bit). I need to check if it's regression though. FAIL: lldb-Unit :: tools/lldb-server/tests/./LLDBServerTests/StandardStartupTest.TestStopReplyContainsThreadPcs (313 of 315) TEST 'lldb-Unit :: tools/lldb-server/tests/./LLDBServerTests/StandardStartupTest.TestStopReplyContainsThreadPcs' FAILED Note: Google Test filter = StandardStartupTest.TestStopReplyContainsThreadPcs [==] Running 1 test from 1 test case. [--] Global test environment set-up. [--] 1 test from StandardStartupTest [ RUN ] StandardStartupTest.TestStopReplyContainsThreadPcs /var/tmp/portage/dev-util/lldb-6.0./work/lldb-6.0./unittests/tools/lldb-server/tests/ThreadIdsInJstopinfoTest.cpp:47: Failure Expected: stop_reply_pcs[tid] Which is: 4160396025 To be equal to: *pc_value Which is: 17868764865783398400 Mismatched PC for thread: 25287 [ FAILED ] StandardStartupTest.TestStopReplyContainsThreadPcs (207 ms) [--] 1 test from StandardStartupTest (207 ms total) Full build & test log attached. This is on release_60 branch with stand-alone build on Gentoo. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=35804 [Bug 35804] [meta] 6.0.0 Release Blockers -- 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] [llvm-dev] [Release-testers] [6.0.0 Release] Release Candidate 1 tagged
On Thu, Jan 18, 2018 at 7:27 PM, Dimitry Andric wrote: > On 18 Jan 2018, at 15:03, Jonas Hahnfeld wrote: >> >> Am 2018-01-18 14:55, schrieb Dimitry Andric via llvm-dev: >>> On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers >>> wrote: Start your engines; 6.0.0-rc1 was just tagged. I know there are still open blockers and it's early in the process in a way, but I'd like to find out where we are. Please run the test script, let me know the results, and upload binaries. >>> At the moment I can't compile openmp, since it errors out on libomptarget: >>> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:50:10: >>> error: use of undeclared identifier 'malloc' >>>rc = malloc(size); >>> ^ >>> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:76:5: >>> error: use of undeclared identifier 'free' >>>free(device_ptr); >>>^ >>> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:163:20: >>> error: use of undeclared identifier 'malloc' >>>void *buffer = malloc(length); >>> ^ >>> I'm trying a local fix here, namely including at the top of the >>> file. >> >> Argh, I have missed that header. Adding sounds like the right >> solution, can you submit a patch or directly commit to SVN if it works for >> you? > > I added to api.cpp, interface.cpp and rtl.cpp, in r322869. Hans, > could you please merge it to release_60, or shall I do it? Go ahead if you're set up, otherwise let me know and I'll do it. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)
Hi all, At work I have been experimenting with linking with lld, I can give all sorts of information about the performance so far if someone wants to hear it, but for a large binary (around 100mb and 800mb of symbols) it takes considerably more memory and time than the vs 2015 and 2017 linker. What I've been playing around is the idea of creating a tool that generate those DEBUG:GHASH sections on .obj files already created, I saw code for reading them in lld and started looking at the codeview part of clang, is there any documentation around that, and would anyone else have interest in such a tool? I wish we could just jump shit to clang but right now that is not a possibility (It mostly revolves around windows.h and the copy of it we mantain). ps: I have two patches that I needed to get it to finish linking I can submit them monday. -- Leonardo Santagada ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm
> On Jan 18, 2018, at 7:52 AM, Pavel Labath via lldb-dev > wrote: > > 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 what kind of interfaces are you using, particularly on the > reading side. I think the current DWARFAcceleratorTable interface will > need to be redesigned a bit if we want it to fit the dwarf5 tables as > well. Dsymutil never reads accelerator tables. It rebuilds them while walking the debug_info section. Fred > On 17 January 2018 at 20:52, Eric Christopher via lldb-dev > wrote: >> FWIW I'm completely on board with everything Adrian has said in this thread >> :) >> >> -eric >> >> On Wed, Jan 17, 2018 at 11:00 AM Adrian Prantl via llvm-dev >> wrote: >>> >>> >>> On Jan 17, 2018, at 9:20 AM, Jonas Devlieghere via llvm-dev wrote: As mentioned by Adrian in the comment you linked, I too am looking at DWARFv5 accelerator tables in LLVM. To give you some background: my motivation is that I want to upstream support for (Apple style) accelerator tables in llvm-dsymutil, >>> >>> Some background for the benefit of everyone who may not be aware of the >>> genesis of the DWARF v5 accelerator tables: >>> >>> DWARF v5 accelerator tables are a direct evolution of the "Apple" >>> accelerator tables that are implemented in LLVM (after going through the >>> standardization process and being reworked/generalized there), so we hope >>> that the implementation can at least share some common interfaces with the >>> existing Apple accelerator table implementation where this makes sense. >>> >>> -- adrian >>> ___ >>> LLVM Developers mailing list >>> llvm-...@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> ___ >> 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 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
