[Lldb-commits] [PATCH] D93939: [elf-core] Improve reading memory from core file

[Djordje Todorovic via Phabricator via lldb-commits]

djtodoro updated this revision to Diff 318464.
djtodoro added a comment.

nfc


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93939/new/

https://reviews.llvm.org/D93939

Files:
  lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
  lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
  
lldb/test/API/functionalities/postmortem/elf-core/linux-x86_64-for-disassemble.core
  
lldb/test/API/functionalities/postmortem/elf-core/linux-x86_64-for-disassemble.out


Index: lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
===
--- lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
+++ lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
@@ -155,6 +155,37 @@
 self.do_test("linux-x86_64", self._x86_64_pid, self._x86_64_regions,
  "a.out")
 
+
+@skipIf(triple='^mips')
+@skipIfLLVMTargetMissing("X86")
+@skipIfWindows
+@skipIfReproducer
+def test_frame_disassemble(self):
+"""Test that we are able to disassemble all the frames"""
+disasmtarget = 
self.dbg.CreateTarget("linux-x86_64-for-disassemble.out")
+disasmprocess = 
disasmtarget.LoadCore("linux-x86_64-for-disassemble.core")
+self.assertTrue(disasmprocess, PROCESS_IS_VALID)
+
+disasmthread = disasmprocess.GetSelectedThread()
+framenum = disasmthread.GetNumFrames()
+for i in range(framenum):
+frame = disasmthread.GetFrameAtIndex(i)
+disassembly = frame.Disassemble()
+self.assertNotEqual(disassembly, "")
+self.assertNotIn("error", disassembly)
+# Make sure we don't have some dummy disassembly.
+# Each function should start with:
+#   pushq %rbp
+#   ...
+# Sometimes it just prints some dummy code as:
+#   addb %al, (%rax)
+#   addb %al, (%rax)
+#   ...
+framesetup = disassembly.splitlines()[1]
+self.assertNotIn("addb", framesetup)
+
+self.dbg.DeleteTarget(disasmtarget)
+
 @skipIf(triple='^mips')
 @skipIfLLVMTargetMissing("X86")
 def test_FPR_SSE(self):
Index: lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
===
--- lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -353,7 +353,6 @@
   const lldb::addr_t file_end = address_range->data.GetRangeEnd();
   size_t bytes_to_read = size; // Number of bytes to read from the core file
   size_t bytes_copied = 0;   // Number of bytes actually read from the core 
file
-  size_t zero_fill_size = 0; // Padding
   lldb::addr_t bytes_left =
   0; // Number of bytes available in the core file from the given address
 
@@ -367,24 +366,15 @@
   if (file_end > file_start + offset)
 bytes_left = file_end - (file_start + offset);
 
-  // Figure out how many bytes we need to zero-fill if we are reading more
-  // bytes than available in the on-disk segment
-  if (bytes_to_read > bytes_left) {
-zero_fill_size = bytes_to_read - bytes_left;
+  if (bytes_to_read > bytes_left)
 bytes_to_read = bytes_left;
-  }
 
   // If there is data available on the core file read it
   if (bytes_to_read)
 bytes_copied =
 core_objfile->CopyData(offset + file_start, bytes_to_read, buf);
 
