History log of /llvm-project/lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp (Results 1 – 25 of 27)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3
# a819b0e5 11-Aug-2024 Alexandre Ganea <aganea@havenstudios.com>

[lldb] Silence warning

This fixes the following warning, when building with Clang ToT on
Windows:
```
[6668/7618] Building CXX object
tools\lldb\source\Plugins\Process\Windows\Common\CMakeFiles\lldb

[lldb] Silence warning

This fixes the following warning, when building with Clang ToT on
Windows:
```
[6668/7618] Building CXX object
tools\lldb\source\Plugins\Process\Windows\Common\CMakeFiles\lldbPluginProcessWindowsCommon.dir\TargetThreadWindows.cpp.obj
C:\src\git\llvm-project\lldb\source\Plugins\Process\Windows\Common\TargetThreadWindows.cpp(182,22):
warning: cast from 'FARPROC' (aka 'long long (*)()') to
'GetThreadDescriptionFunctionPtr' (aka 'long (*)(void *, wchar_t **)')
converts to incompatible function type [-Wcast-function-type-mismatch]
```

This is similar to: https://github.com/llvm/llvm-project/pull/97905

show more ...


Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init
# 048815c2 06-Jul-2024 Alexandre Ganea <aganea@havenstudios.com>

Revert "[lldb] Silence function cast warning when building with Clang ToT targetting Windows"

This reverts commit cf1ded3ac248ad4feeed7b4dd20c60b7e3c40339.


# cf1ded3a 06-Jul-2024 Alexandre Ganea <aganea@havenstudios.com>

[lldb] Silence function cast warning when building with Clang ToT targetting Windows


Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init
# f3f4387e 04-Jan-2024 gmh <13917777+gmh5225@users.noreply.github.com>

[lldb][NFC] Fix compilation issue on windows (#76453)


# 95e5839e 21-Dec-2023 oltolm <oleg.tolmatcev@gmail.com>

[lldb] add support for thread names on Windows (#74731)

This PR adds support for thread names in lldb on Windows.

```
(lldb) thr list
Process 2960 stopped
thread #53: tid = 0x03a0, 0x00007ff

