Re: Program-assigned thread names on Windows

[Pedro Alves <palves at redhat dot com>]

On 08/11/2016 12:42 AM, LRN wrote:
> On 10.08.2016 21:45, Pedro Alves wrote:
>> On 08/10/2016 06:54 PM, LRN wrote:
>>
>> Maybe I could convince you to implement this in gdbserver/win32-low.c too?
> 
> You can't. I've never used gdbserver, and i don't see any need for me to
> start using it. And since i don't use it, i wouldn't be able to test
> anything code changes i could introduce there.

It's as simple as:

shell1:

$ gdbserver :9999 testprog.exe

shell2:

$ gdb testprog.exe -ex "tar rem :9999" -ex "b main" -ex "c"

> 
> TBH, i don't have any plans for further contributions to gdb. There is only
> one more feature that i thought could be added (using Windows API to obtain
> stack traces, enhancing the built-in gdb stack walker; thus gdb would be
> able to show useful stack trace even while being deep inside W32 API
> calls), but the code was so complicated for me that i've failed to even
> *find* where to start.
> 

Sounds like you'd need to write a new frame unwinder.
Grep for "const struct frame_unwind .* =" to find the
many instances.  

The IA64 one, in ia64-libunwind-tdep.c / ia64-tdep.c, is
probably the closest, as that uses an external library
(libunwind) to do the heavy lifting.

Our Windows x64 SEH unwinder is in amd64-windows-tdep.c.

I think I read that you're on 32-bit, though, right?

An unwinder independent of the system one is better for
being usable when cross debugging as well.  I wonder
whether between Microsoft's recent opening of the PDB format,
and what the community might have learned in the past
years itself, there's enough to avoid relying on MS APIs.
I'd go look at Wine's implementation of said APIs too.

Thanks,
Pedro Alves