-  assert(zero_fill_size <= size);
-  // Pad remaining bytes
-  if (zero_fill_size)
-memset(((char *)buf) + bytes_copied, 0, zero_fill_size);
-
-  return bytes_copied + zero_fill_size;
+  return bytes_copied;
 }
 
 void ProcessElfCore::Clear() {


Index: lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
===
--- lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
+++ lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
@@ -155,6 +155,37 @@
 self.do_test("linux-x86_64", self._x86_64_pid, self._x86_64_regions,
  "a.out")
 
+
+@skipIf(triple='^mips')
+@skipIfLLVMTargetMissing("X86")
+@skipIfWindows
+@skipIfReproducer
+def test_frame_disassemble(self):
+"""Test that we are able to disassemble all the frames"""
+disasmtarget = self.dbg.CreateTarget("linux-x86_64-for-disassemble.out")
+disasmprocess = disasmtarget.LoadCore("linux-x86_64-for-disassemble.core")
+self.assertTrue(disasmprocess, PROCESS_IS_VALID)
+
+disasmthread = disasmprocess.GetSelectedThread()
+framenum = disasmthread.GetNumFrames()
+for i in range(framenum):
+frame = disasmthread.GetFrameAtIndex(i)
+disassembly = frame.Disassemble()
+self.assertNotEqual(disassembly, "")
+self.assertNotIn("error", disassembly)
+# Make sure we don't have some dummy disassembly.
+  

[Lldb-commits] [PATCH] D67954: [LLDB] [Windows] Initial support for ARM64 register contexts

[Martin Storsjö via Phabricator via lldb-commits]

mstorsjo added a comment.

In D67954#2515028 , @mgorny wrote:

> Is there a specific reason you've only covered x0..x7 in the test?

No, only for keeping the test short and cohesive.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67954/new/

https://reviews.llvm.org/D67954

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D95165: Implement workaround for issue that shows between libedit and low-level terminal routines on Linux

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Can you be more specific about what is the nature and cause of this breakage?

Could it maybe be the fact that the `set_curterm(nullptr)` call (inside 
`terminalHasColors(fd)`) leaves terminfo with no "current" terminal, (whereas 
before the call it contained the "current" terminal, as setup by libedit? If so 
then maybe the right fix is to change `terminalHasColors` to restore the 
current terminal to whatever it was at the start of the function.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95165/new/

https://reviews.llvm.org/D95165

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D93939: [elf-core] Improve reading memory from core file

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

The fact that the test suite passes is not too surprising since we have very 
few core file tests. However, I agree that we should just remove this zero 
filling completely.

Regarding the test, would it be possible to reuse one of the existing core 
files? (The reason we have so few core tests is because we used to not allow 
checked in core files at all -- now we kinda do, but it's still not ideal.) I'm 
guessing you don't even need to disassemble a function to reproduce this -- it 
should be sufficient to run `disassemble --start-address X --end-address Y`, 
where the region `X--Y` crosses a core segment boundary..


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93939/new/

https://reviews.llvm.org/D93939

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D94888: [lldb] Add -Wl, -rpath to make tests run with fresh built libc++

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D94888#2511675 , @rupprecht wrote:

> In D94888#2506140 , @labath wrote:
>
>> I am pretty sure they were. This flag is needed to use (system) libc++ with 
>> gcc, and this was happening at a time when we were running the test suite 
>> with gcc, as it was still the default compiler for android.
>
> Is anyone running tests in this build mode (gcc + libc++) still? Should we 
> keep this support around?

It doesn't seem to work right now, so I guess the answer to the first question 
is "no". I don't mind removing it, but I also want to be careful about baking 
in clang assumptions as one of the purposes of this test suite is to be able to 
validate that we are able to debug the output of different compilers.




Comment at: lldb/packages/Python/lldbsuite/test/dotest.py:765-770
 cmd = [configuration.compiler, "-xc++", "-stdlib=libc++", "-o", 
f.name, "-"]
 p = subprocess.Popen(cmd, stdin=subprocess.PIPE, 
stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True)
 _, stderr = p.communicate("#include \nint main() {}")
 if not p.returncode:
 return True, "Compiling with -stdlib=libc++ works"
 return False, "Compiling with -stdlib=libc++ fails with the error: 
%s" % stderr

rupprecht wrote:
> I don't know if this is the right place to do it, but it would be good to 
> also check somewhere that binaries built w/ libc++ actually run. That would 
> help with the error you were seeing. Maybe something like this would work?
I'm not sure what does this help with? This compile command does not contain 
the -rpath flag, so, if the executable actually depended on libc++, it would 
not run. And if it does not depend on libc++ features, running it does not tell 
us anything new.

More generally, this is probably not the best place to implement fancy checks 
like this. It's a remnant of the time when folks were running dotest directly, 
and expecting it to just work. These days, it would be better to implement this 
kind of configuration in the lit config or some place like that. Among other 
benefits, it would mean that it gets run just once, instead of once for each 
test. But that is a topic for a different discussion...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94888/new/

https://reviews.llvm.org/D94888

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D95165: Implement workaround for issue that shows between libedit and low-level terminal routines on Linux

[Augusto Noronha via Phabricator via lldb-commits]

augusto2112 added a comment.

@labath, you were absolutely correct! It was simply a matter of saving and 
restoring the terminal struct on the `terminalHasColors` function in the 
`Process.inc` file (I really should've tried that before). I'm currently 
recompiling and will re-run the tests locally, and will push the changes after 
that. I do worry this could potentially impact macOS though (I don't know if 
these low-level terminal functions work differently between differently OSes), 
so how do we ensure this doesn't break anything there?

Also, since the patch will be completely different, should I open a new patch 
or push to this one and just change the title/description accordingly?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95165/new/

https://reviews.llvm.org/D95165

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D77043: Use remote regnums in expedited list, value regs and invalidate regs

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

There's still one "opportunistic" snippet in `GDBRemoteRegisterContext.cpp`, 
around line 404. Did you forget about that, or is there something special about 
that case? (if so, then what?)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77043/new/

https://reviews.llvm.org/D77043

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D95165: Implement workaround for issue that shows between libedit and low-level terminal routines on Linux

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D95165#2515232 , @augusto2112 wrote:

> @labath, you were absolutely correct! It was simply a matter of saving and 
> restoring the terminal struct on the `terminalHasColors` function in the 
> `Process.inc` file (I really should've tried that before). I'm currently 
> recompiling and will re-run the tests locally, and will push the changes 
> after that. I do worry this could potentially impact macOS though (I don't 
> know if these low-level terminal functions work differently between 
> differently OSes), so how do we ensure this doesn't break anything there?

We should pick reviewers which have some knowledge of this -- the original 
author of that code + whoever reviewed that patch is a good starting point. If 
this breaks anyone's use case after it gets reviewed&committed, that person 
will surely let us know (and then we can figure out what to do). However, I 
don't think this will be a particularly risky change. The more interesting 
question is whether there is any reasonable way of testing this

> Also, since the patch will be completely different, should I open a new patch 
> or push to this one and just change the title/description accordingly?

A new patch would probably be better in this case. However, it might be a good 
idea to add a reference to this discussion for context.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95165/new/

https://reviews.llvm.org/D95165

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D94672: Implement vAttachOrWait

[Augusto Noronha via Phabricator via lldb-commits]

augusto2112 added a comment.

@labath sorry for the repeated messages. I believe this is ready to be merged, 
right?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94672/new/

https://reviews.llvm.org/D94672

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

[Pavel Labath via lldb-commits]

On 19/01/2021 23:23, David Blaikie wrote:

On Tue, Jan 19, 2021 at 1:12 AM Pavel Labath  wrote:
Yeah - I have mixed feelings about debugger testing here - it is nice
to have end-to-end tests which makes for handy debugger testing
(though I guess in theory, debuginfo-tests is the place for
intentional end-to-end testing), though also being able to test
different features (DWARF version, split DWARF, dsym V object
debugging, etc) when they're written as end-to-end tests.


Yeah, it would be nice if there was a clearer separation between the two 
categories. The current setup has evolved organically, as the end-to-end 
API tests used to be the only kinds of tests.





Can we write non-end-to-end API tests, then?


Kind of. There is no fundamental reason why one couldn't run llvm-mc or 
whatever as a part of an API test. The main issue is that we don't have 
the infrastructure for that set up right now. I think the reason for 
that is that once you start dealing with "incomplete" executables which 
cannot be run on the host platform, the usefulness of interactivity goes 
down sharply. It is hard for such a test to do something other than load 
up some executable and query its state. This is a perfect use case for a 
shell test.


There are exceptions though. For example we have a collection of "API" 
tests which test the gdb-remote communication layer, by mocking one end 
of the connection. Such tests are necessarily interactive, which is why 
they ended up in the API category, but they are definitely not 
end-to-end tests, and they either don't use any executables, or just use 
a static yaml2objed executable. This is why our API tests have the 
ability to run yaml2obj and one could add other llvm tools in a similar 
fashion.


Another aspect of end-to-endness is being able to test a specific 
component of lldb, instead of just the debugger as a whole. Here the API 
tests cannot help because the "API" is the lldb public API. However, 
there are also various tricks you can do by using the low-level 
(debugging) commands (like the "image lookup" thing I mentioned) to 
interact with the lower debugger layers in some manner.



pl
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D93874: [process] fix exec support on Linux

[walter erquinigo via Phabricator via lldb-commits]

wallace added a comment.

Jim, thanks for the pointers! I think we are getting close to the issue. After 
doing what you asked, I found out the following:

- I set up the state of the lldb debugging the program that will exec right 
before it execs
- Then I do "continue"
- ThreadPlan::WillResume is invoked, which effectively clears out the m_thread 
cache. After this, I would expect no calls to ThreadPlan::GetThread until the 
the new thread list is created
- Then suddenly ThreadList::ShouldReportRun is invoked, which is handling the 
resume event. It eventually asks the current ThreadPlan ShouldReportRun, which 
invokes GetPreviousPlan() if m_run_vote is eVoteNoOpinion

  Vote ThreadPlan::ShouldReportRun(Event *event_ptr) {
if (m_run_vote == eVoteNoOpinion) {
  ThreadPlan *prev_plan = GetPreviousPlan();
  if (prev_plan)
return prev_plan->ShouldReportRun(event_ptr);
}
return m_run_vote;
  }

This triggers ends up invoking GetThread()

  ThreadPlan *GetPreviousPlan() { return GetThread().GetPreviousPlan(this); }

Which causes the incorrect value to be cached.

- After this event is processed, the stop exec happens, but the 
ThreadPlanBase's m_thread cache is not null, which breaks the invariant that 
you mentioned

> Keep continuing in the inferior lldb if you have to till you see it get the 
> stop packet that corresponds to the exec. At this point all the thread plans 
> should have no cached threads, so they are going to have to look them up.

I think that the ShouldReportRun is unavoidable at that step, so I thought of a 
couple of solutions.

- One is to to modify GetPreviousPlan() to something like this

  ThreadPlan *GetPreviousPlan() { return GetThread(/*cache_thread*/ 
false).GetPreviousPlan(this); }

This allows traversing the thread plan stack without caching the thread. This 
might be fine because ShouldReportRun is merely looking for any thread plan in 
the stack with an m_run_vote other than eVoteNoOpinion. It doesn't use the 
thread for any other reason.

- Another solution is to force clear the m_thread caches in all the ThreadPlans 
as soon as there's a stop event.

What do you think?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93874/new/

https://reviews.llvm.org/D93874

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D94888: [lldb] Add -Wl, -rpath to make tests run with fresh built libc++

[Fangrui Song via Phabricator via lldb-commits]

MaskRay updated this revision to Diff 318546.
MaskRay added a comment.

Drop fancy check in dotest.py (restore the previous behavior)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94888/new/

https://reviews.llvm.org/D94888

Files:
  lldb/packages/Python/lldbsuite/test/dotest.py
  lldb/packages/Python/lldbsuite/test/make/Makefile.rules


Index: lldb/packages/Python/lldbsuite/test/make/Makefile.rules
===
--- lldb/packages/Python/lldbsuite/test/make/Makefile.rules
+++ lldb/packages/Python/lldbsuite/test/make/Makefile.rules
@@ -279,11 +279,6 @@
 LD = $(CC)
 LDFLAGS ?= $(CFLAGS)
 LDFLAGS += $(LD_EXTRAS) $(ARCH_LDFLAGS)
-ifneq (,$(LLVM_LIBS_DIR))
-   ifeq ($(OS),NetBSD)
-   LDFLAGS += -L$(LLVM_LIBS_DIR) -Wl,-rpath,$(LLVM_LIBS_DIR)
-   endif
-endif
 ifeq (,$(filter $(OS), Windows_NT Android Darwin))
ifneq (,$(filter YES,$(ENABLE_THREADS)))
LDFLAGS += -pthread
@@ -393,21 +388,18 @@
 
 ifeq (1,$(USE_LIBCPP))
CXXFLAGS += -DLLDB_USING_LIBCPP
-   ifeq "$(OS)" "Linux"
-   ifneq (,$(findstring clang,$(CC)))
-   CXXFLAGS += -stdlib=libc++
-   LDFLAGS += -stdlib=libc++
-   else
-   CXXFLAGS += -isystem /usr/include/c++/v1
-   LDFLAGS += -lc++
-   endif
-   else ifeq "$(OS)" "Android"
+   ifeq "$(OS)" "Android"
# Nothing to do, this is already handled in
# Android.rules.
else
CXXFLAGS += -stdlib=libc++
LDFLAGS += -stdlib=libc++
endif
+   ifneq (,$(filter $(OS), FreeBSD Linux NetBSD))
+   ifneq (,$(LLVM_LIBS_DIR))
+   LDFLAGS += -Wl,-rpath,$(LLVM_LIBS_DIR)
+   endif
+   endif
 endif
 
 #--
Index: lldb/packages/Python/lldbsuite/test/dotest.py
===
--- lldb/packages/Python/lldbsuite/test/dotest.py
+++ lldb/packages/Python/lldbsuite/test/dotest.py
@@ -761,8 +761,6 @@
 return True, "libc++ always present"
 
 if platform == "linux":
-if os.path.isdir("/usr/include/c++/v1"):
-return True, "Headers found, let's hope they work"
 with tempfile.NamedTemporaryFile() as f:
 cmd = [configuration.compiler, "-xc++", "-stdlib=libc++", "-o", 
f.name, "-"]
 p = subprocess.Popen(cmd, stdin=subprocess.PIPE, 
stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True)


Index: lldb/packages/Python/lldbsuite/test/make/Makefile.rules
===
--- lldb/packages/Python/lldbsuite/test/make/Makefile.rules
+++ lldb/packages/Python/lldbsuite/test/make/Makefile.rules
@@ -279,11 +279,6 @@
 LD = $(CC)
 LDFLAGS ?= $(CFLAGS)
 LDFLAGS += $(LD_EXTRAS) $(ARCH_LDFLAGS)
-ifneq (,$(LLVM_LIBS_DIR))
-	ifeq ($(OS),NetBSD)
-		LDFLAGS += -L$(LLVM_LIBS_DIR) -Wl,-rpath,$(LLVM_LIBS_DIR)
-	endif
-endif
 ifeq (,$(filter $(OS), Windows_NT Android Darwin))
 	ifneq (,$(filter YES,$(ENABLE_THREADS)))
 		LDFLAGS += -pthread
@@ -393,21 +388,18 @@
 
 ifeq (1,$(USE_LIBCPP))
 	CXXFLAGS += -DLLDB_USING_LIBCPP
-	ifeq "$(OS)" "Linux"
-		ifneq (,$(findstring clang,$(CC)))
-			CXXFLAGS += -stdlib=libc++
-			LDFLAGS += -stdlib=libc++
-		else
-			CXXFLAGS += -isystem /usr/include/c++/v1
-			LDFLAGS += -lc++
-		endif
-	else ifeq "$(OS)" "Android"
+	ifeq "$(OS)" "Android"
 		# Nothing to do, this is already handled in
 		# Android.rules.
 	else
 		CXXFLAGS += -stdlib=libc++
 		LDFLAGS += -stdlib=libc++
 	endif
+	ifneq (,$(filter $(OS), FreeBSD Linux NetBSD))
+		ifneq (,$(LLVM_LIBS_DIR))
+			LDFLAGS += -Wl,-rpath,$(LLVM_LIBS_DIR)
+		endif
+	endif
 endif
 
 #--
Index: lldb/packages/Python/lldbsuite/test/dotest.py
===
--- lldb/packages/Python/lldbsuite/test/dotest.py
+++ lldb/packages/Python/lldbsuite/test/dotest.py
@@ -761,8 +761,6 @@
 return True, "libc++ always present"
 
 if platform == "linux":
-if os.path.isdir("/usr/include/c++/v1"):
-return True, "Headers found, let's hope they work"
 with tempfile.NamedTemporaryFile() as f:
 cmd = [configuration.compiler, "-xc++", "-stdlib=libc++", "-o", f.name, "-"]
 p = subprocess.Popen(cmd, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D93874: [process] fix exec support on Linux

[Jim Ingham via lldb-commits]

Excellent, thanks for persisting on this!

I think your second idea sounds less error prone than having to figure out 
whether the cache is trustworthy at a particular point.  Maybe even better than 
triggering off a stop event is to clear the caches before we do whatever might 
make the threads in the cache invalid.  That should only happen in 
Process::UpdateThreadList, so we could just move the current virtual 
UpdateThreadList method -> DoUpdateThreadList, and add a non-virtual 
UpdateThreadList that clears the cache and then calls UpdateThreadList.

There's also a non-virtual UpdateThreadListIfNeeded, and we could do it there 
before calling the virtual UpdateThreadList.  But then we'd have to ensure that 
the only way to call UpdateThreadList if through UpdateThreadListIfNeeded, 
which seems hard to ensure formally.  So I think just wrapping the virtual 
method to clear the cache before updating the thread list is the most robust 
way to do this.


Jim

> On Jan 22, 2021, at 8:53 AM, walter erquinigo via Phabricator 
>  wrote:
> 
> wallace added a comment.
> 
> Jim, thanks for the pointers! I think we are getting close to the issue. 
> After doing what you asked, I found out the following:
> 
> - I set up the state of the lldb debugging the program that will exec right 
> before it execs
> - Then I do "continue"
> - ThreadPlan::WillResume is invoked, which effectively clears out the 
> m_thread cache. After this, I would expect no calls to ThreadPlan::GetThread 
> until the the new thread list is created
> - Then suddenly ThreadList::ShouldReportRun is invoked, which is handling the 
> resume event. It eventually asks the current ThreadPlan ShouldReportRun, 
> which invokes GetPreviousPlan() if m_run_vote is eVoteNoOpinion
> 
>  Vote ThreadPlan::ShouldReportRun(Event *event_ptr) {
>if (m_run_vote == eVoteNoOpinion) {
>  ThreadPlan *prev_plan = GetPreviousPlan();
>  if (prev_plan)
>return prev_plan->ShouldReportRun(event_ptr);
>}
>return m_run_vote;
>  }
> 
> This triggers ends up invoking GetThread()
> 
>  ThreadPlan *GetPreviousPlan() { return GetThread().GetPreviousPlan(this); }
> 
> Which causes the incorrect value to be cached.
> 
> - After this event is processed, the stop exec happens, but the 
> ThreadPlanBase's m_thread cache is not null, which breaks the invariant that 
> you mentioned
> 
>> Keep continuing in the inferior lldb if you have to till you see it get the 
>> stop packet that corresponds to the exec. At this point all the thread plans 
>> should have no cached threads, so they are going to have to look them up.
> 
> I think that the ShouldReportRun is unavoidable at that step, so I thought of 
> a couple of solutions.
> 
> - One is to to modify GetPreviousPlan() to something like this
> 
>  ThreadPlan *GetPreviousPlan() { return GetThread(/*cache_thread*/ 
> false).GetPreviousPlan(this); }
> 
> This allows traversing the thread plan stack without caching the thread. This 
> might be fine because ShouldReportRun is merely looking for any thread plan 
> in the stack with an m_run_vote other than eVoteNoOpinion. It doesn't use the 
> thread for any other reason.
> 
> - Another solution is to force clear the m_thread caches in all the 
> ThreadPlans as soon as there's a stop event.
> 
> What do you think?
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D93874/new/
> 
> https://reviews.llvm.org/D93874
> 

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

[Jim Ingham via lldb-commits]

If you are just loading an object file and the looking at the line table or 
something like that, would a UnitTest be more suitable?

Jim


> On Jan 22, 2021, at 5:37 AM, Pavel Labath  wrote:
> 
> On 19/01/2021 23:23, David Blaikie wrote:
>> On Tue, Jan 19, 2021 at 1:12 AM Pavel Labath  wrote:
>> Yeah - I have mixed feelings about debugger testing here - it is nice
>> to have end-to-end tests which makes for handy debugger testing
>> (though I guess in theory, debuginfo-tests is the place for
>> intentional end-to-end testing), though also being able to test
>> different features (DWARF version, split DWARF, dsym V object
>> debugging, etc) when they're written as end-to-end tests.
> 
> Yeah, it would be nice if there was a clearer separation between the two 
> categories. The current setup has evolved organically, as the end-to-end API 
> tests used to be the only kinds of tests.
> 
> 
>> Can we write non-end-to-end API tests, then?
> 
> Kind of. There is no fundamental reason why one couldn't run llvm-mc or 
> whatever as a part of an API test. The main issue is that we don't have the 
> infrastructure for that set up right now. I think the reason for that is that 
> once you start dealing with "incomplete" executables which cannot be run on 
> the host platform, the usefulness of interactivity goes down sharply. It is 
> hard for such a test to do something other than load up some executable and 
> query its state. This is a perfect use case for a shell test.
> 
> There are exceptions though. For example we have a collection of "API" tests 
> which test the gdb-remote communication layer, by mocking one end of the 
> connection. Such tests are necessarily interactive, which is why they ended 
> up in the API category, but they are definitely not end-to-end tests, and 
> they either don't use any executables, or just use a static yaml2objed 
> executable. This is why our API tests have the ability to run yaml2obj and 
> one could add other llvm tools in a similar fashion.
> 
> Another aspect of end-to-endness is being able to test a specific component 
> of lldb, instead of just the debugger as a whole. Here the API tests cannot 
> help because the "API" is the lldb public API. However, there are also 
> various tricks you can do by using the low-level (debugging) commands (like 
> the "image lookup" thing I mentioned) to interact with the lower debugger 
> layers in some manner.
> 
> 
> pl

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] dc057e8 - [LLDB] Fix how ObjCBOOLSummaryProvider deals with BOOL

[Shafik Yaghmour via lldb-commits]

Author: Shafik Yaghmour
Date: 2021-01-22T10:05:24-08:00
New Revision: dc057e87f6c18c24d17c7cae97ebe95f78b6d934

URL: 
https://github.com/llvm/llvm-project/commit/dc057e87f6c18c24d17c7cae97ebe95f78b6d934
DIFF: 
https://github.com/llvm/llvm-project/commit/dc057e87f6c18c24d17c7cae97ebe95f78b6d934.diff

LOG: [LLDB] Fix how ObjCBOOLSummaryProvider deals with BOOL

ObjCBOOLSummaryProvider was incorrectly treating BOOL as unsigned and this is 
now fixed.
Also adding tests for one bit bit-fields of BOOL and unsigned char.

Added: 


Modified: 
lldb/source/Plugins/Language/ObjC/Cocoa.cpp

lldb/test/API/functionalities/data-formatter/boolreference/TestFormattersBoolRefPtr.py
lldb/test/API/functionalities/data-formatter/boolreference/main.mm
lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py
lldb/test/API/lang/objc/bitfield_ivars/main.m

Removed: 




diff  --git a/lldb/source/Plugins/Language/ObjC/Cocoa.cpp 
b/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
index ca4f7332f258..d871d3470e70 100644
--- a/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
+++ b/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
@@ -1035,7 +1035,7 @@ bool lldb_private::formatters::ObjCBOOLSummaryProvider(
 if (!real_guy_sp)
   return false;
   }
-  uint8_t value = (real_guy_sp->GetValueAsUnsigned(0) & 0xFF);
+  int8_t value = (real_guy_sp->GetValueAsSigned(0) & 0xFF);
   switch (value) {
   case 0:
 stream.Printf("NO");
@@ -1044,7 +1044,7 @@ bool lldb_private::formatters::ObjCBOOLSummaryProvider(
 stream.Printf("YES");
 break;
   default:
-stream.Printf("%u", value);
+stream.Printf("%d", value);
 break;
   }
   return true;

diff  --git 
a/lldb/test/API/functionalities/data-formatter/boolreference/TestFormattersBoolRefPtr.py
 
b/lldb/test/API/functionalities/data-formatter/boolreference/TestFormattersBoolRefPtr.py
index 7435409939e4..815a8ab903c0 100644
--- 
a/lldb/test/API/functionalities/data-formatter/boolreference/TestFormattersBoolRefPtr.py
+++ 
b/lldb/test/API/functionalities/data-formatter/boolreference/TestFormattersBoolRefPtr.py
@@ -75,3 +75,12 @@ def cleanup():
 substrs=['NO'])
 if not(isArm):
 self.expect('frame variable unset', substrs=['12'])
+
+self.expect_expr('myField', result_type="BoolBitFields",
+ result_children=[
+ ValueCheck(name="fieldOne", summary="NO"),
+ ValueCheck(name="fieldTwo", summary="-1"),
+ ValueCheck(name="fieldThree", summary="NO"),
+ ValueCheck(name="fieldFour", summary="NO"),
+ ValueCheck(name="fieldFive", summary="-1")
+ ])

diff  --git 
a/lldb/test/API/functionalities/data-formatter/boolreference/main.mm 
b/lldb/test/API/functionalities/data-formatter/boolreference/main.mm
index ce25c0b46e98..121849201bb1 100644
--- a/lldb/test/API/functionalities/data-formatter/boolreference/main.mm
+++ b/lldb/test/API/functionalities/data-formatter/boolreference/main.mm
@@ -1,12 +1,20 @@
 #import 
 
+typedef struct {
+BOOL fieldOne : 1;
+BOOL fieldTwo : 1;
+BOOL fieldThree : 1;
+BOOL fieldFour : 1;
+BOOL fieldFive : 1;
+} BoolBitFields;
+
 int main (int argc, const char * argv[])
 {
-NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
+  NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
 
BOOL yes  = YES;
BOOL no = NO;
-BOOL unset = 12;
+  BOOL unset = 12;

BOOL &yes_ref = yes;
BOOL &no_ref = no;
@@ -16,6 +24,10 @@ int main (int argc, const char * argv[])
BOOL* no_ptr = &no;
BOOL* unset_ptr = &unset;
 
+  BoolBitFields myField = {0};
+  myField.fieldTwo = YES;
+  myField.fieldFive = YES;
+
 [pool drain];// Set break point at this line.
 return 0;
 }

diff  --git a/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py 
b/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py
index 644dca52a464..4e7590de608e 100644
--- a/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py
+++ b/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py
@@ -25,6 +25,15 @@ def test(self):
  'field2 =', '3',
  'field3 =', '4'])
 
+self.expect_expr('myField', result_type="UCBitFields",
+ result_children=[
+ ValueCheck(name="fieldOne", value="'\\0'"),
+ ValueCheck(name="fieldTwo", value="'\\x01'"),
+ ValueCheck(name="fieldThree", value="'\\0'"),
+ ValueCheck(name="fieldFour", value="'\\0'"),
+ ValueCheck(name="fieldFive", value="'\\x01'")
+ ])
+
 # This test is meant to be xfailed, but running the test triggers an ASan
 # issue, so it must be skipped for now.
 @ski

[Lldb-commits] [PATCH] D94937: [lldb/Lua] add initial Lua typemaps

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

LGTM




Comment at: lldb/bindings/lua/lua-typemaps.swig:7
+
+// In 5.3 and beyond the VM supports integers, so we need to remap
+// SWIG's internal handling of integers.

nit: Lua 5.3


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94937/new/

https://reviews.llvm.org/D94937

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D95261: [lldb/test] Reduce API test tools configuration boilerplate

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: JDevlieghere, stella.stamenova.
Herald added a subscriber: mgorny.
labath requested review of this revision.
Herald added a project: LLDB.

Replace the dotest command line options and various cmake variables,
which are used for passing the locations of llvm tools to the API tests
with a single variable, which points to the directory these tools are
placed in. Besides reducing repetition, this also makes things more
similar to how "normal" llvm tests are configured.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D95261

Files:
  lldb/packages/Python/lldbsuite/test/dotest.py
  lldb/packages/Python/lldbsuite/test/dotest_args.py
  lldb/test/API/CMakeLists.txt
  lldb/test/API/lit.cfg.py
  lldb/test/API/lit.site.cfg.py.in
  lldb/utils/lldb-dotest/CMakeLists.txt
  lldb/utils/lldb-dotest/lldb-dotest.in

Index: lldb/utils/lldb-dotest/lldb-dotest.in
===
--- lldb/utils/lldb-dotest/lldb-dotest.in
+++ lldb/utils/lldb-dotest/lldb-dotest.in
@@ -7,14 +7,12 @@
 arch = '@LLDB_TEST_ARCH@'
 executable = '@LLDB_TEST_EXECUTABLE_CONFIGURED@'
 compiler = '@LLDB_TEST_COMPILER_CONFIGURED@'
-dsymutil = '@LLDB_TEST_DSYMUTIL_CONFIGURED@'
-filecheck = '@LLDB_TEST_FILECHECK_CONFIGURED@'
-yaml2obj = '@LLDB_TEST_YAML2OBJ_CONFIGURED@'
 server = '@LLDB_TEST_SERVER_CONFIGURED@'
 lldb_build_dir = '@LLDB_TEST_BUILD_DIRECTORY_CONFIGURED@'
 lldb_build_intel_pt = "@LLDB_BUILD_INTEL_PT@"
 lldb_framework_dir = "@LLDB_FRAMEWORK_DIR_CONFIGURED@"
 lldb_libs_dir = "@LLDB_LIBS_DIR_CONFIGURED@"
+llvm_tools_dir = "@LLVM_TOOLS_DIR_CONFIGURED@"
 
 if __name__ == '__main__':
 wrapper_args = sys.argv[1:]
@@ -26,10 +24,8 @@
 cmd.extend(['--build-dir', lldb_build_dir])
 cmd.extend(['--executable', executable])
 cmd.extend(['--compiler', compiler])
-cmd.extend(['--dsymutil', dsymutil])
-cmd.extend(['--yaml2obj', yaml2obj])
-cmd.extend(['--filecheck', filecheck])
 cmd.extend(['--lldb-libs-dir', lldb_libs_dir])
+cmd.extend(['--llvm-tools-dir', llvm_tools_dir])
 if server:
 cmd.extend(['--server', server])
 if lldb_framework_dir:
Index: lldb/utils/lldb-dotest/CMakeLists.txt
===
--- lldb/utils/lldb-dotest/CMakeLists.txt
+++ lldb/utils/lldb-dotest/CMakeLists.txt
@@ -25,9 +25,6 @@
 string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} LLDB_TEST_BUILD_DIRECTORY_CONFIGURED "${LLDB_TEST_BUILD_DIRECTORY}")
 string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} LLDB_TEST_EXECUTABLE_CONFIGURED "${LLDB_TEST_EXECUTABLE}")
 string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} LLDB_TEST_COMPILER_CONFIGURED "${LLDB_TEST_COMPILER}")