[lldb] add support for thread names on Windows (#74731)

This PR adds support for thread names in lldb on Windows.

```
(lldb) thr list
Process 2960 stopped
thread #53: tid = 0x03a0, 0x00007ff84582db34 ntdll.dll`NtWaitForMultipleObjects + 20
thread #29: tid = 0x04ec, 0x00007ff845830a14 ntdll.dll`NtWaitForAlertByThreadId + 20, name = 'SPUW.6'
thread #89: tid = 0x057c, 0x00007ff845830a14 ntdll.dll`NtWaitForAlertByThreadId + 20, name = 'PPU[0x1000019] physics[main]'
thread #3: tid = 0x0648, 0x00007ff843c2cafe combase.dll`InternalDoATClassCreate + 39518
thread #93: tid = 0x0688, 0x00007ff845830a14 ntdll.dll`NtWaitForAlertByThreadId + 20, name = 'PPU[0x100501d] uMovie::StreamingThread'
thread #1: tid = 0x087c, 0x00007ff842e7a104 win32u.dll`NtUserMsgWaitForMultipleObjectsEx + 20
thread #96: tid = 0x0890, 0x00007ff845830a14 ntdll.dll`NtWaitForAlertByThreadId + 20, name = 'PPU[0x1002020] HLE Video Decoder'
<...>
```

show more ...


Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1
# c34698a8 03-Feb-2022 Pavel Labath <pavel@labath.sk>

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
inf

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.

After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.

show more ...


Revision tags: llvmorg-15-init
# a007a6d8 31-Jan-2022 Pavel Labath <pavel@labath.sk>

[lldb] Convert "LLDB" log channel to the new API


Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4
# 9f34f75f 14-Sep-2021 Martin Storsjö <martin@martin.st>

[lldb] [Windows] Fix continuing from breakpoints and singlestepping on ARM/AArch64

Based on suggestions by Eric Youngdale.

This fixes https://llvm.org/PR51673.

Differential Revision: https://revie

[lldb] [Windows] Fix continuing from breakpoints and singlestepping on ARM/AArch64

Based on suggestions by Eric Youngdale.

This fixes https://llvm.org/PR51673.

Differential Revision: https://reviews.llvm.org/D109777

show more ...


Revision tags: llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4
# 34d7143b 09-Mar-2020 Pavel Labath <pavel@labath.sk>

[lldb] Fix windows build, second attempt


# 24b1831e 09-Mar-2020 Pavel Labath <pavel@labath.sk>

[lldb] Fix windows&freebsd builds for c0b1af68


Revision tags: llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1
# 80814287 24-Jan-2020 Raphael Isemann <teemperor@gmail.com>

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258

show more ...


Revision tags: llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1
# a59444a3 21-Oct-2019 Martin Storsjo <martin@martin.st>

[LLDB] [Windows] Initial support for ARM register contexts

Differential Revision: https://reviews.llvm.org/D69226

llvm-svn: 375392


# b1f6ba2a 15-Oct-2019 Martin Storsjo <martin@martin.st>

[LLDB] [Windows] Initial support for ARM64 register contexts

Differential Revision: https://reviews.llvm.org/D67954

llvm-svn: 374866


# 2e25c44d 21-Sep-2019 Martin Storsjo <martin@martin.st>

[LLDB] Check for the GCC/MinGW compatible arch defines for windows, in addition to MSVC defines

This matches how it is done in all other similar ifdefs throughout
lldb.

Differential Revision: https

[LLDB] Check for the GCC/MinGW compatible arch defines for windows, in addition to MSVC defines

This matches how it is done in all other similar ifdefs throughout
lldb.

Differential Revision: https://reviews.llvm.org/D67858

llvm-svn: 372483

show more ...


Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4
# 842f55f3 07-Jul-2019 Saleem Abdulrasool <compnerd@compnerd.org>

Process: generalise Windows thread setup

The Windows build currently cannot support debugging foreign targets or
debugging Windows ARM NT and Windows ARM64 targets. Do not assume a
x64/x86 host. T

Process: generalise Windows thread setup

The Windows build currently cannot support debugging foreign targets or
debugging Windows ARM NT and Windows ARM64 targets. Do not assume a
x64/x86 host. This enables building lldb for Windows ARM64.

llvm-svn: 365282

show more ...


Revision tags: llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2
# b0717666 21-May-2019 Alexandre Ganea <alexandre.ganea@ubisoft.com>

Fix LLDB warnings when compiling with Clang 8.0

Differential Revision: https://reviews.llvm.org/D62021

llvm-svn: 361295


Revision tags: llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3
# d5b44036 13-Feb-2019 Jonas Devlieghere <jonas@devlieghere.com>

Replace 'ap' with 'up' suffix in variable names. (NFC)

The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique

Replace 'ap' with 'up' suffix in variable names. (NFC)

The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.

In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.

I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.

llvm-svn: 353912

show more ...


Revision tags: llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1
# 2946cd70 19-Jan-2019 Chandler Carruth <chandlerc@gmail.com>

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...


Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2
# d821c997 07-Aug-2018 Pavel Labath <pavel@labath.sk>

Move RegisterValue,Scalar,State from Core to Utility

These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall co

Move RegisterValue,Scalar,State from Core to Utility

These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall code layering (although it still does not break any particular
dependency completely).

The XCode project will need to be updated after this change.

Differential Revision: https://reviews.llvm.org/D49740

llvm-svn: 339127

show more ...


Revision tags: llvmorg-7.0.0-rc1
# 45d8134c 10-Jul-2018 Stella Stamenova <stilis@microsoft.com>

[windows] LLDB shows the wrong values when register read is executed at a frame other than zero

Summary:
This is a clean version of the change suggested here: https://bugs.llvm.org/show_bug.cgi?id=3

[windows] LLDB shows the wrong values when register read is executed at a frame other than zero

Summary:
This is a clean version of the change suggested here: https://bugs.llvm.org/show_bug.cgi?id=37495

The main change is to follow the same pattern as non-windows targets and use an unwinder object to retrieve the register context. I also changed a couple of the comments to actually log, so that issues with unsupported scenarios can be tracked down more easily. Lastly, ClearStackFrames is implemented in the base class, so individual thread implementations don't have to override it.

Reviewers: asmith, zturner, aleksandr.urakov

Reviewed By: aleksandr.urakov

Subscribers: emaste, stella.stamenova, tatyana-krasnukha, llvm-commits

Differential Revision: https://reviews.llvm.org/D49111

llvm-svn: 336732

show more ...


Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2
# 2ad48212 22-May-2018 James Y Knight <jyknight@google.com>

Normalize some lldb #include statements.

Most non-local includes of header files living under lldb/sources/
were specified with the full path starting after sources/. However, in
a few instances, ot

Normalize some lldb #include statements.

Most non-local includes of header files living under lldb/sources/
were specified with the full path starting after sources/. However, in
a few instances, other sub-directories were added to include paths, or

Normalize those few instances to follow the style used by the rest of
the codebase, to make it easier to understand.

llvm-svn: 333035

show more ...


# 0fd67b53 17-May-2018 Stella Stamenova <stilis@microsoft.com>

[Windows, Process] Fix an issue in windows thread handling that was causing LLDB to hang

Summary: The function ResumeThread on Windows returns a DWORD which is an unsigned int. In TargetThreadWindow

[Windows, Process] Fix an issue in windows thread handling that was causing LLDB to hang

Summary: The function ResumeThread on Windows returns a DWORD which is an unsigned int. In TargetThreadWindows::DoResume, there's code that determines how many times to call ResumeThread based on whether the return value is greater than 0. Since the function returns -1 (as an unsigned int) on failure, this was getting stuck in an infinite loop if ResumeThread failed for any reason. The correct thing to do is check whether the return value is -1 and then return the appropriate error instead of ignoring the return value.

Reviewers: asmith, zturner, labath

Reviewed By: zturner

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D47020

llvm-svn: 332670

show more ...


Revision tags: llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4
# 6f9e6901 03-Mar-2017 Zachary Turner <zturner@google.com>

Move Log from Core -> Utility.

All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.

Differential Revision: https://reviews.llvm.org/D30559

llvm-

Move Log from Core -> Utility.

All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.

Differential Revision: https://reviews.llvm.org/D30559

llvm-svn: 296909

show more ...


Revision tags: llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1
# 65abfb11 29-Nov-2016 Hafiz Abid Qadeer <hafiz_abid@mentor.com>

Fix a typo.

llvm-svn: 288118


# 4ad5def9 23-Nov-2016 Adrian McCarthy <amccarth@google.com>

Refactor LLDB's Windows process plugin (NFC)

The Windows process plugin was broken up into multiple pieces a while back in
order to share code between debugging live processes and minidumps
(postmor

Refactor LLDB's Windows process plugin (NFC)

The Windows process plugin was broken up into multiple pieces a while back in
order to share code between debugging live processes and minidumps
(postmortem) debugging. The minidump portion was replaced by a cross-platform
solution. This left the plugin split into a formerly "common" base classes and
the derived classes for live debugging. This extra layer made the code harder
to understand and work with.

This patch simplifies these class hierarchies by rolling the live debugging
concrete classes up to the base classes. Last week I posted my intent to make
this change to lldb-dev, and I didn't hear any objections.

This involved moving code and changing references to classes like
ProcessWindowsLive to ProcessWindows. It still builds for both 32- and 64-bit,
and the tests still pass on 32-bit. (Tests on 64-bit weren't passing before
this refactor for unrelated reasons.)

llvm-svn: 287770

show more ...


12