Closed chrisnas closed 12 months ago
It was intentionally removed until I figure out what to do with it. I'm not sure if I want to add it back or not. Here's what's going on:
MINIDUMP_THREAD
contains the TEB, but resolving where the TLS slot is requires ntdll symbols or hard coding the offset in the TEB for each platform.The end result is that we have to add a bunch of really messy code to IDataReader
implementations which only help a couple of ClrThread
properties, and they only really work on Windows. I need to go pull apart the Linux/OS X implementations to see how to determine that information too.
If this is really blocking something I can move it higher in the list of things to go work on, but otherwise I probably won't get around to it soon otherwise. This might also be something that I build in the M.D.R.Utilities project instead of ClrMD itself until I'm sure we got the design and implementation right.
Thanks a lot for all these details @leculver ! From my point of view, these properties do no bring a lot of value in .NET Core and they are not a blocker: so keep it low in your list ;^)
@leculver While I understand that there might be issues differentiating between different ThreadpoolThreadType values, is there any reason we do not expose ClrThread.IsThreadPoolThread
property which indicates whether thread belongs to pool at all?
That would be a simple threadState & TS_TPWorkerThread
and we already have that enum defined here. It would not differ from e.g. IsMTA
library provides.
I could make a PR to add this property!
The ClrThread type does not provide IsThreadpoolCompletionPort and IsThreadpoolWorker properties. Note that the corresponding ThreadType_Threadpool_IOCompletion and ThreadType_Threadpool_Worker values are available in the TlsThreadType enum (ClrmdThread.cs).
With the current CoreClr Linux implementation, the difference does not really make sense because I/O completion is processed by the ThreadPool without any distinction so I'm not sure if this is a bug...