I think the thread naming is a reasonable way to go.
> 1) Linux and MacOSX inferiors can use pthread_setname_np
> 2) FreeBSD inferiors can use pthread_set_name_np
IIRC Linux and FreeBSD both are limited to a very short thread name, much
shorter than OS X and, if I'm not mistaken, Windows as well.
It's that time again! Sorry for the late reminder, but tomorrow is the
first Thursday of the month and we will once again be gathering at the Tied
House at 7pm! Come, Joon us to debate new IR constructs, crazy C++ features
and any and everything else LLVM!
The meetup link is:
http://www.meetup.com
The change for the ExpressionParser plugin didn't have changes in it for
the cmake or Makefile-based build systems.
I'll check in the cmake changes once my test build completes successfully.
- Bruce
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
htt
Note that completing types is a bit more complex with clang::ASTContext based
types because of it often uses the clang::Decl to do the type completion so we
need to maintain that mapping. It might not be that hard in Go as you could
just do:
CompilerType my_type = ...;
if (my_type.GetCompleteT
Also: lldb_private::TypeSystem has a "SymbolFile *" registered with it:
virtual SymbolFile *
GetSymbolFile () const
{
return m_sym_file;
}
// Returns true if the symbol file changed during the set accessor.
virtual void
SetSymbolFile (SymbolFile *sym_file)
> On Sep 2, 2015, at 3:15 PM, Ryan Brown via lldb-dev
> wrote:
>
> I'm trying to implement a DWARFASTParser for go, and have hit an issue with
> fields for structs.
> As I understand it, DWARFASTParserClang loads minimal type info for structs
> at first, and registers the type in SymbolFileDW
I'm trying to implement a DWARFASTParser for go, and have hit an issue with
fields for structs.
As I understand it, DWARFASTParserClang loads minimal type info for structs
at first, and registers the type in SymbolFileDWARF's
m_forward_decl_clang_type_to_die.
Then later when you call type.GetFullCo
> On Sep 2, 2015, at 1:06 PM, Greg Clayton via lldb-dev
> wrote:
>
> One idea is add the ability to discover which of any of the current threads
> are or are not user created. This might help us.
>
> On MacOSX, the main thread would always be considered user created, and any
> other thread,
I don't think that's a good plan. It's the implementation of std::thread
that created the thread pool. It's quite possible that it then
re-purposing thread pool threads as user threads. This gets into
implementation details that we'd have to figure out and which could change.
Even with the equi
https://llvm.org/bugs/show_bug.cgi?id=24681
Bug ID: 24681
Summary: Allow LLDB to distinguish between user threads and
system threads
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
That might work, on Windows I think we could identify this by looking
for ntdll.dll!TppWorkerThread() in the stack frame. This might not be
exactly the same across OS versions, but we could handle all cases as new
ones are discovered.
We would have to make sure that all developers are educated on
One idea is add the ability to discover which of any of the current threads are
or are not user created. This might help us.
On MacOSX, the main thread would always be considered user created, and any
other thread, it is quite easy to tell. User created threads could be ones
whose bottom stack
Historically the pattern for tests that need to test situations involving
threads has been to write the tests using pthreads, and then a common
pattern on the python side of the test is to assert that the actual number
of threads equals the expected number of threads.
To deal with the pthread port
https://llvm.org/bugs/show_bug.cgi?id=24679
Bug ID: 24679
Summary: Remove pexpect dependency from tests unless it's
absolutely necessary
Product: lldb
Version: unspecified
Hardware: All
OS: All
S
14 matches
Mail list logo
