[lldb-dev] [Bug 17805] LLDB thinks a vector has many more elements than it does
https://llvm.org/bugs/show_bug.cgi?id=17805 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- I've tried the test program and it seems to work as expected with the latest lldb. Feel free to reopen if the problem persists. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 14437] Evaluating expressions that contain function calls is broken on Linux
https://llvm.org/bugs/show_bug.cgi?id=14437 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED Assignee|daniel.ma...@intel.com |lldb-dev@lists.llvm.org --- Comment #4 from lab...@google.com --- This bug has been fixed since it was first filed. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 17808] LLDB fails to find a name that exists in the scope
https://llvm.org/bugs/show_bug.cgi?id=17808 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- This bug should be fixed in latest lldb. Feel free to reopen if the problem persists. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 19478] TestAttachResume.process_attach_continue_interrupt_detach() reports too many breakpoint hits on Linux
https://llvm.org/bugs/show_bug.cgi?id=19478 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |INVALID --- Comment #2 from lab...@google.com --- This is expected behavior, since the breakpoint was hit in multiple threads and the test expectation was fixed to reflect this. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [3.7 Release] 3.7.0-final has been tagged
clang+llvm-3.7.0-mips-linux-gnu.tar.xz All ok clang+llvm-3.7.0-mipsel-linux-gnu.tar.xz All ok clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling to Mips) 22 of 23 test suite runs ok. The 23rd is still running and is ok so far. From: cfe-dev [cfe-dev-boun...@lists.llvm.org] on behalf of Hans Wennborg via cfe-dev [cfe-...@lists.llvm.org] Sent: 28 August 2015 02:46 To: llvm-dev; cfe-...@lists.llvm.org; lldb-dev@lists.llvm.org; openmp-...@lists.llvm.org; Dimitry Andric; Nikola Smiljanić; Sylvestre Ledru; Renato Golin; Ben Pope; Sebastian Dreßler; Pavel Labath; Ed Maste Subject: [cfe-dev] [3.7 Release] 3.7.0-final has been tagged On Wed, Aug 26, 2015 at 4:43 PM, Hans Wennborg wrote: > 3.7.0-rc4 has just been tagged. It is identical to rc3, plus: > > - r245902: Revert r245355: change of clang-tools-extra symlink in the > release script > - r245947: Merge of r245927: Fix LLDB build on MIPS > - r245948: Deprecate the DataLayout on the TargetMachine, and backport > the 3.8 API > - Changes to the ReleaseNotes. > > Those changes should all be safe, and I expect this to be an extremely > short cycle. > > Please build and test. If no new issues arise, I plan to tag this as > 'final' tomorrow or Friday so we can ship the release next week. I have promoted RC4 to final; 3.7.0 has reached its final state. Thanks for all your hard work so far. Please build and upload binaries with "-final", and let's ship this next week! Thanks, Hans ___ cfe-dev mailing list cfe-...@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Where should PROLOGUE_END be set
Ok that clears things up for me.
Thanks Greg.
Aidan
On 31/08/2015 20:50, Greg Clayton wrote:
It is just defined to be where all of the prologue instructions are done
setting up the stack frame for the current function. There is no right answer
in terms of source lines, the compiler can say anything it wants to.
Greg
On Aug 31, 2015, at 4:22 AM, Aidan Dodds via lldb-dev
wrote:
Hello all,
It seems that different LLVM backends (ARM, MIPS, X86) can output a different
line number for PROLOGUE_END in the DWARF line table.
Say I have a function as follows:
1. int my_function( int arg1 )
2. {
3.some_code();
4.
At -O0 I am seeing the PROLOGUE_END set on the function definition (1.,
ARM) and on the first line of code (3., X86, MIPS)
At -03 the ARM backend uses line 3 as its PROLOGUE_END.
Is there a 'correct' place for this to be set, or is expected that this can be
different?
If it is somehow language defined then I am most interested in an answer
related to C99.
Thanks,
Aidan
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [3.7 Release] 3.7.0-final has been tagged
Thanks! Let me know how the last one goes. On Tue, Sep 1, 2015 at 8:16 AM, Daniel Sanders wrote: > clang+llvm-3.7.0-mips-linux-gnu.tar.xz > All ok > > clang+llvm-3.7.0-mipsel-linux-gnu.tar.xz > All ok > > clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling to > Mips) > 22 of 23 test suite runs ok. The 23rd is still running and is ok so far. > > From: cfe-dev [cfe-dev-boun...@lists.llvm.org] on behalf of Hans Wennborg via > cfe-dev [cfe-...@lists.llvm.org] > Sent: 28 August 2015 02:46 > To: llvm-dev; cfe-...@lists.llvm.org; lldb-dev@lists.llvm.org; > openmp-...@lists.llvm.org; Dimitry Andric; Nikola Smiljanić; Sylvestre Ledru; > Renato Golin; Ben Pope; Sebastian Dreßler; Pavel Labath; Ed Maste > Subject: [cfe-dev] [3.7 Release] 3.7.0-final has been tagged > > On Wed, Aug 26, 2015 at 4:43 PM, Hans Wennborg wrote: >> 3.7.0-rc4 has just been tagged. It is identical to rc3, plus: >> >> - r245902: Revert r245355: change of clang-tools-extra symlink in the >> release script >> - r245947: Merge of r245927: Fix LLDB build on MIPS >> - r245948: Deprecate the DataLayout on the TargetMachine, and backport >> the 3.8 API >> - Changes to the ReleaseNotes. >> >> Those changes should all be safe, and I expect this to be an extremely >> short cycle. >> >> Please build and test. If no new issues arise, I plan to tag this as >> 'final' tomorrow or Friday so we can ship the release next week. > > I have promoted RC4 to final; 3.7.0 has reached its final state. > > Thanks for all your hard work so far. Please build and upload binaries > with "-final", and let's ship this next week! > > Thanks, > Hans > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
lldb-dev@lists.llvm.org
> On Aug 31, 2015, at 4:28 PM, Zachary Turner wrote: > > Sounds good. I already have that working in a local patch, but I will wait > for the fix you described earlier to go in first, and handle the merge and > check in the weak_ptr change. > This was in yesterday: Author: gclayton Date: Mon Aug 31 16:25:45 2015 New Revision: 246488 URL: http://llvm.org/viewvc/llvm-project?rev=246488&view=rev Log: Stop objects from keeping a strong reference to the process when they should have a weak reference. Modified: lldb/trunk/source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp lldb/trunk/source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.h lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.h lldb/trunk/source/Plugins/MemoryHistory/asan/MemoryHistoryASan.cpp lldb/trunk/source/Plugins/MemoryHistory/asan/MemoryHistoryASan.h ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [3.7 Release] 3.7.0-final has been tagged
The last one has finished and it was ok too. From: hwennb...@google.com [hwennb...@google.com] on behalf of Hans Wennborg [h...@chromium.org] Sent: 01 September 2015 18:43 To: Daniel Sanders Cc: llvm-dev; cfe-...@lists.llvm.org; lldb-dev@lists.llvm.org; openmp-...@lists.llvm.org; Dimitry Andric; Nikola Smiljanić; Sylvestre Ledru; Renato Golin; Ben Pope; Sebastian Dreßler; Pavel Labath; Ed Maste Subject: Re: [cfe-dev] [3.7 Release] 3.7.0-final has been tagged Thanks! Let me know how the last one goes. On Tue, Sep 1, 2015 at 8:16 AM, Daniel Sanders wrote: > clang+llvm-3.7.0-mips-linux-gnu.tar.xz > All ok > > clang+llvm-3.7.0-mipsel-linux-gnu.tar.xz > All ok > > clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling to > Mips) > 22 of 23 test suite runs ok. The 23rd is still running and is ok so far. > > From: cfe-dev [cfe-dev-boun...@lists.llvm.org] on behalf of Hans Wennborg via > cfe-dev [cfe-...@lists.llvm.org] > Sent: 28 August 2015 02:46 > To: llvm-dev; cfe-...@lists.llvm.org; lldb-dev@lists.llvm.org; > openmp-...@lists.llvm.org; Dimitry Andric; Nikola Smiljanić; Sylvestre Ledru; > Renato Golin; Ben Pope; Sebastian Dreßler; Pavel Labath; Ed Maste > Subject: [cfe-dev] [3.7 Release] 3.7.0-final has been tagged > > On Wed, Aug 26, 2015 at 4:43 PM, Hans Wennborg wrote: >> 3.7.0-rc4 has just been tagged. It is identical to rc3, plus: >> >> - r245902: Revert r245355: change of clang-tools-extra symlink in the >> release script >> - r245947: Merge of r245927: Fix LLDB build on MIPS >> - r245948: Deprecate the DataLayout on the TargetMachine, and backport >> the 3.8 API >> - Changes to the ReleaseNotes. >> >> Those changes should all be safe, and I expect this to be an extremely >> short cycle. >> >> Please build and test. If no new issues arise, I plan to tag this as >> 'final' tomorrow or Friday so we can ship the release next week. > > I have promoted RC4 to final; 3.7.0 has reached its final state. > > Thanks for all your hard work so far. Please build and upload binaries > with "-final", and let's ship this next week! > > Thanks, > Hans > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 24660] New: Thread states not properly maintained on Windows
https://llvm.org/bugs/show_bug.cgi?id=24660 Bug ID: 24660 Summary: Thread states not properly maintained on Windows Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: ztur...@google.com CC: llvm-b...@lists.llvm.org Blocks: 21766 Classification: Unclassified The following tests are failing: TestThreadStates.ThreadStateTestCase.test_state_after_continue_with_dwarf TestThreadStates.ThreadStateTestCase.test_state_after_expression_with_dwarf with the following stack trace: FAIL >>: success Traceback (most recent call last): File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 551, in wrapper return func(self, *args, **kwargs) File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 615, in wrapper func(*args, **kwargs) File "D:\src\llvm\tools\lldb\test\functionalities\thread\state\TestThreadStates.py", line 45, in test_state_after_continue_with_dwarf self.thread_state_after_continue_test() File "D:\src\llvm\tools\lldb\test\functionalities\thread\state\TestThreadStates.py", line 181, in thread_state_after_continue_test self.assertFalse(thread.IsStopped(), "Thread state is \'stopped\' when it should be running.") AssertionError: True is not False : Thread state is 'stopped' when it should be running. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 24663] New: Dynamic values cannot be properly resolved on Windows
https://llvm.org/bugs/show_bug.cgi?id=24663
Bug ID: 24663
Summary: Dynamic values cannot be properly resolved on Windows
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: ztur...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
When you write something like:
class A {};
class B : public A {};
A * a = new B();
and then create a value object out of it and get the type name, we are
returning A* instead of B*. This is the root cause of the following failures,
at minimum:
TestDynamicValue.DynamicValueTestCase.test_get_dynamic_vals_with_dwarf
TestValueMD5Crash.ValueMD5CrashTestCase.test_with_dwarf_and_run_command
--
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] LLVM 3.7 Release
It is my pleasure to announce that LLVM 3.7.0 is now available! Get it here: http://llvm.org/releases/ This release contains the work of the LLVM community over the past six months: full OpenMP 3.1 support (behind a flag), the On Request Compilation (ORC) JIT API, a new backend for Berkeley Packet Filter (BPF), Control Flow Integrity checking, as well as improved optimizations, new Clang warnings, many bug fixes, and more. For details on what's new, see the release notes: http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html http://llvm.org/releases/3.7.0/tools/clang/docs/ReleaseNotes.html Many thanks to everyone who helped with testing, fixing, and getting the release into a good state! Special thanks to the volunteer release builders and testers, without whom this release would not be possible: Dimitry Andric, Sebastian Dreßler, Renato Golin, Pavel Labath, Sylvestre Ledru, Ed Maste, Ben Pope, Daniel Sanders, and Nikola Smiljanić! If you have any questions or comments about this release, please contact the community on the mailing lists. Onwards to 3.8! - Hans LLVM 3.6 Release Announcement: http://lists.llvm.org/pipermail/llvm-announce/2015-February/57.html ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 24668] New: Breakpoints not being resolved correctly
https://llvm.org/bugs/show_bug.cgi?id=24668
Bug ID: 24668
Summary: Breakpoints not being resolved correctly
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: ztur...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
A number of tests which are seemingly unrelated fail because they all rely on
being able to set a breakpoint and then have it resolve dynamically once the
executable is run.
In certain instances, this doesn't work correctly on Windows, leading to output
similar to the following:
runCmd: breakpoint list -f
output: Current breakpoints:
1: file = 'main.cpp', line = 36, exact_match = 0, locations = 1
1.1: where = a.out`void * step_thread_func(void) + 3 at main.cpp:36, address
= a.out[0x00412023], unresolved, hit count = 0
Expecting sub string: 1: file = 'main.cpp', line = 36, locations = 1
Not matched
FAIL
Traceback (most recent call last):
File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 615, in wrapper
func(*args, **kwargs)
File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 615, in wrapper
func(*args, **kwargs)
File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 615, in wrapper
func(*args, **kwargs)
File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 551, in wrapper
return func(self, *args, **kwargs)
File
"D:\src\llvm\tools\lldb\test\functionalities\thread\create_during_step\TestCreateDuringStep.py",
line 46, in test_step_inst_with_dwarf
self.create_during_step_inst_test()
File
"D:\src\llvm\tools\lldb\test\functionalities\thread\create_during_step\TestCreateDuringStep.py",
line 75, in create_during_step_inst_test
self.create_during_step_base("thread step-inst -m all-threads", 'stop
reason = instruction step')
File
"D:\src\llvm\tools\lldb\test\functionalities\thread\create_during_step\TestCreateDuringStep.py",
line 95, in create_during_step_base
substrs = ["1: file = 'main.cpp', line = %d, locations = 1" %
self.breakpoint])
File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 2630, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Breakpoint location shown correctly
As can be seen, the breakpoint is set, but it is unresolved so it has no
breakpoitn locations, causing the test to fail.
This affects (at a minimum) the following set of tests:
TestThreadStates.ThreadStateTestCase.test_process_interrupt_with_dwarf
TestThreadStates.ThreadStateTestCase.test_process_state_with_dwarf
TestCreateDuringStep.CreateDuringStepTestCase.test_step_in_with_dwarf
TestCreateDuringStep.CreateDuringStepTestCase.test_step_inst_with_dwarf
TestCreateDuringStep.CreateDuringStepTestCase.test_step_over_with_dwarf
TestExitDuringBreak.ExitDuringBreakpointTestCase.test_with_dwarf
TestMultipleBreakpoints.MultipleBreakpointTestCase.test_with_dwarf
TestThreadStates.ThreadStateTestCase.test_state_after_breakpoint_with_dwarf
--
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