-string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} LLDB_TEST_DSYMUTIL_CONFIGURED "${LLDB_TEST_DSYMUTIL}")
-string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} LLDB_TEST_FILECHECK_CONFIGURED "${LLDB_TEST_FILECHECK}")
-string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} LLDB_TEST_YAML2OBJ_CONFIGURED "${LLDB_TEST_YAML2OBJ}")
 string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} LLDB_TEST_SERVER_CONFIGURED "${LLDB_TEST_SERVER}")
 
 # Remaining ones must be paths to the provided LLVM build-tree.
@@ -39,11 +36,9 @@
   string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} LLDB_TEST_BUILD_DIRECTORY_CONFIGURED "${LLDB_TEST_BUILD_DIRECTORY}")
   string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} LLDB_TEST_EXECUTABLE_CONFIGURED "${LLDB_TEST_EXECUTABLE}")
   string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} LLDB_TEST_COMPILER_CONFIGURED "${LLDB_TEST_COMPILER}")
-  string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} LLDB_TEST_DSYMUTIL_CONFIGURED "${LLDB_TEST_DSYMUTIL}")
-  string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} LLDB_TEST_FILECHECK_CONFIGURED "${LLDB_TEST_FILECHECK}")
-  string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} LLDB_TEST_YAML2OBJ_CONFIGURED "${LLDB_TEST_YAML2OBJ}")
   string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} LLDB_TEST_SERVER_CONFIGURED "${LLDB_TEST_SERVER}")
   string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} LLDB_LIBS_DIR_CONFIGURED "${LLDB_LIBS_DIR}")
