Author: Med Ismail Bennani
Date: 2024-07-29T20:51:49-07:00
New Revision: 6bd5fd35063cd14b0a56bc6f7fb1e7b6e1ac56d5
URL:
https://github.com/llvm/llvm-project/commit/6bd5fd35063cd14b0a56bc6f7fb1e7b6e1ac56d5
DIFF:
https://github.com/llvm/llvm-project/commit/6bd5fd35063cd14b0a56bc6f7fb1e7b6e1ac56d5.
YungRaj wrote:
I got it working.
But symbolicating backtraces is still broken. Setting breakpoints by address,
reading memory, disassembling memory, etc is now working.
https://github.com/llvm/llvm-project/blob/40b4fd7a3e81d32b29364a1b15337bcf817659c0/lldb/source/Core/Section.cpp#L229
In `Se
@@ -154,3 +155,17 @@ MinidumpFile::create(MemoryBufferRef Source) {
return std::unique_ptr(
new MinidumpFile(Source, Hdr, *ExpectedStreams, std::move(StreamMap)));
}
+
+Expected> MinidumpFile::getMemory64List() const {
+ Expected MemoryList64 =
getMemoryList64Header()
@@ -154,3 +155,17 @@ MinidumpFile::create(MemoryBufferRef Source) {
return std::unique_ptr(
new MinidumpFile(Source, Hdr, *ExpectedStreams, std::move(StreamMap)));
}
+
+Expected> MinidumpFile::getMemory64List() const {
+ Expected MemoryList64 =
getMemoryList64Header()
https://github.com/clayborg requested changes to this pull request.
There must be some minidump yaml tests somewhere. We should add some to test
the YAML support. Also need to test for multiple MemoryDescriptor_64 entries in
a file using your new YAML.
https://github.com/llvm/llvm-project/pull
@@ -104,6 +105,25 @@ using ModuleListStream =
detail::ListStream;
using ThreadListStream = detail::ListStream;
using MemoryListStream = detail::ListStream;
+/// Memory64ListStream minidump stream.
+struct Memory64ListStream : public Stream {
+ std::vector Entries;
+ yaml::B
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/101086
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jimingham wrote:
> On Jul 29, 2024, at 3:16 PM, rocallahan ***@***.***> wrote:
>
>
> Is there a notion of "reverse stepping" like "take me to the line that
> preceded this one in execution history", and if so what contains the logic
> that does that?
>
> rr supports the "bs" gdbserver pack
rocallahan wrote:
> Is there a notion of "reverse stepping" like "take me to the line that
> preceded this one in execution history", and if so what contains the logic
> that does that?
rr supports the "bs" gdbserver packet to reverse-step a single instruction (and
so does the test proxy I'm
https://github.com/Jlalond edited
https://github.com/llvm/llvm-project/pull/101086
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Jlalond wrote:
@labath Would you mind if I added you as a reviewer for the `Obj2Yaml` changes
for minidump?
https://github.com/llvm/llvm-project/pull/101086
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/100477
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/100477
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -12,6 +12,7 @@
class MultipleSlidesTestCase(TestBase):
NO_DEBUG_INFO_TESTCASE = True
+@expectedFailureAll(oslist=["windows"], archs=["x86_64"])
kendalharland wrote:
Ah, sorry I spoke too soon. On windows I am seeing this fail. The test is built
wi
YungRaj wrote:
> This patch fixes the deserialization of the "address" field which surely can
> be tested in isolation. The existing test (`TestObjectFileJSON.py`) has
> `address` set to zero, which is why this happens to work today. It should be
> possible to either update the test or add a n
JDevlieghere wrote:
This patch fixes the deserialization of the "address" field which surely can be
tested in isolation. The existing test (`TestObjectFileJSON.py`) has `address`
set to zero, which is why this happens to work today. It should be possible to
either update the test or add a new
YungRaj wrote:
> The change itself looks good modulo formatting. Can you please update one of
> the existing tests to cover this use case?
This doesn't get symbolication fully working. We still need to prevent the
object file from being read when inspecting the symbolicated addresses through
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 6dba99e14f7e508a5028036b753fa7f84e846307
47af2b7229eaa6712fe5812e3d4dbea44bbb212b --e
llvmbot wrote:
@llvm/pr-subscribers-llvm-binary-utilities
Author: Jacob Lalonde (Jlalond)
Changes
This PR is in response to a bug my coworker @mbucko discovered where on
MacOS Minidumps were being created where the 64b memory regions were readable,
but were not being listed in `SBProcess
https://github.com/Jlalond edited
https://github.com/llvm/llvm-project/pull/101086
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond ready_for_review
https://github.com/llvm/llvm-project/pull/101086
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
JDevlieghere wrote:
The change itself looks good modulo formatting. Can you please update one of
the existing tests to cover this use case?
https://github.com/llvm/llvm-project/pull/101062
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
htt
jimingham wrote:
> On Jul 29, 2024, at 1:06 PM, rocallahan ***@***.***> wrote:
>
>
> As it stands, this will allow "reverse continue to a breakpoint", right?
>
> Using rr as the backend you can reverse-continue to any stop, including
> signals, watchpoints and the "history boundary" i.e. st
rocallahan wrote:
> As it stands, this will allow "reverse continue to a breakpoint", right?
Using rr as the backend you can reverse-continue to any stop, including
signals, watchpoints and the "history boundary" i.e. start of time. I expect
the other stop types don't work well yet. I plan to
dzhidzhoev wrote:
> Please don't use environment variables to pass options to the `make`
> invocation. It makes it really hard to reproduce build failures because you
> can't just copy-paste the failing invocation to debug the build. I went
> through an effort to clean that up a few years ago.
https://github.com/YungRaj edited
https://github.com/llvm/llvm-project/pull/101062
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
dzhidzhoev wrote:
Closed since another libcxx linking method is used
https://github.com/llvm/llvm-project/pull/99266#discussion_r1693409524.
https://github.com/llvm/llvm-project/pull/99589
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http
https://github.com/dzhidzhoev closed
https://github.com/llvm/llvm-project/pull/99589
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
MaskRay wrote:
> I like this idea a lot, but I have some reservations about the implementation.
>
> For one, I think this patch is too big. I once heard someone say "if you have
> bullet points in your patch description, then the patch is doing too much".
> While I don't think we should go as
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Ilhan Raja (YungRaj)
Changes
This is a dummy pull request to demonstrate the changes I made in to get
symbolication working using JSON Object/Symbol files
https://discourse.llvm.org/t/lldb-support-renaming-symbols-by-address-using-a-symbol
github-actions[bot] wrote:
Thank you for submitting a Pull Request (PR) to the LLVM Project!
This PR will be automatically labeled and the relevant teams will be
notified.
If you wish to, you can add reviewers by using the "Reviewers" section on this
page.
If this is not working for you, it
https://github.com/YungRaj created
https://github.com/llvm/llvm-project/pull/101062
This is a dummy pull request to demonstrate the changes I made in to get
symbolication working using JSON Object/Symbol files
https://discourse.llvm.org/t/lldb-support-renaming-symbols-by-address-using-a-symbol
clayborg wrote:
ok, I will break this up to make it easier to review.
https://github.com/llvm/llvm-project/pull/100900
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
slydiman wrote:
@labath It seems we do not need qSupported and qUpgradeToGdbConnection. We can
run
`lldb-server platform --server --listen 1234 --gdbserver-port 1235`
Option 1:
On receiving qLaunchGDBServer we can
- fork the child process to know the new pid
- send the response with the pid and
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/100477
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -12,6 +12,7 @@
class MultipleSlidesTestCase(TestBase):
NO_DEBUG_INFO_TESTCASE = True
+@expectedFailureAll(oslist=["windows"], archs=["x86_64"])
kendalharland wrote:
Looks like after my CMake chages,this one is passing now. I'll remove it from
the
jimingham wrote:
> > First off, for systems that do past motion and forward motion, there are
> > things you really can't do effectively in the past, like set variable
> > values and have that make any difference. So we probably will need to know
> > whether we're executing in the immutable pa
https://github.com/JDevlieghere edited
https://github.com/llvm/llvm-project/pull/100836
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/JDevlieghere requested changes to this pull request.
Please don't use environment variables to pass options to the `make`
invocation. It makes it really hard to reproduce build failures because you
can't just copy-paste the failing invocation to debug the build. I went throug
https://github.com/slydiman closed
https://github.com/llvm/llvm-project/pull/100659
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
slydiman wrote:
I have moved this patch to #100670.
https://github.com/llvm/llvm-project/pull/100659
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/slydiman updated
https://github.com/llvm/llvm-project/pull/100670
>From 0870140c8b8d465570a696b35b59fbf55610919a Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Thu, 25 Jul 2024 00:34:34 +0400
Subject: [PATCH 1/2] [lldb] Multithreading lldb-server works on Windows now;
@@ -153,19 +127,89 @@ void TypeQuery::SetLanguages(LanguageSet languages) {
bool TypeQuery::ContextMatches(
llvm::ArrayRef context_chain) const {
- if (GetExactMatch() || context_chain.size() == m_context.size())
-return ::contextMatches(context_chain, m_context);
-
-
labath wrote:
My idea for anonymous namespaces was basically to treat them as optional, so
that you could get a match (even an "exact" match maybe?) for `(anonymous
namespace)::Foo` with a pattern `Foo`. However, if a pattern explicitly
contained an `(anonymous namespace)`, then this would hav
@@ -97,12 +97,14 @@ void DWARFUnit::ExtractUnitDIEIfNeeded() {
*m_dwo_id, m_first_die.GetOffset()));
return; // Can't fetch the compile unit from the dwo file.
}
- // If the skeleton compile unit gets its unit DIE parsed first, then this
- // will fill in the DW
@@ -456,21 +492,15 @@ ifeq (1, $(USE_SYSTEM_STDLIB))
endif
CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem
$(SDKROOT)/usr/include/c++/v1
LDFLAGS += -L$(SDKROOT)/usr/lib -Wl,-rpath,$(SDKROOT)/usr/lib -lc++
+else
+ifneq (,$(findstring clang,$
@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,446 @@
+//===-- DILAST.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,560 @@
+//===-- DILAST.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,560 @@
+//===-- DILAST.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,560 @@
+//===-- DILAST.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/labath commented:
I still have a lot of comments, but I think we're making progress.
The most important questions are about the parts where we appear to be
reimplementing some existing lldb functionality. Basically all of the
functionality for looking up names (for members,
@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/95738
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/90059
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
Custom printing code for just enums for registers would be possible but it
means copying a lot of existing code. A callback reduces that to a copy of
`DumpEnumValue` only. Or you can iterate the value object yourself but then you
have to provide the surrounding format too
labath wrote:
> > The way this would work is by letting the platform instance
> > delegate/upgrate/convert the platform connection into a gdbserver one. The
> > way this would work would be something like this:
> >
> > 1. `lldb-server platform` would advertise (say in `qSupported`) its support
slydiman wrote:
> I'd like to hear your opinion on my port mapping alternative.
https://github.com/llvm/llvm-project/pull/100670#issuecomment-2255991921
https://github.com/llvm/llvm-project/pull/100659
___
lldb-commits mailing list
lldb-commits@lists.
slydiman wrote:
> The way this would work is by letting the platform instance
> delegate/upgrate/convert the platform connection into a gdbserver one. The
> way this would work would be something like this:
>
> 1. `lldb-server platform` would advertise (say in `qSupported`) its support
> for
DavidSpickett wrote:
> So instead of using enum for the field why not a union of enum and unsigned.
The union idea sort of works, but it's clunky enough I'm not going to pursue
it. The most verbose version:
```
fpcr = 0x
= {
<...>
RMode = (meaning = RN, value =
labath wrote:
> > Ok, so if I'm reading this right you're saying you saw no ETXTBSY errors
> > with the current implementation --server flag. Is that correct ?
>
> Right. Initially I have marked #100670 as dependent on this.
>
> Ok, agreed. So, we can try to use O_CLOFORK. And simple solution
slydiman wrote:
> Ok, so if I'm reading this right you're saying you saw no ETXTBSY errors with
> the current implementation --server flag. Is that correct ?
Right. Initially I have marked #100670 as dependent on this.
Ok, agreed. So, we can try to use O_CLOFORK.
And simple solution is to cal
labath wrote:
> > that could mean that something like `$CC hello.cc && ./a.out` could fail
> > (what we're doing here isn't fundamentally different than that).
>
> The difference is that cc creates a.out and exits itself. But `lldb-server
> platform` is still running after creating the executa
labath wrote:
> > Does this refer the the forking implementation you get with the --server
> > flag, or the serial implementation which only handles one connection at a
> > time (without the flag)?
>
> I mean the `--server` flag. It is very hard to reproduce this issue with the
> serial imple
slydiman wrote:
See also https://github.com/golang/go/issues/22315
https://github.com/llvm/llvm-project/pull/100659
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
slydiman wrote:
> that could mean that something like `$CC hello.cc && ./a.out` could fail
> (what we're doing here isn't fundamentally different than that).
The difference is that cc creates a.out and exits itself. But `lldb-server
platform` is still running after creating the executable. Som
labath wrote:
> > If this is only really used for a "only for few requests via the platform
> > protocol", then why not make the CWD a property of the platform object?
> > (Either through a virtual filesystem, or just by having it as a string, and
> > resolving things explicitly)
>
> It is po
slydiman wrote:
> Does this refer the the forking implementation you get with the --server
> flag, or the serial implementation which only handles one connection at a
> time (without the flag)?
I mean the `--server` flag. It is very hard to reproduce this issue with the
serial implementation
labath wrote:
I like this idea a lot, but I have some reservations about the implementation.
For one, I think this patch is too big. I once heard someone say "if you have
bullet points in your patch description, then the patch is doing too much".
While I don't think we should go as far as to c
slydiman wrote:
> If this is only really used for a "only for few requests via the platform
> protocol", then why not make the CWD a property of the platform object?
> (Either through a virtual filesystem, or just by having it as a string, and
> resolving things explicitly)
It is possible to
https://github.com/labath commented:
Could we standardize on `$(OBJCOPY) --strip-debug` instead?
https://github.com/llvm/llvm-project/pull/100836
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/99012
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
> @labath
>
> > I wanted to change this code to use threads for a long time, but the idea
> > of using a per-thread virtual file system absolutely terrifies me. That
> > only works is all of the accesses go through the file system (no direct
> > syscalls) and if we're very stric
@@ -324,6 +324,18 @@ Status PipePosix::ReadWithTimeout(void *buf, size_t size,
bytes_read += result;
if (bytes_read == size || result == 0)
break;
+
+// This is the workaround for the following bug in Linux multithreading
+// select() h
tschuett wrote:
I heard rumours that you know a bit about ELF :)
https://github.com/llvm/llvm-project/pull/100900
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
This seems fine, but what happens currently? Does it try to use a tool that's
built for the remote not the host?
https://github.com/llvm/llvm-project/pull/100836
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://li
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/100710
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Michael Buch
Date: 2024-07-29T09:35:00+01:00
New Revision: d72c8b02802c87386f5db3c7de6c79e921618fa3
URL:
https://github.com/llvm/llvm-project/commit/d72c8b02802c87386f5db3c7de6c79e921618fa3
DIFF:
https://github.com/llvm/llvm-project/commit/d72c8b02802c87386f5db3c7de6c79e921618fa3.diff
@@ -456,21 +492,15 @@ ifeq (1, $(USE_SYSTEM_STDLIB))
endif
CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem
$(SDKROOT)/usr/include/c++/v1
LDFLAGS += -L$(SDKROOT)/usr/lib -Wl,-rpath,$(SDKROOT)/usr/lib -lc++
+else
+ifneq (,$(findstring clang,$
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/100710
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
> * thread 1 opens a file for writing (file descriptor A) and starts writing it
>
> * thread 2 starts launching a gdb server. It calls fork(), which creates
> another process with a copy of fd A (the fd has the CLOEXEC flag set, but not
> CLOFORK (the flag doesn't exist))
>
> *
labath wrote:
That *may* be how things works on windows(*), but I'm pretty sure it's not how
things work on linux. A much more likely scenario is:
1. thread 1 opens a file for writing (file descriptor A) and starts writing it
2. thread 2 starts launching a gdb server. It calls fork(), which crea
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/96538
>From 294246a77e1bb16a34e9451bae65ad340c7ef7a9 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Mon, 29 Jan 2024 16:23:16 +
Subject: [PATCH 1/4] [lldb] Support new libc++ __compressed_pair layout
---
ll
MaskRay wrote:
I'm not familiar with lldb, but I can make some comments as @tschuett invited
me:)
Parsing PT_NOTE is a great step, as program headers are sufficient for
executables, shared objects, and core dumps.
The section header table isn't needed and the relevant code could be dropped
(u
94 matches
Mail list logo
