Re: [lldb-dev] LLDB/NetBSD test suite results as of 8 Dec 2015
On 7 December 2015 at 19:28, Kamil Rytarowski via lldb-dev wrote: > > I ran the LLDB test suite of the LLDB-current version on NetBSD/amd64 > (v. 7.99.21). > > The results are as follows: > > 415 out of 415 test suites processed - TestRecursiveTypes.py > > Ran 415 test suites (266 failed) (64.096386%) > Ran 222 test cases (145 failed) (65.315315%) > Failing Tests (266) > > The major missing piece is native process tracking support (with the > ptrace(2) interface). Once added, LLDB should start to be usable on > this platform. Great progress, and thanks for the update! Are you planning to base the NetBSD native support on NativeProcessLinux? I need to migrate the FreeBSD support to work that way still. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Running a single test
I've been away from LLDB development for a little while but am
starting to work on it again.
I used to run a few tests using dotest.py's -f or -p flags, but they
don't seem to be working now.
-f filterspec Specify a filter, which consists of the test class
name, a dot, followed by the test method, to only
admit such test into the test suite
-p patternSpecify a regexp filename pattern for inclusion in the
test suite
For example, I'd expect this command:
% python dotest.py --executable
/tank/emaste/src/llvm/build-nodebug/bin/lldb -C /usr/bin/clang -v -t
-p TestCppIncompleteTypes
to run just the TestCppIncompleteTypes.py test(s), but instead it
looks like it runs the full suite.
I'd also expect
% python dotest.py --executable
/tank/emaste/src/llvm/build-nodebug/bin/lldb -C /usr/bin/clang -v -t
-f TestCppIncompleteTypes.test_limit_debug_info
to run a single test from the same suite, but it runs no tests
("Collected 0 tests").
I'm sure these options used to work, although this could be an issue
that affects only FreeBSD. Do they work on Linux/OS X?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Running a single test
On 9 February 2016 at 17:19, Zachary Turner wrote: > Try passing the directory to start in as the last argument. Also make sure > you include .py on the filename when using -p (I don't actually know if this > is required but I do it). > > % python dotest.py --executable /tank/emaste/src/llvm/build-nodebug/bin/lldb > -C /usr/bin/clang -v -t -p TestCppIncompleteTypes.py > ~/src/llvm/tools/lldb/packages/Python/lldbsuite/test > > I don't know off the top of my head why that last argument is required, and > I agree it's counterintuitive and probably doesn't *need* to be that way for > technical reasons. Ah yes, that works for -p, and explains why it worked for me before: the tests themselves used to be in lldb/tests/... (that is, subdirectories of dotest.py's location), so they were found without specifying an explicit path. Thanks. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Details on rdar://18684408?
The tests in lang/cpp/unicode-literals/TestUnicodeLiterals.py are
marked with @unittest2.expectedFailure("rdar://18684408").
These tests are passing on FreeBSD:
UNEXPECTED SUCCESS: test_and_run_command_dwarf
(lang/c/const_variables/TestConstVariables.py)
UNEXPECTED SUCCESS: test_expr1_dwarf
(lang/cpp/unicode-literals/TestUnicodeLiterals.py)
UNEXPECTED SUCCESS: test_expr2_dwarf
(lang/cpp/unicode-literals/TestUnicodeLiterals.py)
UNEXPECTED SUCCESS: test_expr3_dwarf
(lang/cpp/unicode-literals/TestUnicodeLiterals.py)
The example in the test case works as expected:
(lldb) expr L"Hello"
(const wchar_t [6]) $0 = L"Hello"
Are these passing on Linux as well?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Enabling tests on the Windows LLVM buildbot
On 18 May 2016 at 05:08, Pavel Labath via lldb-dev wrote: > > Sounds reasonable. I'd like to add a clarifying point (2.5): If you > have added a new test, and this test fails on some other platform AND > there is no reason to believe that this is due to a problem in the > test (like the python3 bytes thingy, etc.), then you can just xfail > the test for the relevant architecture is fine. That sounds reasonable to me. I hope to re-enable tests on the FreeBSD buildbot shortly as well. I have a "temporary" build-only buildbot I put into service when the previous ones needed to be decommissioned. Since FreeBSD's currently the only platform still using the old-style POSIX in-process debug support it's quite likely we could run into a failure when a test is added. I'd prefer to have the test marked XFAIL on FreeBSD with a bug report (or at least a post to the mailing list) than for it to be backed out pending investigation. A bit of a tangent but for reference, on FreeBSD 10 I currently see the following set of undesired test results: ERROR: test_with_run_command_dwarf (functionalities/data-formatter/data-formatter-stl/libstdcpp/string/TestDataFormatterStdString.py) ERROR: test_with_run_command_dwarf (functionalities/data-formatter/data-formatter-stl/libstdcpp/list/TestDataFormatterStdList.py) ERROR: test_with_run_command_dwarf (functionalities/data-formatter/data-formatter-stl/libstdcpp/iterator/TestDataFormatterStdIterator.py) ERROR: [EXCEPTIONAL EXIT 10 (SIGBUS)] test_python_os_plugin_dwarf (functionalities/plugins/python_os_plugin/TestPythonOSPlugin.py) UNEXPECTED SUCCESS: test_and_run_command_dwarf (lang/c/register_variables/TestRegisterVariables.py) UNEXPECTED SUCCESS: test_and_run_command_dwarf (lang/c/const_variables/TestConstVariables.py) TIMEOUT: test_asm_int_3 (functionalities/breakpoint/debugbreak/TestDebugBreak.py) TIMEOUT: test_with_dsym_and_python_api_dwarf (lang/go/expressions/TestExpressions.py) ___ 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
On 22 August 2016 at 16:03, Ted Woodward via lldb-dev wrote: > > 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. Indeed, and that's true for binaries and libraries too. For one specific example, FreeBSD/arm64 binaries have ELFOSABI_NONE (as specified by the AArch64 ABI). LLDB's OS detection from binaries and core files is (or was?) rather awkward and I hope we can clean it up, but treating ELFOSABI_NONE as Linux is a nonstarter. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB Evolution: Next Phase
On 19 August 2016 at 17:10, Kate Stone via lldb-dev wrote: > > Sept 5th Trunk closes for commits while reformatting takes place and is > validated before re-opening trunk. This is fine with me. As for validation, from my perspective I want to make sure the FreeBSD build-only buildbot is green: http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11 and I will build and run the test suite locally. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB Evolution: Next Phase
On 23 August 2016 at 11:55, Zachary Turner wrote: > > Should we consider adding git hyper-blame to llvm and recommending its usage? Nifty, I hadn't encountered git hyper-blame before. Thanks Zach. If I understand correctly all we need to do is add a `.git-blame-ignore-revs` file to the lldb root directory which lists git revision IDs to ignore, correct? And that's something we'd do after the reformatting commit goes in (and it would not affect any tool other than git hyper-blame). If so it sounds good to me. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB Evolution: Next Phase
On 3 September 2016 at 00:30, Kate Stone via lldb-dev
wrote:
> As a reminder, any pending commits you might have planned for LLDB this
> weekend must not break any of the bots we’re using to validate the health of
> the source tree.
Given the current non-functional state of the bots, what is the plan
for proceeding with the formatting change? For FreeBSD the bot was
building lldb but not running the tests and I was planning to manually
validate the tests.
For reference at r280675 on my FreeBSD desktop there are a few tests
that report errors (the libstdcpp ones, as FreeBSD 10 and later use
libc++), two that abort with an assertion ("Breakpoint update
failed!"), and three that sometimes time out (test_asm_int_3,
test_iter_registers_dwarf, test_with_dsym_and_python_api_dwarf).
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB Evolution: Next Phase
On 6 September 2016 at 08:51, Pavel Labath wrote: > Hi Ed, > > which bots are you referring to? Our bots were red overnight, but > we've been cleaning them up now, and they should get green shortly. As > far as we're concerned, the reformat can go on as planned. The "Buildbot General Failure - Production Stop?" thread on llvm-dev is what concerned me -- http://lists.llvm.org/pipermail/llvm-dev/2016-September/104564.html Quoting from there, > Essentially, the bots were all lying when they said this or that > commit "passed", since they were still testing the same old commit. > All our bots were affected, and it seems many other Windows, PowerPC, > s390, Atom, etc. I'm not certain which bots are affected but the thread makes it sound like there's a significant problem in the zorg infrastructure affecting many bots. Perhaps all lldb bots of interest are not affected though? From my perspective on FreeBSD I'm fine with the reformat proceeding, as my plan was always to manually validate the test run. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS
On 6 September 2016 at 17:17, Kate Stone via lldb-dev wrote: > The storm of commit messages might be a subtle clue, but here it is > officially: the reformatting is complete and I’ve verified that no tests > regressed locally in our macOS suite. Please begin any validation process > you’ve signed up for on another platform, and if changes are necessary go > ahead and land them individually. FreeBSD currently fails to build due to header reordering in source/Host/freebsd/Host.cpp which I'll sort out shortly. I'd like to request that we avoid any functional changes other than those restoring builds to green, until we get the "all clear" from everyone who's signed up to validate other platforms. -Ed ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] All clear on FreeBSD after reformatting
On 6 September 2016 at 17:26, Ed Maste wrote: > > FreeBSD currently fails to build due to header reordering in > source/Host/freebsd/Host.cpp which I'll sort out shortly. > > I'd like to request that we avoid any functional changes other than > those restoring builds to green, until we get the "all clear" from > everyone who's signed up to validate other platforms. The FreeBSD build is fixed in r280755, and test results are consistent with those from before the reformatting. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB Evolution - Final Form
On 19 September 2016 at 16:18, Zachary Turner via lldb-dev wrote: > > De-inventing the wheel - We should use more code from LLVM, and delete code > in LLDB where LLVM provides a solution. Another example of duplicated code is the debug info parsing (LLDB source/Plugins/SymbolFile/DWARF vs LLVM lib/DebugInfo/DWARF). I took a look at trying to rationalize the two when I first started working with LLDB and it looked like a large task then, and they've only continued to diverge. However, diffs between the two trees are now at least not cluttered with whitespace and formatting differences. I'll try to take another look at these. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB Evolution - Final Form
On 20 September 2016 at 17:25, Greg Clayton wrote: > > Well the DWARF code was copied from LLDB into LLVM. The original person > didn't update LLDB to use it, so things diverged. Yeah, sorry I didn't mention that explicitly. I do recall someone pointed that out when this came up previously. > I am actually in the process of fixing all of this as we speak, so don't do > any work on the DWARF parser. It will all be fixed in the next month or so! Most excellent, thank you. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLGS for Free/NetBSD (was: Re: [PATCH] D25756: FreeBSD ARM support for software single step.)
On 24 October 2016 at 06:26, Pavel Labath wrote: > > It's not my place to tell you how to work, but I'd recommend a > different approach to this. If you base your work on the current > FreeBSD in-process plugin, then when you get around to actually > implementing remote support, you will find that you will have to > rewrite most of what you have already done to work with lldb-server, > as it uses completely different class hierarchies and everything. I'd > recommend starting with lldb-server right away. It's going to be a bit > more work as (I assume) freebsd implementation is closer to what you > need than linux, but I think it will save you time in the long run. I > can help you with factoring out any linux-specific code that you > encounter. I definitely second the approach Pavel suggests here, and am happy to work with others on refactoring the Linux lldb-server so that we can get it to support both FreeBSD and NetBSD at the same time. A direct port of the current FreeBSD support probably would result in a basic level of support running sooner, but that work would be largely thrown away in a future migration to lldb-server. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Sample output from Darwin / Linux timeout pre-kill hook?
I'm looking at adding a FreeBSD timeout pre-kill hook, and I'm interested in mirroring the data currently collected on Linux and OS X. Is there a sample output from a timed-out LLDB test available somewhere? -Ed ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Improve performance of crc32 calculation
On 13 April 2017 at 07:28, Pavel Labath via lldb-dev wrote: > Improving the checksumming speed is definitely a worthwhile contribution, > but be aware that there is a pretty simple way to avoid computing the crc > altogether, and that is to make sure your binaries have a build ID. This is > generally as simple as adding -Wl,--build-id to your compiler flags. FreeBSD's default toolchain still uses an ancient GNU ld that lacks build-id support (on all platforms other than aarch64), so I'll be very happy to see improvements in checksum speed. We're migrating to LLD and will be able to use --build-id eventually, but it will be a while yet. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Patch to Attach pid successfully from different dir
On 19 April 2017 at 10:15, vignesh balu via lldb-dev wrote: > > While using lldb we found the small bug with attaching to the running > process. > "attach" works fine when we run the lldb on the same dir where we ran the > executable but not if the dir changes. Thank you for the bug report and patch in D32271. I recently reworked Host/freebsd/Host.cpp based on Kamil's NetBSD Host.cpp, and adapted your patch to match. Please try out the version now in D32271. One tip for future patch submissions: please include full context in the diffs as it makes review easier. For example if working in git, "git diff -U" or "git show -U". ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] FreeBSD test status snapshot
I've been away from lldb for a little bit, but hope to now find some time to continue working on FreeBSD support (possibly with a Google Summer of Code student). In any case I hadn't run the test suite for a little while, and when I try it on FreeBSD 12 now I see a number of somewhat recent failures. Fortunately it seems that there are a limited number of root causes. The list of failures is below - I'll submit bug reports for them after some initial investigation. The FreeBSD buildbot that I'm running doesn't execute tests - there was an issue with the test script when I set it up and I never addressed it. I'll take a look at enabling that soon. FAIL: test_breakpoint_doesnt_match_file_with_different_case_dwarf (functionalities/breakpoint/breakpoint_case_sensitivity/TestBreakpointCaseSensitivity.py) FAIL: test_conflicting_symbols (lang/c/conflicting-symbol/TestConflictingSymbol.py) FAIL: test_enum_args_dwarf (lang/cpp/template/TestTemplateArgs.py) FAIL: test_int16_t_dwarf (lang/cpp/enum_types/TestCPP11EnumTypes.py) FAIL: test_int32_t_dwarf (lang/cpp/enum_types/TestCPP11EnumTypes.py) FAIL: test_int64_t_dwarf (lang/cpp/enum_types/TestCPP11EnumTypes.py) FAIL: test_int8_t_dwarf (lang/cpp/enum_types/TestCPP11EnumTypes.py) FAIL: test_read_memory_c_string (python_api/process/read-mem-cstring/TestReadMemCString.py) FAIL: test_uint16_t_dwarf (lang/cpp/enum_types/TestCPP11EnumTypes.py) FAIL: test_uint32_t_dwarf (lang/cpp/enum_types/TestCPP11EnumTypes.py) FAIL: test_uint64_t_dwarf (lang/cpp/enum_types/TestCPP11EnumTypes.py) FAIL: test_uint8_t_dwarf (lang/cpp/enum_types/TestCPP11EnumTypes.py) ERROR: test_dwarf (functionalities/command_script_alias/TestCommandScriptAlias.py) ERROR: test_with_run_command_dwarf (functionalities/data-formatter/data-formatter-stl/libstdcpp/string/TestDataFormatterStdString.py) ERROR: test_with_run_command_dwarf (functionalities/data-formatter/data-formatter-stl/libstdcpp/iterator/TestDataFormatterStdIterator.py) ERROR: test_with_run_command_dwarf (functionalities/data-formatter/data-formatter-stl/libstdcpp/list/TestDataFormatterStdList.py) UNEXPECTED SUCCESS: test_multiple_targets (api/multiple-targets/TestMultipleTargets.py) UNEXPECTED SUCCESS: test_step_out_of_malloc_into_function_b_dwarf (python_api/thread/TestThreadAPI.py) UNEXPECTED SUCCESS: test_with_dwarf (lang/cpp/printf/TestPrintf.py) UNEXPECTED SUCCESS: test_with_run_command_dwarf (functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py) TIMEOUT: (functionalities/breakpoint/breakpoint_case_sensitivity/TestBreakpointCaseSensitivity.py) TIMEOUT: test_asm_int_3 (functionalities/breakpoint/debugbreak/TestDebugBreak.py) TIMEOUT: test_sigtrap (functionalities/signal/raise/TestRaise.py) TIMEOUT: test_unique_stacks_dwarf (functionalities/thread/num_threads/TestNumThreads.py) === Test Result Summary === Test Methods: 1324 Reruns:0 Success: 583 Expected Failure: 49 Failure: 13 Error: 4 Exceptional Exit: 0 Unexpected Success:4 Skip:667 Timeout: 4 Expected Timeout: 0 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] FreeBSD LLDB buildbot
Years ago there was a FreeBSD LLDB buildbot managed by Galina; it was decommissioned quite some time ago. I've been running one since then, but it was never set up to run tests, only build. Over the weekend I tried to get it to run tests, but ended up with a broken installation. I've started over in a clean FreeBSD jail and have it configured again, but it appears that FreeBSD now has a newer version of the buildbot worker package (0.9.11) in the package collection that is not compatible with the server; the Python 3 version reported: remoteFailed: [Failure instance: Traceback from remote host -- Traceback unavailable buildbot_worker.base.UnknownCommand: unrecognized WorkerCommand 'b'shell'' ] I installed the Python 2 buildbot-worker 0.9.11 and it reports: exceptions.AssertionError: Unexpected usePTY argument value: 'slave-config'. Expected boolean. exceptions.AssertionError: Unexpected usePTY argument value: 'slave-config'. Expected boolean. It seems there's a number of interop problems between different Buildbot versions and Python 2 / Python 3. What is the best way to install a compatible buildbot worker? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] FreeBSD LLDB buildbot
On 26 February 2018 at 18:46, Galina Kistanova wrote: > Hi Ed, > > Please try to install pip to get buildslave v0.8.12. > Something like this should work: > pip install 'buildbot-slave <= 0.8.12' Thanks Galina. I now have a jail running FreeBSD 11.1-Release hosting the original lldb-amd64-ninja-freebsd11 configuration, so we're at least back to a green build-only FreeBSD buildbot. http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11 For reference (most likely for my future self, when I have to set up another instance), this is how I set it up: 1. Create a FreeBSD 11.1-Release jail as described in https://www.freebsd.org/doc/handbook/jails-build.html. (As an aside, I found some outdated information in the FreeBSD handbook jails section; changes are in progress but noted in case anyone else wants to try.) 2. Install required packages: # pkg install cmake ninja swig30 subversion py27-pip 3. installed buildbot-slave via pip, as described above. This jail is used exclusively for this buildbot instance so there is no concern installing to the system-wide location. 4. Recreate buildbot.tac $ buildslave create-slave /usr/home/buildbot/scratch/ lab.llvm.org:9990 lldb-amd64-ninja-freebsd11 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 reason they're not? 6. Add updateScripts.sh to path (I symlinked it into ~/bin). 7. Start the buildbot worker process $ buildslave start The host is running a FreeBSD 12-CURRENT kernel and to enable tests I expect I'll create a new FreeBSD 12 builder, which can be initially connected to the staging master. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] FreeBSD LLDB buildbot
On 26 February 2018 at 22:32, Ed Maste wrote: > > 2. Install required packages: > # pkg install cmake ninja swig30 subversion py27-pip Also gmake and bash. > The host is running a FreeBSD 12-CURRENT kernel and to enable tests I > expect I'll create a new FreeBSD 12 builder, which can be initially > connected to the staging master. I've sent connection details for lldb-amd64-ninja-freebsd-wip-12, and will post a patch for slaves.py and builders.py soon. There is one problem reported by the lit tests with my jail approach: [ RUN ] SocketTest.TCPGetAddress /usr/home/buildbot/scratch/scratch/llvm/tools/lldb/unittests/Host/SocketTest.cpp:207: Failure Expected: "127.0.0.1" To be equal to: socket_a_up->GetRemoteIPAddress().c_str() Which is: "192.168.11.4" In a (default configuration) jail FreeBSD maps 127.0.0.1 to the jail's IP address. Support for independent virtualized network stacks is a more recent addition to FreeBSD and it looks like I'll need to set that up here (or use full virtual machines). ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Default script language
In lldb/include/lldb/lldb-enumerations.h we have: eScriptLanguageDefault = eScriptLanguagePython I'd like to do something like: #if LLDB_ENABLE_PYTHON eScriptLanguageDefault = eScriptLanguagePython #elif LLDB_ENABLE_LUA eScriptLanguageDefault = eScriptLanguageLua #else eScriptLanguageDefault = eScriptLanguageNone #endif if we could include Config.h, or achieve the same effect in some other way if we cannot. Does this seem reasonable? I'm interested in this for lldb in the FreeBSD base system. We have lua available already (and no python) and I've integrated our liblua it into lldb, but it required "--script-language lua" on the command line. For now I'll just change the default to be eScriptLanguageLua in our tree, but would like to have this "just work" upstream. ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Default script language
On Wed, 1 Apr 2020 at 19:13, Ted Woodward wrote: > > I agree with Jim - it should be a cmake setting, defaulting to Python. If the > person building lldb wants to change the default scripting language from > Python to Lua, it should be easy. Ok, agreed. My initial concern was that python remained the default even if not compiled in, but I can carry a tiny patch in the FreeBSD base system to address that for now. I agree with Jim that there's no point in doing the work twice. > Since we now support 2 scripting languages, we should have an easy way for > the user to see which are supported, and which is the default if there are > more than 1 supported. Maybe in lldb --version? We should indeed have a way to see which languages are available and which is default. We have a few other build-time options, should we include a summary of all of them in --version I wonder? On Thu, 2 Apr 2020 at 02:44, Pavel Labath wrote: > > That said, I don't think we can implement this using #ifdefs. > lldb-enumerations.h is a part of our public api, Config.h isn't (it > theoretically could be, but I don't think we want that). As it turns out changing lldb-enumerations.h wasn't sufficient anyway, the default is also specified in CoreProperties.td. I'll start looking into both of these changes (dealing with eScriptLanguageDefault, and adding cmake configuration). ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Removing linux mips support
On Tue, 9 Mar 2021 at 03:24, Pavel Labath via lldb-dev wrote: > > So, unless someone willing to address these issues (I'm happy to provide > support where I can), I propose we drop mips support. Generic mips > support will remain (and hopefully be better tested) thanks to the > FreeBSD mips port, so re-adding mips support should be a matter of > reimplementing the linux bits. A brief note on the FreeBSD mips support - the FreeBSD Foundation is sponsoring Michał to do this work, but our primary non-x86 focus is amd64. Other architectures that had old-style in-process FreeBSD support (including mips) are in scope on a best-effort basis. I hope that this does result in better testing of the generic mips support and such. However, FreeBSD/mips users are going to need to use and test this on an ongoing basis or we'll find ourselves in the same situation, and will have to look at retiring it as well. ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Removing linux mips support
On Mon, 15 Mar 2021 at 16:00, Ed Maste wrote: > > A brief note on the FreeBSD mips support - the FreeBSD Foundation is > sponsoring Michał to do this work, but our primary non-x86 focus is > amd64. Oops, that doesn't make a lot of sense. I meant arm64 (AArch64) here. Thanks to a couple of folks who pointed this out to me. ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)
On Tue, 14 Dec 2021 at 10:58, Pavel Labath via lldb-dev wrote: > > So how would this be represented in lldb? Would there be any threads, > registers? Just a process with a bunch of modules ? Using GDB (kgdb) as an example - it lists a thread for every kernel/userspace thread. For example, ... 593 Thread 100691 (PID=20798: sleep) sched_switch (td=0xfe0118579100, flags=) at /usr/home/emaste/src/freebsd-git/laptop/sys/kern/sched_ule.c:2147 ... and it can fetch per-thread register state: (kgdb) thread 593 [Switching to thread 593 (Thread 100691)] #0 sched_switch (td=0xfe0118579100, flags=) at /usr/home/emaste/src/freebsd-git/laptop/sys/kern/sched_ule.c:2147 2147cpuid = td->td_oncpu = PCPU_GET(cpuid); (kgdb) info reg rax rbx0x882c545e 2284606558 rcx rdx rsi rdi rbp0xfe01172617d0 0xfe01172617d0 rsp0xfe0117261708 0xfe0117261708 (kgdb) bt #0 sched_switch (td=0xfe0118579100, flags=) at /usr/home/emaste/src/freebsd-git/laptop/sys/kern/sched_ule.c:2147 #1 0x80ba4261 in mi_switch (flags=flags@entry=260) at /usr/home/emaste/src/freebsd-git/laptop/sys/kern/kern_synch.c:542 #2 0x80bf428e in sleepq_switch (wchan=wchan@entry=0x81c8db21 , pri=pri@entry=108) at /usr/home/emaste/src/freebsd-git/laptop/sys/kern/subr_sleepqueue.c:608 ... ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Question (bug?) about thread tids when lldb loads a core dump.
On 11 August 2015 at 17:17, Mike McLaughlin wrote: > Any word on the fix for Linux? I really don't know enough to fix it myself. > Would this fix (and any Linux, etc. fix) go into 3.7? I think it's going to be too late for 3.7 since we don't have the fix in place yet. I'm not aware of the Linux ELF core info myself and don't have a Linux machine handy to test at the moment. Some time ago I planned to collect sample core files, and if someone can clone https://github.com/emaste/userland-cores, run it, and add the resulting core from Linux I'll see if it's straightforward to update the ELF core plugin to handle it. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Looking for info on two rdars: 18684124, 15367233
Two tests are currently decorated with a @unittest2.expectedFailure
referencing rdar tickets. These tests pass consistently for me on
FreeBSD. Can I ask the Apple folks to look at these tickets and put
details in a public PR if appropriate? Alternatively, shall I switch
the tests to expectedFailureDarwin?
Also, are these tests passing on Linux?
-Ed
test/driver/batch_mode/TestBatchMode.py
@unittest2.expectedFailure(", lldb doesn't
reliably print the prompt when run under pexpect")
test/functionalities/inferior-assert/TestInferiorAssert.py
@unittest2.expectedFailure("rdar://15367233")
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