+  string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} LLVM_TOOLS_DIR_CONFIGURED "${LLVM_TOOLS_BINARY_DIR}")
 else()
   # Single-configuration generator like Ninja.
   string(REPLACE ${CMAKE_CFG_INTDIR} "." LLDB_DOTEST_ARGS_CONFIGURED "${LLDB_DOTEST_ARGS}")
@@ -52,11 +47,9 @@
   string(REPLACE ${CMAKE_CFG_INTDIR} "." LLDB_TEST_BUILD_DIRECTORY_CONFIGURED "${LLDB_TEST_BUILD_DIRECTORY}")
   string(REPLACE ${CMAKE_CFG_INTDIR} "." LLDB_TEST_EXECUTABLE_CONFIGURED "${LLDB_TEST_EXECUTABLE}")
   string(REPLACE ${CMAKE_CFG_INTDIR} "." LLDB_TEST_COMPILER_CONFIGURED "${LLDB_TEST_COMPILER}")
-  string(REPLACE ${CMAKE_C

[Lldb-commits] [PATCH] D95261: [lldb/test] Reduce API test tools configuration boilerplate

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I should add, this also ensures one does not need to introduce a similar amount 
of cruft for each new llvm tool that he wants to use in the tests.




Comment at: lldb/test/API/CMakeLists.txt:59
 set(LLDB_TEST_COMPILER "${LLDB_DEFAULT_TEST_COMPILER}" CACHE PATH "C Compiler 
to use for building LLDB test inferiors")
-set(LLDB_TEST_DSYMUTIL "${LLDB_DEFAULT_TEST_DSYMUTIL}" CACHE PATH "dsymutil 
used for generating dSYM bundles")
-set(LLDB_TEST_FILECHECK "${LLDB_DEFAULT_TEST_FILECHECK}" CACHE PATH "FileCheck 
used for testing purposes")

Dsymutil is in compilation of inferiors, so it may make sense to leave it 
individually configurable, like we have it for the compiler, but I don't know 
if that would actually be useful (?)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95261/new/

https://reviews.llvm.org/D95261

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D95261: [lldb/test] Reduce API test tools configuration boilerplate

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added inline comments.



Comment at: lldb/test/API/CMakeLists.txt:59
 set(LLDB_TEST_COMPILER "${LLDB_DEFAULT_TEST_COMPILER}" CACHE PATH "C Compiler 
to use for building LLDB test inferiors")
-set(LLDB_TEST_DSYMUTIL "${LLDB_DEFAULT_TEST_DSYMUTIL}" CACHE PATH "dsymutil 
used for generating dSYM bundles")
-set(LLDB_TEST_FILECHECK "${LLDB_DEFAULT_TEST_FILECHECK}" CACHE PATH "FileCheck 
used for testing purposes")

labath wrote:
> Dsymutil is in compilation of inferiors, so it may make sense to leave it 
> individually configurable, like we have it for the compiler, but I don't know 
> if that would actually be useful (?)
Yeah, I recently did some work to make it possible to run the test suite 
against an Xcode installation, which contains a `dsymutil` but no `FileCheck` 
or `yaml2obj`. To keep that working, I need a way to configure the latter two 
separately. To me it doesn't really matter whether that's by setting the tools 
dir and having dsymutil specified separately, but that one way this would 
continue working. 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95261/new/

https://reviews.llvm.org/D95261

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D95261: [lldb/test] Reduce API test tools configuration boilerplate

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added inline comments.



Comment at: lldb/utils/lldb-dotest/CMakeLists.txt:87
   set(LLDB_LIBS_DIR_CONFIGURED "${LLDB_LIBS_DIR}")
+  set(LLVM_TOOLS_DIR_CONFIGURED "${LLVM_TOOLS_DIR_CONFIGURED}")
 

I think here you just want to set it to LLVM_TOOLS_BINARY_DIR, right?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95261/new/

https://reviews.llvm.org/D95261

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D93874: [process] fix exec support on Linux

[walter erquinigo via Phabricator via lldb-commits]

wallace updated this revision to Diff 318640.
wallace added a comment.
Herald added a subscriber: emaste.

Updated based on @jingham's idea, and added an independent test for this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93874/new/

https://reviews.llvm.org/D93874

Files:
  lldb/include/lldb/Target/Process.h
  lldb/include/lldb/Target/ProcessTrace.h
  lldb/include/lldb/Target/ThreadPlan.h
  lldb/include/lldb/Target/ThreadPlanStack.h
  lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.h
  lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
  lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.h
  lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
  lldb/source/Plugins/Process/Windows/Common/ProcessWindows.h
  lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
  lldb/source/Plugins/Process/elf-core/ProcessElfCore.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
  lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
  lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
  lldb/source/Plugins/Process/minidump/ProcessMinidump.h
  lldb/source/Target/Process.cpp
  lldb/source/Target/ProcessTrace.cpp
  lldb/source/Target/ThreadPlan.cpp
  lldb/source/Target/ThreadPlanStack.cpp
  lldb/test/API/functionalities/exec/TestExec.py
  lldb/unittests/Process/ProcessEventDataTest.cpp
  lldb/unittests/Target/ExecutionContextTest.cpp
  lldb/unittests/Thread/ThreadTest.cpp

Index: lldb/unittests/Thread/ThreadTest.cpp
===
--- lldb/unittests/Thread/ThreadTest.cpp
+++ lldb/unittests/Thread/ThreadTest.cpp
@@ -51,8 +51,8 @@
   Status &error) {
 return 0;
   }
-  virtual bool UpdateThreadList(ThreadList &old_thread_list,
-ThreadList &new_thread_list) {
+  bool DoUpdateThreadList(ThreadList &old_thread_list,
+  ThreadList &new_thread_list) override {
 return false;
   }
   virtual ConstString GetPluginName() { return ConstString("Dummy"); }
Index: lldb/unittests/Target/ExecutionContextTest.cpp
===
--- lldb/unittests/Target/ExecutionContextTest.cpp
+++ lldb/unittests/Target/ExecutionContextTest.cpp
@@ -58,8 +58,8 @@
   Status &error) {
 return 0;
   }
-  virtual bool UpdateThreadList(ThreadList &old_thread_list,
-ThreadList &new_thread_list) {
+  bool DoUpdateThreadList(ThreadList &old_thread_list,
+  ThreadList &new_thread_list) override {
 return false;
   }
   virtual ConstString GetPluginName() { return ConstString("Dummy"); }
Index: lldb/unittests/Process/ProcessEventDataTest.cpp
===
--- lldb/unittests/Process/ProcessEventDataTest.cpp
+++ lldb/unittests/Process/ProcessEventDataTest.cpp
@@ -53,8 +53,8 @@
   Status &error) {
 return 0;
   }
-  virtual bool UpdateThreadList(ThreadList &old_thread_list,
-ThreadList &new_thread_list) {
+  bool DoUpdateThreadList(ThreadList &old_thread_list,
+  ThreadList &new_thread_list) override {
 return false;
   }
   virtual ConstString GetPluginName() { return ConstString("Dummy"); }
Index: lldb/test/API/functionalities/exec/TestExec.py
===
--- lldb/test/API/functionalities/exec/TestExec.py
+++ lldb/test/API/functionalities/exec/TestExec.py
@@ -115,3 +115,78 @@
 self.runCmd("bt")
 self.assertTrue(len(threads) == 1,
 "Stopped at breakpoint in exec'ed process.")
+
+@expectedFailureAll(archs=['i386'],
+oslist=no_match(["freebsd"]),
+bugnumber="rdar://28656532")
+@expectedFailureAll(oslist=["ios", "tvos", "watchos", "bridgeos"], bugnumber="rdar://problem/34559552") # this exec test has problems on ios systems
+@expectedFailureNetBSD
+@skipIfAsan # rdar://problem/43756823
+@skipIfWindows
+def test_correct_thread_plan_state_before_exec(self):
+'''
+In this test we make sure that the Thread* cache in the ThreadPlans
+is cleared correctly when performing exec
+'''
+
+self.build()
+exe = self.getBuildArtifact("a.out")
+secondprog = self.getBuildArtifact("secondprog")
+
+# Create the target
+target = self.dbg.CreateTarget(exe)
+
+# Create any breakpoints we need
+breakpoint1 = target.BreakpointCreateBySourceRegex(
+'Set breakpoint 1 here', lldb.SBFileSpec("main.cpp", False))
+self.asse

[Lldb-commits] [PATCH] D94811: [lldb] Fix fallthrough with strictly virtual working directory.

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere abandoned this revision.
JDevlieghere added a comment.

Superseded by D95188 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94811/new/

https://reviews.llvm.org/D94811

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D94064: lldb: Add support for printing variables with DW_AT_ranges on DW_TAG_subprograms

[David Blaikie via Phabricator via lldb-commits]

dblaikie updated this revision to Diff 318654.
dblaikie added a comment.

Retrieve the lowest address in the address ranges, rather than just hardcoding 0


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94064/new/

https://reviews.llvm.org/D94064

Files:
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/test/Shell/SymbolFile/DWARF/Inputs/subprogram_ranges.s
  lldb/test/Shell/SymbolFile/DWARF/subprogram_ranges.test

Index: lldb/test/Shell/SymbolFile/DWARF/subprogram_ranges.test
===
--- lldb/test/Shell/SymbolFile/DWARF/subprogram_ranges.test
+++ lldb/test/Shell/SymbolFile/DWARF/subprogram_ranges.test
@@ -16,4 +16,8 @@
 
 b main
 # CHECK: (lldb) b main
-# CHECK-NEXT: Breakpoint 1: where = {{.*}}`main + 6 at main.c:2:7
+# CHECK-NEXT: Breakpoint 1: where = {{.*}}`main at subprogram_ranges.c:4:5
+
+image lookup -v -s main
+# CHECK: 1 symbols match 'main'
+# CHECK:  Variable: {{.*}}, name = "var", type = "int", {{.*}}, decl = subprogram_ranges.c:3
Index: lldb/test/Shell/SymbolFile/DWARF/Inputs/subprogram_ranges.s
===
--- lldb/test/Shell/SymbolFile/DWARF/Inputs/subprogram_ranges.s
+++ lldb/test/Shell/SymbolFile/DWARF/Inputs/subprogram_ranges.s
@@ -1,32 +1,53 @@
 	.text
-	.file	"main.c"
+	.file	"subprogram_ranges.c"
 	.globl	main# -- Begin function main
 	.p2align	4, 0x90
 	.type	main,@function
 main:   # @main
 .Lfunc_begin0:
-	.file	1 "/usr/local/google/home/blaikie/dev/scratch" "main.c"
-	.loc	1 1 0   # main.c:1:0
+	.file	1 "/usr/local/google/home/blaikie/dev/scratch" "subprogram_ranges.c"
+	.loc	1 2 0   # subprogram_ranges.c:2:0
 	.cfi_startproc
 # %bb.0:# %entry
-	pushq	%rbp
-	.cfi_def_cfa_offset 16
-	.cfi_offset %rbp, -16
-	movq	%rsp, %rbp
-	.cfi_def_cfa_register %rbp
-	xorl	%eax, %eax
+	#DEBUG_VALUE: main:var <- 3
+	.loc	1 4 5 prologue_end  # subprogram_ranges.c:4:5
+	movl	$1, i(%rip)
 .Ltmp0:
-	.loc	1 2 7 prologue_end  # main.c:2:7
-	movl	$3, -4(%rbp)
-	.loc	1 3 1   # main.c:3:1
-	popq	%rbp
-	.cfi_def_cfa %rsp, 8
+	#DEBUG_VALUE: main:var <- 5
+	.loc	1 6 5   # subprogram_ranges.c:6:5
+	movl	$2, i(%rip)
+	.loc	1 7 1   # subprogram_ranges.c:7:1
+	xorl	%eax, %eax
 	retq
 .Ltmp1:
 .Lfunc_end0:
 	.size	main, .Lfunc_end0-main
 	.cfi_endproc
 # -- End function
+	.type	i,@object   # @i
+	.bss
+	.globl	i
+	.p2align	2
+i:
+	.long	0   # 0x0
+	.size	i, 4
+
+	.section	.debug_loc,"",@progbits
+.Ldebug_loc0:
+	.quad	.Lfunc_begin0-.Lfunc_begin0
+	.quad	.Ltmp0-.Lfunc_begin0
+	.short	3   # Loc expr size
+	.byte	17  # DW_OP_consts
+	.byte	3   # 3
+	.byte	159 # DW_OP_stack_value
+	.quad	.Ltmp0-.Lfunc_begin0
+	.quad	.Lfunc_end0-.Lfunc_begin0
+	.short	3   # Loc expr size
+	.byte	17  # DW_OP_consts
+	.byte	5   # 5
+	.byte	159 # DW_OP_stack_value
+	.quad	0
+	.quad	0
 	.section	.debug_abbrev,"",@progbits
 	.byte	1   # Abbreviation Code
 	.byte	17  # DW_TAG_compile_unit
@@ -54,6 +75,8 @@
 	.byte	23  # DW_FORM_sec_offset
 	.byte	64  # DW_AT_frame_base
 	.byte	24  # DW_FORM_exprloc
+	.ascii	"\227B" # DW_AT_GNU_all_call_sites
+	.byte	25  # DW_FORM_flag_present
 	.byte	3   # DW_AT_name
 	.byte	14  # DW_FORM_strp
 	.byte	58  # DW_AT_decl_file
@@ -70,7 +93,7 @@
 	.byte	52  # DW_TAG_variable
 	.byte	0   # DW_CHILDREN_no
 	.byte	2   # DW_AT_location
-	.byte	24  # DW_FORM_exprloc
+	.byte	23  # DW_FORM_sec_offset
 	.byte	3   # DW_AT_name
 	.byte	14  # DW_FORM_strp
 	.byte	58  # DW_AT_decl_file
@@ -100,7 +123,7 @@
 	.short	4   # DWARF version number
 	.long	.debug_abbrev   # Offset Into Abbrev. Section
 	.byte	8   # Address Size (in bytes)
-	.byte	1   # Abbrev [1] 0xb:0x47 DW_TAG_compile_unit
+	.byte	1   # Abbrev [1] 0xb:0x48 DW_TAG_compile_unit
 	.long	.Linfo_string0  # DW_AT_producer
 	

[Lldb-commits] [lldb] 3a50ed8 - [lldb] FixFileSystem::GetExternalPath for VFS API change

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2021-01-22T15:04:17-08:00
New Revision: 3a50ed84f4823fb0e7b385cc22fef12435dfd376

URL: 
https://github.com/llvm/llvm-project/commit/3a50ed84f4823fb0e7b385cc22fef12435dfd376
DIFF: 
https://github.com/llvm/llvm-project/commit/3a50ed84f4823fb0e7b385cc22fef12435dfd376.diff

LOG: [lldb] FixFileSystem::GetExternalPath for VFS API change

Added: 


Modified: 
lldb/source/Host/common/FileSystem.cpp

Removed: 




diff  --git a/lldb/source/Host/common/FileSystem.cpp 
b/lldb/source/Host/common/FileSystem.cpp
index 8a6c03f72b6f..9fa8854d950e 100644
--- a/lldb/source/Host/common/FileSystem.cpp
+++ b/lldb/source/Host/common/FileSystem.cpp
@@ -479,7 +479,7 @@ ErrorOr FileSystem::GetExternalPath(const 
llvm::Twine &path) {
 
   // If VFS mapped we know the underlying FS is a RedirectingFileSystem.
   ErrorOr E =
-  static_cast(*m_fs).lookupPath(path);
+  static_cast(*m_fs).lookupPath(path.str());
   if (!E) {
 if (E.getError() == llvm::errc::no_such_file_or_directory) {
   return path.str();



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D93874: [process] fix exec support on Linux

[Jim Ingham via Phabricator via lldb-commits]

jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

Yes, this is how I should have done it originally.  Thanks!

I had one suggestion for making the test more compact which you can do or not 
as you please.  Other than the LGTM.




Comment at: lldb/test/API/functionalities/exec/TestExec.py:133-158
+exe = self.getBuildArtifact("a.out")
+secondprog = self.getBuildArtifact("secondprog")
+
+# Create the target
+target = self.dbg.CreateTarget(exe)
+
+# Create any breakpoints we need

I don't think you need to set the second breakpoint till after you've stopped 
at the first one, If not, you should be able to replace everything from the 
"exe = self.getBuildArtifact" to the self.assertTrue(len(threads == 1)) with:

(target, process, thread, breakpoint1) = 
lldbutil.run_to_source_breakpoint(self, 'Set breakpoint 1 here', 
lldb.SBFileSpec('main.cpp', False))
breakpoint2 = target.BreakpointCreateBySourceRegex(...)

and "threads[0]" below -> "thread", which is a lot easier to read.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93874/new/

https://reviews.llvm.org/D93874

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D94064: lldb: Add support for printing variables with DW_AT_ranges on DW_TAG_subprograms

[David Blaikie via Phabricator via lldb-commits]

dblaikie added a comment.

In D94064#2485222 , @labath wrote:

> In D94064#2483578 , @dblaikie wrote:
>
>> In D94064#2481925 , @labath wrote:
>>
>>> I don't think that simply setting func_lo_pc to zero will be sufficient to 
>>> make this work. I would expect this to break in more complicated scenarios 
>>> (like, even if we just have two of these functions). I think the only 
>>> reason it works in this case is because for this particular function, it's 
>>> base address (relative to the CU base) *is* zero.
>>
>> I certainly don't have high confidence in the change, to be sure - but I 
>> think it's a bit more robust than that.
>
> Yes, it seems it is, though just by a bit. :)
>
> The thing which is missing is the location list on the variable DIE -- 
> without it, it does not matter which address gets put here (so long as it 
> does not trigger the assertion), as the value is totally unused. The 
> necessity of the location list is kind of obvious from my description of the 
> problem, though even I did not realize when I was writing it that this 
> requires a more elaborate test case.
>
> Adjusting your test case to produce a location list for `i` I got this 
> (probably not minimal) snippet (add -O1 to CFLAGS):
>
>   #define optnone __attribute__((optnone))
>   #define noinline __attribute__((noinline))
>   
>   void optnone noinline stop() {}
>   void optnone noinline consume(int i) {}
>   void noinline f1(int x) {
> int i = x;
> stop();
> consume(i);
> i = 5;
> consume(i);
>   }
>   int main() {
> int j = 12;
> f1(j);
> stop();
>   }
>
> Here lldb fails to print the value of `i`, but if I rearrange the code so 
> that the `f1` functions comes first, the value is printed correctly:
>
>   #define optnone __attribute__((optnone))
>   #define noinline __attribute__((noinline))
>   
>   void optnone noinline stop();
>   void optnone noinline consume(int i);
>   void noinline f1(int x) {
> int i = x;
> stop();
> consume(i);
> i = 5;
> consume(i);
>   }
>   void optnone noinline stop() {}
>   void optnone noinline consume(int i) {}
>   int main() {
> int j = 12;
> f1(j);
> stop();
>   }

Ah, thanks - think I figured out a representative test & understand better.
I ended up with this:

  __attribute__((nodebug)) volatile int i;
  int main() {
int var = 3;
i = 1;
var = 5;
i = 2;
  }

By using volatile writes, I was able to get the 'var' variable live range to 
start at the start of the function (so that `image lookup -v -s main` would 
render the "var" variable since it's now live at the very start of the function 
(rather than only after the push instruction)). And use nodebug to reduce the 
DWARF since the 'i' isn't interesting.

Indeed without the fix you suggested to use "lowest address" rather than zero, 
this test above would/was failing (running the image lookup command would not 
show the "var" variable).

Also, I figured out how to run the API tests, and that showed a bunch more 
failures when using ranges-everywhere (actually a more aggressive version of 
ranges-everywhere - using it no matter the DWARF version and even when it 
wouldn't reduce the address pool size (eg: using ranges on a subprogram even 
when low_pc is an address already in the pool (such as for the start of a CU 
range))) - and with the change to use the lowest address of the ranges, all 
those failures now go away.

So *fingers crossed* this is ready.

>>> The purpose of func_lo_pc is pretty weird, but it's essentially used for 
>>> runtime relocation of location lists within the function -- we take the 
>>> static "base" of the function, and the runtime "base", and the difference 
>>> between the two produces the load bias. Applying the same bias to all 
>>> variable location lists "relocates" the variables. (The reason this is so 
>>> convoluted is reading location lists straight from (unrelocated) .o files 
>>> on mac. I seriously considered changing this when working on 
>>> debug_rnglists, but it turned out it wasn't really necessary, so I let it 
>>> go.)
>>
>> Yep, I figured a bunch of this was for DWARF in unrelocated MachO files - 
>> and that they wouldn't be able to/want to use Split DWARF or this feature 
>> (which is particularly relevant to Split DWARF). Does any of this logic 
>> apply outside that unrelocated MachO scenario?
>
> Yes, this code is used everywhere, though it's role is less important (and 
> one that could be implemented in an easier manner, were it not for MachO) -- 
> it adjusts the variable address for ASLR, i.e., the variable/function being 
> loaded at a different address than what the static debug info says.

Ah, good to know!

>>> LLDB's representation of a function (lldb_private::Function) assumes that 
>>> all functions will be contiguous (Function::GetAddressRange returns a 
>>> single range

[Lldb-commits] [lldb] ad25bdc - Change static buffer to be BSS instead of DATA in HandlePacket_qSpeedTest

[Jason Molenda via lldb-commits]

Author: Jason Molenda
Date: 2021-01-22T16:14:24-08:00
New Revision: ad25bdcb8e4e9459886062d3855a5971af758731

URL: 
https://github.com/llvm/llvm-project/commit/ad25bdcb8e4e9459886062d3855a5971af758731
DIFF: 
https://github.com/llvm/llvm-project/commit/ad25bdcb8e4e9459886062d3855a5971af758731.diff

LOG: Change static buffer to be BSS instead of DATA in HandlePacket_qSpeedTest

Having this 4MB buffer with a compile-time initialized string forced it
into the DATA section and it took up 4MB of space in the binary, which
accounts for like 80% of debugserver's footprint on disk.  Change it to
BSS and strcpy in the initial value at runtime instead.



Added: 


Modified: 
lldb/tools/debugserver/source/RNBRemote.cpp

Removed: 




diff  --git a/lldb/tools/debugserver/source/RNBRemote.cpp 
b/lldb/tools/debugserver/source/RNBRemote.cpp
index fd713f08a3cc..586336a21b6b 100644
--- a/lldb/tools/debugserver/source/RNBRemote.cpp
+++ b/lldb/tools/debugserver/source/RNBRemote.cpp
@@ -4578,7 +4578,8 @@ rnb_err_t RNBRemote::HandlePacket_qSpeedTest(const char 
*p) {
 __FILE__, __LINE__, p,
 "Didn't find response_size value at right offset");
   else if (*end == ';') {
-static char g_data[4 * 1024 * 1024 + 16] = "data:";
+static char g_data[4 * 1024 * 1024 + 16];
+strcpy(g_data, "data:");
 memset(g_data + 5, 'a', response_size);
 g_data[response_size + 5] = '\0';
 return SendPacket(g_data);



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D94064: lldb: Add support for printing variables with DW_AT_ranges on DW_TAG_subprograms

[David Blaikie via Phabricator via lldb-commits]

dblaikie updated this revision to Diff 318711.
dblaikie added a comment.

Include some more details about/in the test


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94064/new/

https://reviews.llvm.org/D94064

Files:
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/test/Shell/SymbolFile/DWARF/Inputs/subprogram_ranges.s
  lldb/test/Shell/SymbolFile/DWARF/subprogram_ranges.test

Index: lldb/test/Shell/SymbolFile/DWARF/subprogram_ranges.test
===
--- lldb/test/Shell/SymbolFile/DWARF/subprogram_ranges.test
+++ lldb/test/Shell/SymbolFile/DWARF/subprogram_ranges.test
@@ -14,6 +14,26 @@
 # especially useful, but don't dismiss it as pointless just because it's a bit
 # weird.
 
+# * Using volatile writes to create instructions the location may be valid over
+# * Using two values for the variable so it is described by a location list,
+#   not a single location description
+# * Not using function calls, so that the function has no frame pointer
+#   initialization/no prologue instructions, so the location of "var" is valid
+#   at the start of the function, so 'image lookup -v -s main' will include it.
+#
+# Source:
+# __attribute__((nodebug)) volatile int i;
+# int main() {
+#   int var = 3;
+#   i = 1;
+#   var = 5;
+#   i = 2;
+# }
+
 b main
 # CHECK: (lldb) b main
-# CHECK-NEXT: Breakpoint 1: where = {{.*}}`main + 6 at main.c:2:7
+# CHECK-NEXT: Breakpoint 1: where = {{.*}}`main at subprogram_ranges.c:4:5
+
+image lookup -v -s main
+# CHECK: 1 symbols match 'main'
+# CHECK:  Variable: {{.*}}, name = "var", type = "int", {{.*}}, decl = subprogram_ranges.c:3
Index: lldb/test/Shell/SymbolFile/DWARF/Inputs/subprogram_ranges.s
===
--- lldb/test/Shell/SymbolFile/DWARF/Inputs/subprogram_ranges.s
+++ lldb/test/Shell/SymbolFile/DWARF/Inputs/subprogram_ranges.s
@@ -1,32 +1,53 @@
 	.text
-	.file	"main.c"
+	.file	"subprogram_ranges.c"
 	.globl	main# -- Begin function main
 	.p2align	4, 0x90
 	.type	main,@function
 main:   # @main
 .Lfunc_begin0:
-	.file	1 "/usr/local/google/home/blaikie/dev/scratch" "main.c"
-	.loc	1 1 0   # main.c:1:0
+	.file	1 "/usr/local/google/home/blaikie/dev/scratch" "subprogram_ranges.c"
+	.loc	1 2 0   # subprogram_ranges.c:2:0
 	.cfi_startproc
 # %bb.0:# %entry
-	pushq	%rbp
-	.cfi_def_cfa_offset 16
-	.cfi_offset %rbp, -16
-	movq	%rsp, %rbp
-	.cfi_def_cfa_register %rbp
-	xorl	%eax, %eax
+	#DEBUG_VALUE: main:var <- 3
+	.loc	1 4 5 prologue_end  # subprogram_ranges.c:4:5
+	movl	$1, i(%rip)
 .Ltmp0:
-	.loc	1 2 7 prologue_end  # main.c:2:7
-	movl	$3, -4(%rbp)
-	.loc	1 3 1   # main.c:3:1
-	popq	%rbp
-	.cfi_def_cfa %rsp, 8
+	#DEBUG_VALUE: main:var <- 5
+	.loc	1 6 5   # subprogram_ranges.c:6:5
+	movl	$2, i(%rip)
+	.loc	1 7 1   # subprogram_ranges.c:7:1
+	xorl	%eax, %eax
 	retq
 .Ltmp1:
 .Lfunc_end0:
 	.size	main, .Lfunc_end0-main
 	.cfi_endproc
 # -- End function
+	.type	i,@object   # @i
+	.bss
+	.globl	i
+	.p2align	2
+i:
+	.long	0   # 0x0
+	.size	i, 4
+
+	.section	.debug_loc,"",@progbits
+.Ldebug_loc0:
+	.quad	.Lfunc_begin0-.Lfunc_begin0
+	.quad	.Ltmp0-.Lfunc_begin0
+	.short	3   # Loc expr size
+	.byte	17  # DW_OP_consts
+	.byte	3   # 3
+	.byte	159 # DW_OP_stack_value
+	.quad	.Ltmp0-.Lfunc_begin0
+	.quad	.Lfunc_end0-.Lfunc_begin0
+	.short	3   # Loc expr size
+	.byte	17  # DW_OP_consts
+	.byte	5   # 5
+	.byte	159 # DW_OP_stack_value
+	.quad	0
+	.quad	0
 	.section	.debug_abbrev,"",@progbits
 	.byte	1   # Abbreviation Code
 	.byte	17  # DW_TAG_compile_unit
@@ -54,6 +75,8 @@
 	.byte	23  # DW_FORM_sec_offset
 	.byte	64  # DW_AT_frame_base
 	.byte	24  # DW_FORM_exprloc
+	.ascii	"\227B" # DW_AT_GNU_all_call_sites
+	.byte	25  # DW_FORM_flag_present
 	.byte	3   # DW_AT_name
 	.byte	14  # DW_FORM_strp
 	.byte	58  # DW_AT_decl_file
@@ -70,7 +93,7 @@
 	.byte	52  # DW_TAG_variable
 	.byte	0   # DW_CHILDREN_no
 	.byte	2   # DW_AT_location
-	.byte	24  # DW_FORM_exprloc
+	.byte	23  # DW_FO