fjricci abandoned this revision.
fjricci added a comment.
Didn’t realize I still had open revisions, haven’t worked on lldb in quite some
time
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D44041/new/
https://reviews.llvm.org/D44041
___
lld
fjricci abandoned this revision.
fjricci added a comment.
I'm not going to get to this
https://reviews.llvm.org/D41909
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
fjricci created this revision.
fjricci added reviewers: clayborg, zturner, wallace.
If a section name is exactly 8 characters (the maximum section name length),
and the next item in the section header struct contains a non-zero value,
we would append garbage data to the end of the section name str
fjricci created this revision.
fjricci added reviewers: clayborg, zturner, labath.
Herald added subscribers: JDevlieghere, arichardson, emaste.
In order to allow some sections to exist either in split debug-info or in the
main binary,
don't replace non-empty sections with empty sections.
https:
fjricci added a comment.
> SymbolVendor::FindFunctions will lazily parse functions from the debug info
> and populate things inside the module, so the lock is required.
Can it give up the lock while it's blocked on worker threads? Holding a lock
while blocked seems like a recipe for deadlocks (
fjricci added a comment.
> I think a better option would be to remove that lock and if it is needed then
> lock it just for the calls where it necessary. The fact that SymbolVendor
> locks a mutex inside a Module feels like a pretty bad layering violation for
> me what can cause many other dead
fjricci added a comment.
It's definitely possible to re-design the lock holding in such a way that we
can keep this locked, but I don't want to go through all the work to do that if
there isn't any added value to doing so.
https://reviews.llvm.org/D41909
fjricci added a comment.
Actually I don't think even that is racy, because we just get a pointer to the
const char *, which is immutable anyway.
https://reviews.llvm.org/D41909
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.
fjricci added a comment.
I guess the question is whether we expect that someone will do something like
change the module's filepath while we're printing a log message with that
filepath in it.
https://reviews.llvm.org/D41909
___
lldb-commits maili
fjricci created this revision.
fjricci added reviewers: clayborg, zturner, tberghammer.
Herald added subscribers: JDevlieghere, aprantl.
When dwarf parse logging is enabled (ie `log enable dwarf info`),
deadlocks can occur during dwarf parsing:
Thread 1:
`SymbolVendor::FindFunctions` (acquires mu
fjricci added inline comments.
Comment at: source/Host/common/TaskPool.cpp:55
+ static const unsigned g_hardware_concurrency =
+std::max(1u, std::thread::hardware_concurrency());
+ return g_hardware_concurrency;
Is 1 the best default here when hardware_con
fjricci added a comment.
Oh I see from the discussion on https://github.com/apple/swift-lldb/pull/252
that it was accidental - don't worry about it
Repository:
rL LLVM
https://reviews.llvm.org/D38328
___
lldb-commits mailing list
lldb-commits@li
fjricci added a comment.
@jasonmolenda - just an FYI that I'm an llvm committer (I contribute frequently
to compiler-rt, and used to contribute quite a bit to lldb as well). No worries
about this patch though, especially given how small it is.
Repository:
rL LLVM
https://reviews.llvm.org/D3
fjricci created this revision.
It is probably reasonable to expect that most (or all) users of
the patch file feature will be using git, and assuming
git patch files makes this feature easier to use.
https://reviews.llvm.org/D38328
Files:
scripts/Xcode/build-llvm.py
scripts/build-lldb-llvm-
This revision was automatically updated to reflect the committed changes.
Closed by commit rL313637: Use ThreadLauncher to launch TaskPool threads
(authored by fjricci).
Changed prior to commit:
https://reviews.llvm.org/D37930?vs=115691&id=115844#toc
Repository:
rL LLVM
https://reviews.llvm
fjricci updated this revision to Diff 115691.
fjricci added a comment.
Herald added subscribers: JDevlieghere, mgorny.
Move TaskPool from Utility to Host
https://reviews.llvm.org/D37930
Files:
include/lldb/Host/TaskPool.h
include/lldb/Utility/TaskPool.h
lldb.xcodeproj/project.pbxproj
so
fjricci reopened this revision.
fjricci added a comment.
This revision is now accepted and ready to land.
Is ThreadLauncher unavailable in this code for some reason? The link failed on
linux buildbots (building lldb on Darwin was fine locally):
http://lab.llvm.org:8011/builders/lldb-x86_64-ubunt
This revision was automatically updated to reflect the committed changes.
Closed by commit rL313537: Use ThreadLauncher to launch TaskPool threads
(authored by fjricci).
Changed prior to commit:
https://reviews.llvm.org/D37930?vs=115484&id=115658#toc
Repository:
rL LLVM
https://reviews.llvm
fjricci created this revision.
This allows for the stack size to be configured, which isn't
possible with std::thread. Prevents overflowing the stack when
performing complex operations in the task pool on darwin,
where the default pthread stack size is only 512kb.
https://reviews.llvm.org/D37930
This revision was automatically updated to reflect the committed changes.
Closed by commit rL302260: Add missing 'arch' key to valid qHostInfo keys
(authored by fjricci).
Changed prior to commit:
https://reviews.llvm.org/D32711?vs=97322&id=97983#toc
Repository:
rL LLVM
https://reviews.llvm.
This revision was automatically updated to reflect the committed changes.
Closed by commit rL302027: Don't attempt to use mpx registers on unsupported
platforms (authored by fjricci).
Changed prior to commit:
https://reviews.llvm.org/D32719?vs=97447&id=97648#toc
Repository:
rL LLVM
https://
fjricci updated this revision to Diff 97447.
fjricci added a comment.
Move checks into cpp files
https://reviews.llvm.org/D32719
Files:
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
packages/Python/lldbsuite/test/functionalities/register/intel_xt
fjricci added a comment.
Yeah, that works too, just wasn't sure which way was preferred.
https://reviews.llvm.org/D32719
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
fjricci created this revision.
The existing cpp-level checks using PR_MPX_ENABLE_MANAGEMENT aren't sufficient,
as this isn't defined for linux kernel versions below 3.19.
https://reviews.llvm.org/D32719
Files:
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/Te
fjricci created this revision.
'arch' is a valid qHostInfo key, but the unit
test for qHostInfo did not include it in the set of possible keys.
https://reviews.llvm.org/D32711
Files:
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteHostInfo.py
Index: packages/Python/lldbsuite/t
fjricci added inline comments.
Comment at: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py:1418
"include")),
-'LD_EXTRAS': "-L%s -llldb" % lib_dir}
+'LD_EXTRAS': "-L%s/../lib -llldb -Wl,-r
fjricci abandoned this revision.
fjricci added a comment.
I primarily wrote this because `getArchFlag()` accounts for the possibility
that `getCompiler()` can be None. But my problem was unrelated, so I don't need
this (and I agree that it would be surprising if anyone did).
https://reviews.ll
fjricci created this revision.
Prior to r259433, getCompiler could return None without causing a
test suite crash. However, passing a NoneType to realpath will
cause a crash. Prevent this crash by allowing getCompiler to return None.
https://reviews.llvm.org/D31335
Files:
packages/Python/lldb
28 matches
Mail list logo
