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,
...
5
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 w
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,
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 remain
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 = eSc
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 initiall
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-f
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
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 failure
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 pa
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
> genera
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.l
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
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
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 li
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 "al
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
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 - Pr
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
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
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:
h
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 li
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 by
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/
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/buil
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,
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.0963
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 expectedFailure
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 Linu
29 matches
Mail list logo
