Re: [lldb-dev] Deadlock loading DWARF symbols

[Frédéric Riss via lldb-dev]

[I thought I had already sent this out weeks ago…] 

> On Oct 2, 2020, at 2:13 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
> Yes this is bad, and GetDescription() is used as a convenience to print out 
> the module path (which might be a .o file within a .a file) and optionally 
> architecture of the module. It probably shouldn't be taking the module lock 
> as the only member variables that that GetDescription accesses are:
> 
> Module::m_arch
> Module::m_file
> Module::m_object_name
> 
> I would almost vote to take out the mutex lock in GetDescription() as the 
> arch, file and name don't change after the module has been created. I am 
> going to CC a few extra folks for discussion.
> 
> Anyone else have any objections to removing the mutex in GetDescription? 
> Seems like this deadlock is easy to trigger if you have DWARF with errors or 
> warnings inside of it.

I remember having a discussion with Jim about a very similar issue and IIRC, he 
told me that the arch could change after a module is created. I don’t remember 
the reason off the top of my head.

I think we are hitting a very similar deadlock in the Swift REPL for slightly 
different reasons (same lock though).

Fred 

> Greg
> 
> 
>> On Oct 2, 2020, at 6:50 AM, Dmitry Antipov via lldb-dev 
>>  wrote:
>> 
>> I'm observing the following deadlock:
>> 
>> One thread calls Module::PreloadSymbols() which takes m_mutex of this 
>> Module. Module::PreloadSymbols()
>> calls ManualDWARFIndex::Index(), which, in turn, creates thread pool and 
>> waits for all threads completion:
>> 
>> (gdb)
>> #0  futex_wait_cancelable (private=0, expected=0, futex_word=0x7f67f176914c) 
>> at ../sysdeps/nptl/futex-internal.h:183
>> #1  __pthread_cond_wait_common (abstime=0x0, clockid=0, 
>> mutex=0x7f67f17690c8, cond=0x7f67f1769120) at pthread_cond_wait.c:508
>> #2  __pthread_cond_wait (cond=0x7f67f1769120, mutex=0x7f67f17690c8) at 
>> pthread_cond_wait.c:638
>> #3  0x7f67f3974890 in 
>> std::condition_variable::wait(std::unique_lock&) () from 
>> /lib64/libstdc++.so.6
>> #4  0x7f67f4440c4b in 
>> std::condition_variable::wait > 
>> (__p=..., __lock=..., this=0x7f67f1769120)
>>   at /usr/include/c++/10/condition_variable:108
>> #5  llvm::ThreadPool::wait (this=this@entry=0x7f67f1769060) at 
>> source/llvm/lib/Support/ThreadPool.cpp:72
>> #6  0x7f67fc6fa3a6 in lldb_private::ManualDWARFIndex::Index 
>> (this=0x7f66fe87e950)
>>   at source/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp:94
>> #7  0x7f67fc6b3825 in SymbolFileDWARF::PreloadSymbols 
>> (this=0x7f67de7af6f0) at /usr/include/c++/10/bits/unique_ptr.h:421
>> #8  0x7f67fc1ee488 in lldb_private::Module::PreloadSymbols 
>> (this=0x7f67de79b620) at source/lldb/source/Core/Module.cpp:1397
>> #9  0x7f67fc397a37 in lldb_private::Target::GetOrCreateModule 
>> (this=this@entry=0x96c7a0, module_spec=..., notify=notify@entry=true, 
>> error_ptr=error_ptr@entry=0x0)
>>   at /usr/include/c++/10/bits/shared_ptr_base.h:1324
>> ...
>> 
>> OTOH one of pool threads makes an attempt to lock Module's mutex:
>> 
>> (gdb) bt
>> #0  __lll_lock_wait (futex=futex@entry=0x7f67de79b638, private=0) at 
>> lowlevellock.c:52
>> #1  0x7f67fcd907f1 in __GI___pthread_mutex_lock (mutex=0x7f67de79b638) 
>> at ../nptl/pthread_mutex_lock.c:115
>> #2  0x7f67fc1ed922 in __gthread_mutex_lock (__mutex=0x7f67de79b638) at 
>> /usr/include/c++/10/x86_64-redhat-linux/bits/gthr-default.h:749
>> #3  __gthread_recursive_mutex_lock (__mutex=0x7f67de79b638) at 
>> /usr/include/c++/10/x86_64-redhat-linux/bits/gthr-default.h:811
>> #4  std::recursive_mutex::lock (this=0x7f67de79b638) at 
>> /usr/include/c++/10/mutex:106
>> #5  std::lock_guard::lock_guard (__m=..., 
>> this=) at /usr/include/c++/10/bits/std_mutex.h:159
>> #6  lldb_private::Module::GetDescription (this=this@entry=0x7f67de79b620, 
>> s=..., level=level@entry=lldb::eDescriptionLevelBrief)
>>   at source/lldb/source/Core/Module.cpp:1083
>> #7  0x7f67fc1f2070 in lldb_private::Module::ReportError 
>> (this=0x7f67de79b620, format=0x7f67fca03660 "DW_FORM_ref* DIE reference 
>> 0x%lx is outside of its CU")
>>   at source/lldb/include/lldb/Utility/Stream.h:358
>> #8  0x7f67fc6adfb4 in DWARFFormValue::Reference 
>> (this=this@entry=0x7f66f5ff29c0) at 
>> /usr/include/c++/10/bits/shared_ptr_base.h:1324
>> #9  0x7f67fc6aaa77 in DWARFDebugInfoEntry::GetAttributes 
>> (this=this@entry=0x7f662e3580e0, cu=cu@entry=0x7f66ff6ebad0, attributes=...,
>>   recurse=recurse@entry

[lldb-dev] [Bug 47826] New: Cannot attach to a process with exited leader thread (TID==PID)

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47826

Bug ID: 47826
   Summary: Cannot attach to a process with exited leader thread
(TID==PID)
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: jan.kratoch...@redhat.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

There does not need to exist a thread with TID equal to the process PID. That
TID could already exit while other TIDs of that PID may be still running.

https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=432b4d03ad0f23970315e9f9dec080ab4a9ab94b

simplified and deGPLed as: https://people.redhat.com/jkratoch/leader-exit2.C

Currently LLDB server cannot attach to such TID as:
  lldb-server g --attach >TID< :1234
  ptrace(PTRACE_ATTACH, >PID<) = -1 EPERM (Operation not permitted)
  write(2, "error: failed to attach to pid >TID<: Operation not permitted\n",
64) = 64

02295e6d1a1559f0689aeca09d98f468e3f29d9a = 2020-10-12

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 47820] New: Correct vFile:pread/pwrite packet format incompatibility with gdb

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47820

Bug ID: 47820
   Summary: Correct vFile:pread/pwrite packet format
incompatibility with gdb
   Product: lldb
   Version: 11.0
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: david.spick...@linaro.org
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

This is derived from discussion on: https://reviews.llvm.org/D89227

Where I updated the docs to say that vFile:pread/pwrite use different number
formats in gdb and lldb.

The protocol specification requires hex formatted numbers (no mention of 0x
prefix or not)
gdb/gdb-server send/expect to get hex numbers without an 0x prefix
lldb/lldb-server send decimal numbers and expect to get either decimal numbers
or hex with the 0x prefix

Plan to fix this: (from labath's comment)
* Change lldb to send hex with 0x prefix, wait a while
* Change lldb-server to always expect hex (0x prefix or otherwise), wait again
* Change lldb to send hex *without* the 0x prefix

Which gets us to matching gdb.

Waiting some time allows us to keep some compatibility going between old
clients and new servers. I'm interpreting this to mean wait a release between
each one.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM 11.0.0 Release

[Hans Wennborg via lldb-dev]

I am pleased to announce that LLVM 11 is now finally available.

Get it here: https://releases.llvm.org/download.html#11.0.0

This release is the result of the LLVM community's efforts over the
past six months (up to 2e10b7a3 on trunk plus commits up to 176249bd
on the release/11.x branch).

One highlight is that the Flang Fortran frontend is now part of the release.

And as usual, there are many bug fixes, optimizations, new compiler
diagnostics, etc.

For details, see the release notes:

https://releases.llvm.org/11.0.0/docs/ReleaseNotes.html
https://releases.llvm.org/11.0.0/tools/clang/docs/ReleaseNotes.html
https://releases.llvm.org/11.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html
https://releases.llvm.org/11.0.0/tools/flang/docs/ReleaseNotes.html
https://releases.llvm.org/11.0.0/tools/lld/docs/ReleaseNotes.html
https://releases.llvm.org/11.0.0/tools/polly/docs/ReleaseNotes.html
https://releases.llvm.org/11.0.0/projects/libcxx/docs/ReleaseNotes.html

The release would not be possible without the help of everyone who
reported, investigated and fixed bugs, pointed out patches that needed
merging, wrote release notes, etc. Thank you!

Special thanks to the release testers and packagers: Ahsan Saghir, Amy
Kwan, Andrew Kelley, Bernhard Rosenkraenzer, Brian Cain, Diana Picus,
Dimitry Andric, Florian Hahn, Martin Storjö, Michał Górny, Neil
Nelson, Nikita Popov, Rainer Orth, Shoaib Meenai, Sylvestre Ledru, and
Tobias Hieta!

For questions or comments about the release, please contact the
community on the mailing lists.

Onwards to LLVM 12! And take care.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] [11.0.0 Release] Release Candidate 6 is here

[Diana Picus via lldb-dev]

Hi,

Uploaded Arm & AArch64:
95449841c1c4b0164414e58b1053a3877e3bd73d9b1b3e15e5d1d4c2fd5cae1e
clang+llvm-11.0.0-rc6-aarch64-linux-gnu.tar.xz
40ba7c35c5430cc2775b8dbf0bc4687d7a466c29332b89193de903ea4557fb05
clang+llvm-11.0.0-rc6-armv7a-linux-gnueabihf.tar.xz

Same as previous rc's.

Cheers,
Diana

On Sat, 10 Oct 2020 at 04:46, Shoaib Meenai via cfe-dev
 wrote:
>
> Uploaded macOS binaries to 
> https://drive.google.com/file/d/1OVsImFG99a0jNOWc1IDhRvER3CvbGmFp/view?usp=sharing.
>
> The SHA-256 is:
>
> b35f3b6ce4de703f015bdf9d936f530b28c752737c2dd60715bd3d098787652b  
> clang+llvm-11.0.0-rc6-x86_64-apple-darwin.tar.xz
>
> The full test results are:
>
> Failed Tests (2):
>   libunwind :: libunwind_01.pass.cpp
>   libunwind :: signal_frame.pass.cpp
>
> Testing Time: 3211.12s
>   Unsupported  :  3200
>   Passed   : 68254
>   Expectedly Failed:   264
>   Failed   : 2
>
> The libunwind tests failed with rc5 and also fail for 10.0.1 on my machine, 
> so it's likely an environmental issue. (See 
> https://lists.llvm.org/pipermail/llvm-dev/2020-October/145513.html for my 
> previous investigation into the libunwind failures, where we determined they 
> shouldn't be launch-blocking.)
>
> (It might be easier to give me SFTP access, to save Tobias the trouble of 
> having to download and reupload to the SFTP.)
>
> On 10/7/20, 7:40 AM, "llvm-dev on behalf of Hans Wennborg via llvm-dev" 
>  wrote:
>
> Hello once again,
>
> A few more issues appeared, so here is yet another release candidate:
> llvmorg-11.0.0-rc6 was just tagged.
>
> Source code and docs are available at
> https://prereleases.llvm.org/11.0.0/#rc6
> and
> https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc6
>
> Pre-built binaries will be added as they become ready.
>
> Please file reports for any bugs you find as blockers of
> https://llvm.org/pr46725
>
> Release testers, if you still have cycles, please take this for a
> quick spin. The changes from rc5 are minimal, and hopefully we can tag
> this as the final version very soon now.
>
> Thanks,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [11.0.0 Release] Release Candidate 6 is here

[Dimitry Andric via lldb-dev]

On 7 Oct 2020, at 16:40, Hans Wennborg via Release-testers 
 wrote:
> 
> A few more issues appeared, so here is yet another release candidate:
> llvmorg-11.0.0-rc6 was just tagged.

I've built rc6, and again this did not need any patches.

Main results on amd64-freebsd11:

  Unsupported:  5122 (rc4:  5122)
  Passed : 69762 (rc4: 69761)
  Expectedly Failed  :   245 (rc4:   245)
  Timed Out  :16 (rc4:16)
  Failed :   482 (rc4:   481)
  Unexpectedly Passed: 2 (rc4: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc5: 2399)
  Failed:3 (rc5:3)

Main results on i386-freebsd11:

  Unsupported:  3513 (rc4:  3513)
  Passed : 66638 (rc4: 66637)
  Expectedly Failed  :   230 (rc4:   230)
  Timed Out  : 7 (rc4: 7)
  Failed :   322 (rc4:   321)
  Unexpectedly Passed: 1 (rc4: 1)

Uploaded:
SHA256 (clang+llvm-11.0.0-rc6-amd64-unknown-freebsd11.tar.xz) = 
c2c9840e7329d77d9655f5b576bc441db254622ea9c1845d3f3846b75f7220f6
SHA256 (clang+llvm-11.0.0-rc6-i386-unknown-freebsd11.tar.xz) = 
aa949a4978f6aa33b678b0887c74bfaf954080b8d0b210b458759599fb108903

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

[Jason Molenda via lldb-dev]

> On Oct 8, 2020, at 10:37 PM, Greg Clayton  wrote:
> 
> 
> 
>> On Oct 8, 2020, at 10:29 PM, Jason Molenda  wrote:
>> 
>> 
>> 
>>> On Oct 8, 2020, at 10:06 PM, Jason Molenda  wrote:
>>> 
>>> 
>>> 
 On Oct 8, 2020, at 9:17 PM, Greg Clayton  wrote:
 
 
 
> On Oct 8, 2020, at 8:55 PM, Jason Molenda  wrote:
> 
> Good bug find!
> 
> It seems to me that DWARFCallFrameInfo should push the initial CIE 
> register setup instructions as being the state at offset 0 in the 
> function (in fact I'd say it's a bug if it's not). If that were done, 
> then getting RowAtIndex(0) should be synonymous with 
> get-the-CIE-register-unwind-rules, and this code would be correct.
> 
> Looking at DWARFCallFrameInfo::FDEToUnwindPlan, we do
> 
> unwind_plan.SetPlanValidAddressRange(range);
> UnwindPlan::Row *cie_initial_row = new UnwindPlan::Row;
> *cie_initial_row = cie->initial_row;
> UnwindPlan::RowSP row(cie_initial_row);
> 
> unwind_plan.SetRegisterKind(GetRegisterKind());
> unwind_plan.SetReturnAddressRegister(cie->return_addr_reg_num);
> 
> cie->initial_row is set by DWARFCallFrameInfo::HandleCommonDwarfOpcode.
> 
> I think the bug here is DWARFCallFrameInfo::FDEToUnwindPlan not pushing 
> that initial row at offset 0, isn't it? We don't really use DWARF CFI on 
> darwin any more so I don't have a lot of real world experience here.
 
 The only opcodes that push a row are DW_CFA_advance_locXXX and 
 DW_CFA_set_loc, so I don't think that is the right fix. I think we need to 
 pass a copy of just the registers from the "cie->initial_row" object 
 around to the opcode parsing code for restoration purposes.
>>> 
>>> 
>>> I think everything I'm saying here is besides the point, though.  Unless we 
>>> ALWAYS push the initial unwind state (from the CIE) to an UnwindPlan, the 
>>> DW_CFA_restore is not going to work.  If an unwind rule for r12 says 
>>> "DW_CFA_restore" and at offset 0 in the function, the unwind rule for r12 
>>> was "same" (i.e. no rule), but we return the RowAtIndex(0) and the first 
>>> instruction, I don't know, spills it or something, then the DW_CFA_restore 
>>> would set the r12 rule to "r12 was spilled" instead of "r12 is same".
>>> 
>>> So the only way DW_CFA_restore would behave correctly, with this, is if we 
>>> always push a Row at offset 0 with the rules from the CIE, or with no rules 
>>> at all, just the initial unwind state showing how the CFA is set and no 
>>> register rules.
>> 
>> 
>> 
>> just to be clear, though, my initial reaction to this bug is "we should 
>> always push a row at offset 0."  I don't want to sound dumb or anything, but 
>> I don't understand how unwinding would work if we didn't have a Row at 
>> offset 0.  You step into the function, you're at the first instruction, you 
>> want to find the caller stack frame, and without knowing the rule for 
>> establishing the CFA and finding the saved pc, I don't know how you get 
>> that.  And the only way to get the CFA / saved pc rule is to get the Row.  
>> Do we really not have a Row at offset 0 when an UnwindPlan is created from 
>> CFI?  I might be forgetting some trick of UnwindPlans, but I don't see how 
>> it works.
> 
> What you are saying makes sense, but that isn't how it is encoded. A quick 
> example:
> 
>  0010  CIE
>   Version:   4
>   Augmentation:  ""
>   Address size:  4
>   Segment desc size: 0
>   Code alignment factor: 1
>   Data alignment factor: -4
>   Return address column: 14
> 
>   DW_CFA_def_cfa: reg13 +0
>   DW_CFA_nop:
>   DW_CFA_nop:
> 
> 0014 0024  FDE cie= pc=0001bb2c...0001bc90
>   DW_CFA_advance_loc: 4
>   DW_CFA_def_cfa_offset: +32
>   DW_CFA_offset: reg14 -4
>   DW_CFA_offset: reg10 -8
>   DW_CFA_offset: reg9 -12
>   DW_CFA_offset: reg8 -16
>   DW_CFA_offset: reg7 -20
>   DW_CFA_offset: reg6 -24
>   DW_CFA_offset: reg5 -28
>   DW_CFA_offset: reg4 -32
>   DW_CFA_advance_loc: 2
>   DW_CFA_def_cfa_offset: +112
>   DW_CFA_nop:
>   DW_CFA_nop:
> 
> 
> DW_CFA_advance_loc is what pushes a row. As you can see in the FDE, it is the 
> first thing it does.


Ah, cool, thanks for the example CFI.  I believe 
DWARFCallFrameInfo::FDEToUnwindPlan is doing the right thing here.  We start by 
initializing the local variable 'row' to the CIE's initial register state:

  UnwindPlan::Row *cie_initial_row = new UnwindPlan::Row;
  *cie_initial_row = cie->initial_row;
  UnwindPlan::RowSP row(cie_initial_row);

The first instruction we hit is the advance loc,

  if (primary_opcode) {
switch (primary_opcode) {
case DW_CFA_advance_loc: // (Row Creation Instruction)
  unwind_plan.AppendRow(row);
  UnwindPlan::Row *newrow = new UnwindPlan::Row;
  *newrow = *row.get();
  row.reset(newrow);
  row->SlideOffset(extended_opcode * code_align);
  break;

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

[Greg Clayton via lldb-dev]

> On Oct 8, 2020, at 10:29 PM, Jason Molenda  wrote:
> 
> 
> 
>> On Oct 8, 2020, at 10:06 PM, Jason Molenda  wrote:
>> 
>> 
>> 
>>> On Oct 8, 2020, at 9:17 PM, Greg Clayton  wrote:
>>> 
>>> 
>>> 
 On Oct 8, 2020, at 8:55 PM, Jason Molenda  wrote:
 
 Good bug find!
 
 It seems to me that DWARFCallFrameInfo should push the initial CIE 
 register setup instructions as being the state at offset 0 in the function 
 (in fact I'd say it's a bug if it's not). If that were done, then getting 
 RowAtIndex(0) should be synonymous with get-the-CIE-register-unwind-rules, 
 and this code would be correct.
 
 Looking at DWARFCallFrameInfo::FDEToUnwindPlan, we do
 
 unwind_plan.SetPlanValidAddressRange(range);
 UnwindPlan::Row *cie_initial_row = new UnwindPlan::Row;
 *cie_initial_row = cie->initial_row;
 UnwindPlan::RowSP row(cie_initial_row);
 
 unwind_plan.SetRegisterKind(GetRegisterKind());
 unwind_plan.SetReturnAddressRegister(cie->return_addr_reg_num);
 
 cie->initial_row is set by DWARFCallFrameInfo::HandleCommonDwarfOpcode.
 
 I think the bug here is DWARFCallFrameInfo::FDEToUnwindPlan not pushing 
 that initial row at offset 0, isn't it? We don't really use DWARF CFI on 
 darwin any more so I don't have a lot of real world experience here.
>>> 
>>> The only opcodes that push a row are DW_CFA_advance_locXXX and 
>>> DW_CFA_set_loc, so I don't think that is the right fix. I think we need to 
>>> pass a copy of just the registers from the "cie->initial_row" object around 
>>> to the opcode parsing code for restoration purposes.
>> 
>> 
>> I think everything I'm saying here is besides the point, though.  Unless we 
>> ALWAYS push the initial unwind state (from the CIE) to an UnwindPlan, the 
>> DW_CFA_restore is not going to work.  If an unwind rule for r12 says 
>> "DW_CFA_restore" and at offset 0 in the function, the unwind rule for r12 
>> was "same" (i.e. no rule), but we return the RowAtIndex(0) and the first 
>> instruction, I don't know, spills it or something, then the DW_CFA_restore 
>> would set the r12 rule to "r12 was spilled" instead of "r12 is same".
>> 
>> So the only way DW_CFA_restore would behave correctly, with this, is if we 
>> always push a Row at offset 0 with the rules from the CIE, or with no rules 
>> at all, just the initial unwind state showing how the CFA is set and no 
>> register rules.
> 
> 
> 
> just to be clear, though, my initial reaction to this bug is "we should 
> always push a row at offset 0."  I don't want to sound dumb or anything, but 
> I don't understand how unwinding would work if we didn't have a Row at offset 
> 0.  You step into the function, you're at the first instruction, you want to 
> find the caller stack frame, and without knowing the rule for establishing 
> the CFA and finding the saved pc, I don't know how you get that.  And the 
> only way to get the CFA / saved pc rule is to get the Row.  Do we really not 
> have a Row at offset 0 when an UnwindPlan is created from CFI?  I might be 
> forgetting some trick of UnwindPlans, but I don't see how it works.

What you are saying makes sense, but that isn't how it is encoded. A quick 
example:

 0010  CIE
  Version:   4
  Augmentation:  ""
  Address size:  4
  Segment desc size: 0
  Code alignment factor: 1
  Data alignment factor: -4
  Return address column: 14

  DW_CFA_def_cfa: reg13 +0
  DW_CFA_nop:
  DW_CFA_nop:

0014 0024  FDE cie= pc=0001bb2c...0001bc90
  DW_CFA_advance_loc: 4
  DW_CFA_def_cfa_offset: +32
  DW_CFA_offset: reg14 -4
  DW_CFA_offset: reg10 -8
  DW_CFA_offset: reg9 -12
  DW_CFA_offset: reg8 -16
  DW_CFA_offset: reg7 -20
  DW_CFA_offset: reg6 -24
  DW_CFA_offset: reg5 -28
  DW_CFA_offset: reg4 -32
  DW_CFA_advance_loc: 2
  DW_CFA_def_cfa_offset: +112
  DW_CFA_nop:
  DW_CFA_nop:


DW_CFA_advance_loc is what pushes a row. As you can see in the FDE, it is the 
first thing it does. If we were to always push a row after parsing the CIE 
instructions, then we would end up with two rows at the address for the FDE. 
The reason we need the FDE is to fill in a valid address for the CIE 
instructions into the row _before_ pushing it. So the CIE  instructions don't 
make any sense without the FDE making it make sense. So as I originally stated: 
it probably won't affect us since this almost always happens, but if I have 
learned anything from years of parsing info compilers emit: if they can do it, 
they will. So the FDE _could_ modify more register values on top of the CIE 
instructions before pushing a row...



> 
> 
>> 
>> 
>>> 
>>> 
 
 
 
> On Oct 8, 2020, at 4:01 PM, Greg Clayton  wrote:
> 
> Hello LLDB devs,
> 
> This is a deep dive into an issue I found in the LLDB handling of DWARF 
> call frame information, so no need to read further if this doesn't 
> interest you!
> 
> I am 

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

[Jason Molenda via lldb-dev]

> On Oct 8, 2020, at 10:06 PM, Jason Molenda  wrote:
> 
> 
> 
>> On Oct 8, 2020, at 9:17 PM, Greg Clayton  wrote:
>> 
>> 
>> 
>>> On Oct 8, 2020, at 8:55 PM, Jason Molenda  wrote:
>>> 
>>> Good bug find!
>>> 
>>> It seems to me that DWARFCallFrameInfo should push the initial CIE register 
>>> setup instructions as being the state at offset 0 in the function (in fact 
>>> I'd say it's a bug if it's not). If that were done, then getting 
>>> RowAtIndex(0) should be synonymous with get-the-CIE-register-unwind-rules, 
>>> and this code would be correct.
>>> 
>>> Looking at DWARFCallFrameInfo::FDEToUnwindPlan, we do
>>> 
>>> unwind_plan.SetPlanValidAddressRange(range);
>>> UnwindPlan::Row *cie_initial_row = new UnwindPlan::Row;
>>> *cie_initial_row = cie->initial_row;
>>> UnwindPlan::RowSP row(cie_initial_row);
>>> 
>>> unwind_plan.SetRegisterKind(GetRegisterKind());
>>> unwind_plan.SetReturnAddressRegister(cie->return_addr_reg_num);
>>> 
>>> cie->initial_row is set by DWARFCallFrameInfo::HandleCommonDwarfOpcode.
>>> 
>>> I think the bug here is DWARFCallFrameInfo::FDEToUnwindPlan not pushing 
>>> that initial row at offset 0, isn't it? We don't really use DWARF CFI on 
>>> darwin any more so I don't have a lot of real world experience here.
>> 
>> The only opcodes that push a row are DW_CFA_advance_locXXX and 
>> DW_CFA_set_loc, so I don't think that is the right fix. I think we need to 
>> pass a copy of just the registers from the "cie->initial_row" object around 
>> to the opcode parsing code for restoration purposes.
> 
> 
> I think everything I'm saying here is besides the point, though.  Unless we 
> ALWAYS push the initial unwind state (from the CIE) to an UnwindPlan, the 
> DW_CFA_restore is not going to work.  If an unwind rule for r12 says 
> "DW_CFA_restore" and at offset 0 in the function, the unwind rule for r12 was 
> "same" (i.e. no rule), but we return the RowAtIndex(0) and the first 
> instruction, I don't know, spills it or something, then the DW_CFA_restore 
> would set the r12 rule to "r12 was spilled" instead of "r12 is same".
> 
> So the only way DW_CFA_restore would behave correctly, with this, is if we 
> always push a Row at offset 0 with the rules from the CIE, or with no rules 
> at all, just the initial unwind state showing how the CFA is set and no 
> register rules.



just to be clear, though, my initial reaction to this bug is "we should always 
push a row at offset 0."  I don't want to sound dumb or anything, but I don't 
understand how unwinding would work if we didn't have a Row at offset 0.  You 
step into the function, you're at the first instruction, you want to find the 
caller stack frame, and without knowing the rule for establishing the CFA and 
finding the saved pc, I don't know how you get that.  And the only way to get 
the CFA / saved pc rule is to get the Row.  Do we really not have a Row at 
offset 0 when an UnwindPlan is created from CFI?  I might be forgetting some 
trick of UnwindPlans, but I don't see how it works.


> 
> 
>> 
>> 
>>> 
>>> 
>>> 
 On Oct 8, 2020, at 4:01 PM, Greg Clayton  wrote:
 
 Hello LLDB devs,
 
 This is a deep dive into an issue I found in the LLDB handling of DWARF 
 call frame information, so no need to read further if this doesn't 
 interest you!
 
 I am in the process of adding some support to LLVM for parsing the opcode 
 state machines for CIE and FDE objects that produces unwind rows. While 
 making unit tests to test DW_CFA_restore and DW_CFA_restore_extended 
 opcodes, I read the DWARF spec that states:
 
 "The DW_CFA_restore instruction takes a single operand (encoded with the 
 opcode) that represents a register number. The required action is to 
 change the rule for the indicated register to the rule assigned it by the 
 initial_instructions in the CIE."
 
 Looking at the LLDB code in DWARFCallFrameInfo.cpp I see code that is 
 simplified to:
 
 case DW_CFA_restore:
 if (unwind_plan.IsValidRowIndex(0) && 
   unwind_plan.GetRowAtIndex(0)->GetRegisterInfo(reg_num, reg_location))
   row->SetRegisterInfo(reg_num, reg_location);
 break;
 
 
 The issue is, the CIE contains initial instructions, but it doesn't push a 
 row after doing these instructions, the FDE will push a row when it emits 
 a DW_CFA_advance_loc, DW_CFA_advance_loc1, DW_CFA_advance_loc2, 
 DW_CFA_advance_loc4 or DW_CFA_set_loc opcode. So the DWARF spec says we 
 should restore the register rule to be what it was in the CIE's initial 
 instructions, but we are restoring it to the first row that was parsed. 
 This will mostly not get us into trouble because .debug_frame and 
 .eh_frame usually have a DW_CFA_advance_locXXX or DW_CFA_set_loc opcode as 
 the first opcode, but it isn't a requirement and a FDE could modify a 
 register value prior to pushing the first row at index zero. So we might 
 be 

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

[Jason Molenda via lldb-dev]

> On Oct 8, 2020, at 9:17 PM, Greg Clayton  wrote:
> 
> 
> 
>> On Oct 8, 2020, at 8:55 PM, Jason Molenda  wrote:
>> 
>> Good bug find!
>> 
>> It seems to me that DWARFCallFrameInfo should push the initial CIE register 
>> setup instructions as being the state at offset 0 in the function (in fact 
>> I'd say it's a bug if it's not). If that were done, then getting 
>> RowAtIndex(0) should be synonymous with get-the-CIE-register-unwind-rules, 
>> and this code would be correct.
>> 
>> Looking at DWARFCallFrameInfo::FDEToUnwindPlan, we do
>> 
>> unwind_plan.SetPlanValidAddressRange(range);
>> UnwindPlan::Row *cie_initial_row = new UnwindPlan::Row;
>> *cie_initial_row = cie->initial_row;
>> UnwindPlan::RowSP row(cie_initial_row);
>> 
>> unwind_plan.SetRegisterKind(GetRegisterKind());
>> unwind_plan.SetReturnAddressRegister(cie->return_addr_reg_num);
>> 
>> cie->initial_row is set by DWARFCallFrameInfo::HandleCommonDwarfOpcode.
>> 
>> I think the bug here is DWARFCallFrameInfo::FDEToUnwindPlan not pushing that 
>> initial row at offset 0, isn't it? We don't really use DWARF CFI on darwin 
>> any more so I don't have a lot of real world experience here.
> 
> The only opcodes that push a row are DW_CFA_advance_locXXX and 
> DW_CFA_set_loc, so I don't think that is the right fix. I think we need to 
> pass a copy of just the registers from the "cie->initial_row" object around 
> to the opcode parsing code for restoration purposes.


I think everything I'm saying here is besides the point, though.  Unless we 
ALWAYS push the initial unwind state (from the CIE) to an UnwindPlan, the 
DW_CFA_restore is not going to work.  If an unwind rule for r12 says 
"DW_CFA_restore" and at offset 0 in the function, the unwind rule for r12 was 
"same" (i.e. no rule), but we return the RowAtIndex(0) and the first 
instruction, I don't know, spills it or something, then the DW_CFA_restore 
would set the r12 rule to "r12 was spilled" instead of "r12 is same".

So the only way DW_CFA_restore would behave correctly, with this, is if we 
always push a Row at offset 0 with the rules from the CIE, or with no rules at 
all, just the initial unwind state showing how the CFA is set and no register 
rules.


> 
> 
>> 
>> 
>> 
>>> On Oct 8, 2020, at 4:01 PM, Greg Clayton  wrote:
>>> 
>>> Hello LLDB devs,
>>> 
>>> This is a deep dive into an issue I found in the LLDB handling of DWARF 
>>> call frame information, so no need to read further if this doesn't interest 
>>> you!
>>> 
>>> I am in the process of adding some support to LLVM for parsing the opcode 
>>> state machines for CIE and FDE objects that produces unwind rows. While 
>>> making unit tests to test DW_CFA_restore and DW_CFA_restore_extended 
>>> opcodes, I read the DWARF spec that states:
>>> 
>>> "The DW_CFA_restore instruction takes a single operand (encoded with the 
>>> opcode) that represents a register number. The required action is to change 
>>> the rule for the indicated register to the rule assigned it by the 
>>> initial_instructions in the CIE."
>>> 
>>> Looking at the LLDB code in DWARFCallFrameInfo.cpp I see code that is 
>>> simplified to:
>>> 
>>> case DW_CFA_restore:
>>> if (unwind_plan.IsValidRowIndex(0) && 
>>>unwind_plan.GetRowAtIndex(0)->GetRegisterInfo(reg_num, reg_location))
>>>row->SetRegisterInfo(reg_num, reg_location);
>>> break;
>>> 
>>> 
>>> The issue is, the CIE contains initial instructions, but it doesn't push a 
>>> row after doing these instructions, the FDE will push a row when it emits a 
>>> DW_CFA_advance_loc, DW_CFA_advance_loc1, DW_CFA_advance_loc2, 
>>> DW_CFA_advance_loc4 or DW_CFA_set_loc opcode. So the DWARF spec says we 
>>> should restore the register rule to be what it was in the CIE's initial 
>>> instructions, but we are restoring it to the first row that was parsed. 
>>> This will mostly not get us into trouble because .debug_frame and .eh_frame 
>>> usually have a DW_CFA_advance_locXXX or DW_CFA_set_loc opcode as the first 
>>> opcode, but it isn't a requirement and a FDE could modify a register value 
>>> prior to pushing the first row at index zero. So we might be restoring the 
>>> register incorrectly in some cases according to the spec. Also, what if 
>>> there was no value specified in the CIE's initial instructions for a 
>>> register? Should we remove the register value to match the state of the 
>>> CIE's initial instructions if there is no rule for the register? We are 
>>> currently leaving this register as having the same value if there is no 
>>> value for the register in the first row.
>>> 
>>> Let me know what you think.
>>> 
>>> Greg Clayton
>>> 
>> 
> 

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

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

[Jason Molenda via lldb-dev]

> On Oct 8, 2020, at 9:17 PM, Greg Clayton  wrote:
> 
> 
> 
>> On Oct 8, 2020, at 8:55 PM, Jason Molenda  wrote:
>> 
>> Good bug find!
>> 
>> It seems to me that DWARFCallFrameInfo should push the initial CIE register 
>> setup instructions as being the state at offset 0 in the function (in fact 
>> I'd say it's a bug if it's not). If that were done, then getting 
>> RowAtIndex(0) should be synonymous with get-the-CIE-register-unwind-rules, 
>> and this code would be correct.
>> 
>> Looking at DWARFCallFrameInfo::FDEToUnwindPlan, we do
>> 
>> unwind_plan.SetPlanValidAddressRange(range);
>> UnwindPlan::Row *cie_initial_row = new UnwindPlan::Row;
>> *cie_initial_row = cie->initial_row;
>> UnwindPlan::RowSP row(cie_initial_row);
>> 
>> unwind_plan.SetRegisterKind(GetRegisterKind());
>> unwind_plan.SetReturnAddressRegister(cie->return_addr_reg_num);
>> 
>> cie->initial_row is set by DWARFCallFrameInfo::HandleCommonDwarfOpcode.
>> 
>> I think the bug here is DWARFCallFrameInfo::FDEToUnwindPlan not pushing that 
>> initial row at offset 0, isn't it? We don't really use DWARF CFI on darwin 
>> any more so I don't have a lot of real world experience here.
> 
> The only opcodes that push a row are DW_CFA_advance_locXXX and 
> DW_CFA_set_loc, so I don't think that is the right fix. I think we need to 
> pass a copy of just the registers from the "cie->initial_row" object around 
> to the opcode parsing code for restoration purposes.

The Rows in an UnwindPlan at each function offset describes the register unwind 
rules there.  If the CIE has a register unwind rule, we should push that Row 
for offset 0 in the function.  The function today may only push a Row when the 
pc has been advanced, but that is not (IMO) correct.

I can't think of any register rule like this on arm64 or x86_64.  You could say 
the CFA is $sp+8 at function entry, and the caller's $sp value is CFA+0 (aka 
$sp+8) to reflect the return-pc value that was pushed by the CALLQ.  But I 
don't know if actual CFI on x86_64 includes an SP unwind rule in the CIE like 
this.

> 
> 
>> 
>> 
>> 
>>> On Oct 8, 2020, at 4:01 PM, Greg Clayton  wrote:
>>> 
>>> Hello LLDB devs,
>>> 
>>> This is a deep dive into an issue I found in the LLDB handling of DWARF 
>>> call frame information, so no need to read further if this doesn't interest 
>>> you!
>>> 
>>> I am in the process of adding some support to LLVM for parsing the opcode 
>>> state machines for CIE and FDE objects that produces unwind rows. While 
>>> making unit tests to test DW_CFA_restore and DW_CFA_restore_extended 
>>> opcodes, I read the DWARF spec that states:
>>> 
>>> "The DW_CFA_restore instruction takes a single operand (encoded with the 
>>> opcode) that represents a register number. The required action is to change 
>>> the rule for the indicated register to the rule assigned it by the 
>>> initial_instructions in the CIE."
>>> 
>>> Looking at the LLDB code in DWARFCallFrameInfo.cpp I see code that is 
>>> simplified to:
>>> 
>>> case DW_CFA_restore:
>>> if (unwind_plan.IsValidRowIndex(0) && 
>>>unwind_plan.GetRowAtIndex(0)->GetRegisterInfo(reg_num, reg_location))
>>>row->SetRegisterInfo(reg_num, reg_location);
>>> break;
>>> 
>>> 
>>> The issue is, the CIE contains initial instructions, but it doesn't push a 
>>> row after doing these instructions, the FDE will push a row when it emits a 
>>> DW_CFA_advance_loc, DW_CFA_advance_loc1, DW_CFA_advance_loc2, 
>>> DW_CFA_advance_loc4 or DW_CFA_set_loc opcode. So the DWARF spec says we 
>>> should restore the register rule to be what it was in the CIE's initial 
>>> instructions, but we are restoring it to the first row that was parsed. 
>>> This will mostly not get us into trouble because .debug_frame and .eh_frame 
>>> usually have a DW_CFA_advance_locXXX or DW_CFA_set_loc opcode as the first 
>>> opcode, but it isn't a requirement and a FDE could modify a register value 
>>> prior to pushing the first row at index zero. So we might be restoring the 
>>> register incorrectly in some cases according to the spec. Also, what if 
>>> there was no value specified in the CIE's initial instructions for a 
>>> register? Should we remove the register value to match the state of the 
>>> CIE's initial instructions if there is no rule for the register? We are 
>>> currently leaving this register as having the same value if there is no 
>>> value for the register in the first row.
>>> 
>>> Let me know what you think.
>>> 
>>> Greg Clayton
>>> 
>> 
> 

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

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

[Greg Clayton via lldb-dev]

> On Oct 8, 2020, at 8:55 PM, Jason Molenda  wrote:
> 
> Good bug find!
> 
> It seems to me that DWARFCallFrameInfo should push the initial CIE register 
> setup instructions as being the state at offset 0 in the function (in fact 
> I'd say it's a bug if it's not). If that were done, then getting 
> RowAtIndex(0) should be synonymous with get-the-CIE-register-unwind-rules, 
> and this code would be correct.
> 
> Looking at DWARFCallFrameInfo::FDEToUnwindPlan, we do
> 
>  unwind_plan.SetPlanValidAddressRange(range);
>  UnwindPlan::Row *cie_initial_row = new UnwindPlan::Row;
>  *cie_initial_row = cie->initial_row;
>  UnwindPlan::RowSP row(cie_initial_row);
> 
>  unwind_plan.SetRegisterKind(GetRegisterKind());
>  unwind_plan.SetReturnAddressRegister(cie->return_addr_reg_num);
> 
> cie->initial_row is set by DWARFCallFrameInfo::HandleCommonDwarfOpcode.
> 
> I think the bug here is DWARFCallFrameInfo::FDEToUnwindPlan not pushing that 
> initial row at offset 0, isn't it? We don't really use DWARF CFI on darwin 
> any more so I don't have a lot of real world experience here.

The only opcodes that push a row are DW_CFA_advance_locXXX and DW_CFA_set_loc, 
so I don't think that is the right fix. I think we need to pass a copy of just 
the registers from the "cie->initial_row" object around to the opcode parsing 
code for restoration purposes.


> 
> 
> 
>> On Oct 8, 2020, at 4:01 PM, Greg Clayton  wrote:
>> 
>> Hello LLDB devs,
>> 
>> This is a deep dive into an issue I found in the LLDB handling of DWARF call 
>> frame information, so no need to read further if this doesn't interest you!
>> 
>> I am in the process of adding some support to LLVM for parsing the opcode 
>> state machines for CIE and FDE objects that produces unwind rows. While 
>> making unit tests to test DW_CFA_restore and DW_CFA_restore_extended 
>> opcodes, I read the DWARF spec that states:
>> 
>> "The DW_CFA_restore instruction takes a single operand (encoded with the 
>> opcode) that represents a register number. The required action is to change 
>> the rule for the indicated register to the rule assigned it by the 
>> initial_instructions in the CIE."
>> 
>> Looking at the LLDB code in DWARFCallFrameInfo.cpp I see code that is 
>> simplified to:
>> 
>> case DW_CFA_restore:
>> if (unwind_plan.IsValidRowIndex(0) && 
>> unwind_plan.GetRowAtIndex(0)->GetRegisterInfo(reg_num, reg_location))
>> row->SetRegisterInfo(reg_num, reg_location);
>> break;
>> 
>> 
>> The issue is, the CIE contains initial instructions, but it doesn't push a 
>> row after doing these instructions, the FDE will push a row when it emits a 
>> DW_CFA_advance_loc, DW_CFA_advance_loc1, DW_CFA_advance_loc2, 
>> DW_CFA_advance_loc4 or DW_CFA_set_loc opcode. So the DWARF spec says we 
>> should restore the register rule to be what it was in the CIE's initial 
>> instructions, but we are restoring it to the first row that was parsed. This 
>> will mostly not get us into trouble because .debug_frame and .eh_frame 
>> usually have a DW_CFA_advance_locXXX or DW_CFA_set_loc opcode as the first 
>> opcode, but it isn't a requirement and a FDE could modify a register value 
>> prior to pushing the first row at index zero. So we might be restoring the 
>> register incorrectly in some cases according to the spec. Also, what if 
>> there was no value specified in the CIE's initial instructions for a 
>> register? Should we remove the register value to match the state of the 
>> CIE's initial instructions if there is no rule for the register? We are 
>> currently leaving this register as having the same value if there is no 
>> value for the register in the first row.
>> 
>> Let me know what you think.
>> 
>> Greg Clayton
>> 
> 

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

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

[Jason Molenda via lldb-dev]

Good bug find!

It seems to me that DWARFCallFrameInfo should push the initial CIE register 
setup instructions as being the state at offset 0 in the function (in fact I'd 
say it's a bug if it's not). If that were done, then getting RowAtIndex(0) 
should be synonymous with get-the-CIE-register-unwind-rules, and this code 
would be correct.

Looking at DWARFCallFrameInfo::FDEToUnwindPlan, we do

  unwind_plan.SetPlanValidAddressRange(range);
  UnwindPlan::Row *cie_initial_row = new UnwindPlan::Row;
  *cie_initial_row = cie->initial_row;
  UnwindPlan::RowSP row(cie_initial_row);

  unwind_plan.SetRegisterKind(GetRegisterKind());
  unwind_plan.SetReturnAddressRegister(cie->return_addr_reg_num);

cie->initial_row is set by DWARFCallFrameInfo::HandleCommonDwarfOpcode.

I think the bug here is DWARFCallFrameInfo::FDEToUnwindPlan not pushing that 
initial row at offset 0, isn't it? We don't really use DWARF CFI on darwin any 
more so I don't have a lot of real world experience here.



> On Oct 8, 2020, at 4:01 PM, Greg Clayton  wrote:
> 
> Hello LLDB devs,
> 
> This is a deep dive into an issue I found in the LLDB handling of DWARF call 
> frame information, so no need to read further if this doesn't interest you!
> 
> I am in the process of adding some support to LLVM for parsing the opcode 
> state machines for CIE and FDE objects that produces unwind rows. While 
> making unit tests to test DW_CFA_restore and DW_CFA_restore_extended opcodes, 
> I read the DWARF spec that states:
> 
> "The DW_CFA_restore instruction takes a single operand (encoded with the 
> opcode) that represents a register number. The required action is to change 
> the rule for the indicated register to the rule assigned it by the 
> initial_instructions in the CIE."
> 
> Looking at the LLDB code in DWARFCallFrameInfo.cpp I see code that is 
> simplified to:
> 
> case DW_CFA_restore:
>  if (unwind_plan.IsValidRowIndex(0) && 
>  unwind_plan.GetRowAtIndex(0)->GetRegisterInfo(reg_num, reg_location))
>  row->SetRegisterInfo(reg_num, reg_location);
>  break;
> 
> 
> The issue is, the CIE contains initial instructions, but it doesn't push a 
> row after doing these instructions, the FDE will push a row when it emits a 
> DW_CFA_advance_loc, DW_CFA_advance_loc1, DW_CFA_advance_loc2, 
> DW_CFA_advance_loc4 or DW_CFA_set_loc opcode. So the DWARF spec says we 
> should restore the register rule to be what it was in the CIE's initial 
> instructions, but we are restoring it to the first row that was parsed. This 
> will mostly not get us into trouble because .debug_frame and .eh_frame 
> usually have a DW_CFA_advance_locXXX or DW_CFA_set_loc opcode as the first 
> opcode, but it isn't a requirement and a FDE could modify a register value 
> prior to pushing the first row at index zero. So we might be restoring the 
> register incorrectly in some cases according to the spec. Also, what if there 
> was no value specified in the CIE's initial instructions for a register? 
> Should we remove the register value to match the state of the CIE's initial 
> instructions if there is no rule for the register? We are currently leaving 
> this register as having the same value if there is no value for the register 
> in the first row.
> 
> Let me know what you think.
> 
> Greg Clayton
> 

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

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

[Fangrui Song via lldb-dev]

On 2020-10-08, Greg Clayton via lldb-dev wrote:

Hello LLDB devs,

This is a deep dive into an issue I found in the LLDB handling of DWARF call 
frame information, so no need to read further if this doesn't interest you!

I am in the process of adding some support to LLVM for parsing the opcode state 
machines for CIE and FDE objects that produces unwind rows. While making unit 
tests to test DW_CFA_restore and DW_CFA_restore_extended opcodes, I read the 
DWARF spec that states:

"The DW_CFA_restore instruction takes a single operand (encoded with the opcode) 
that represents a register number. The required action is to change the rule for the 
indicated register to the rule assigned it by the initial_instructions in the CIE."

Looking at the LLDB code in DWARFCallFrameInfo.cpp I see code that is 
simplified to:

case DW_CFA_restore:
 if (unwind_plan.IsValidRowIndex(0) &&
 unwind_plan.GetRowAtIndex(0)->GetRegisterInfo(reg_num, reg_location))
 row->SetRegisterInfo(reg_num, reg_location);
 break;


The issue is, the CIE contains initial instructions, but it doesn't push a row 
after doing these instructions, the FDE will push a row when it emits a 
DW_CFA_advance_loc, DW_CFA_advance_loc1, DW_CFA_advance_loc2, 
DW_CFA_advance_loc4 or DW_CFA_set_loc opcode. So the DWARF spec says we should 
restore the register rule to be what it was in the CIE's initial instructions, 
but we are restoring it to the first row that was parsed. This will mostly not 
get us into trouble because .debug_frame and .eh_frame usually have a 
DW_CFA_advance_locXXX or DW_CFA_set_loc opcode as the first opcode, but it 
isn't a requirement and a FDE could modify a register value prior to pushing 
the first row at index zero. So we might be restoring the register incorrectly 
in some cases according to the spec. Also, what if there was no value specified 
in the CIE's initial instructions for a register? Should we remove the register 
value to match the state of the CIE's initial instructions if there is no rule 
for the register? We are currently leaving this register as having the same 
value if there is no value for the register in the first row.

Let me know what you think.

Greg Clayton


Thanks for noticing this. This is indeed a bug.

nongnu.org libunwind is correct:
http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=blob;f=src/dwarf/Gparser.c;h=da170d4b35fe3d5ac86a81bec8bb9a08939e010d;hb=HEAD#l523

llvm libunwind (DwarfParser.hpp) makes an approximation by only tracking
the first instruction setting up a register (it works in practice
because initial instructions don't use multiple setup instructions on one 
register)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

[Greg Clayton via lldb-dev]

Hello LLDB devs,

This is a deep dive into an issue I found in the LLDB handling of DWARF call 
frame information, so no need to read further if this doesn't interest you!

I am in the process of adding some support to LLVM for parsing the opcode state 
machines for CIE and FDE objects that produces unwind rows. While making unit 
tests to test DW_CFA_restore and DW_CFA_restore_extended opcodes, I read the 
DWARF spec that states:

"The DW_CFA_restore instruction takes a single operand (encoded with the 
opcode) that represents a register number. The required action is to change the 
rule for the indicated register to the rule assigned it by the 
initial_instructions in the CIE."

Looking at the LLDB code in DWARFCallFrameInfo.cpp I see code that is 
simplified to:

case DW_CFA_restore:
  if (unwind_plan.IsValidRowIndex(0) && 
  unwind_plan.GetRowAtIndex(0)->GetRegisterInfo(reg_num, reg_location))
  row->SetRegisterInfo(reg_num, reg_location);
  break;


The issue is, the CIE contains initial instructions, but it doesn't push a row 
after doing these instructions, the FDE will push a row when it emits a 
DW_CFA_advance_loc, DW_CFA_advance_loc1, DW_CFA_advance_loc2, 
DW_CFA_advance_loc4 or DW_CFA_set_loc opcode. So the DWARF spec says we should 
restore the register rule to be what it was in the CIE's initial instructions, 
but we are restoring it to the first row that was parsed. This will mostly not 
get us into trouble because .debug_frame and .eh_frame usually have a 
DW_CFA_advance_locXXX or DW_CFA_set_loc opcode as the first opcode, but it 
isn't a requirement and a FDE could modify a register value prior to pushing 
the first row at index zero. So we might be restoring the register incorrectly 
in some cases according to the spec. Also, what if there was no value specified 
in the CIE's initial instructions for a register? Should we remove the register 
value to match the state of the CIE's initial instructions if there is no rule 
for the register? We are currently leaving this register as having the same 
value if there is no value for the register in the first row.

Let me know what you think.

Greg Clayton

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

[lldb-dev] [Bug 47766] New: String formatter regex wrongly catching multi-dimensional types as well.

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47766

Bug ID: 47766
   Summary: String formatter regex wrongly catching
multi-dimensional types as well.
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: chi...@raincode.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

For a simple C program,
struct b {
char i[2][4];
};

int main() {
struct b z;
z.i[0][0] = 'F';
z.i[0][1] = 'O';
z.i[0][2] = 'O';
z.i[0][3] = 0;
z.i[1][0] = 'B';
z.i[1][1] = 'A';
z.i[1][2] = 'R';
z.i[1][3] = 0;
return 0;
}

while printing variable z, the type summary finder finds the summary provider
because it matches the regex "char [[0-9]+]" while looking for char [2][4] and
failing while printing due to not knowing how to handle the datatype.

(As per conversation on lldb-dev mail thread)The regex should be "char
[[0-9]+]$" with string terminator anchor to start matching at end to avoid
trying to print multi-dimensional data.


LLDB

currently,
(lldb) target create "/home/chirag/a.out"
Current executable set to '/home/chirag/a.out' (x86_64).
(lldb) b 15
Breakpoint 1: where = a.out`main + 36 at struct.c:15, address =
0x00400511
(lldb) r
Process 57100 launched: '/home/chirag/a.out' (x86_64)
Process 57100 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00400511 a.out`main at struct.c:15
   12   z.i[1][1] = 'A';
   13   z.i[1][2] = 'R';
   14   z.i[1][3] = 0;
-> 15   return 0;
   16   }
(lldb) p z
(b) $0 = (i = char [2][4] @ 0x01fe3ca0)
(lldb) q



GDB

while gdb prints as expected,
Reading symbols from /home/chirag/a.out...done.
(gdb) b 15
Breakpoint 1 at 0x400511: file Desktop/test/struct.c, line 15.
(gdb) r
Starting program: /home/chirag/./a.out

Breakpoint 1, main () at Desktop/test/struct.c:15
15  return 0;
Missing separate debuginfos, use: debuginfo-install glibc-2.17-307.el7.1.x86_64
(gdb) p z
$1 = {i = {"FOO", "BAR"}}
(gdb) q
A debugging session is active.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 47758] New: Stop with a watchpoint, only on register values

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47758

Bug ID: 47758
   Summary: Stop with a watchpoint, only on register values
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: rustymagnet3...@gmail.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

If a system call is written with inline ASM and C, how do you stop lldb when
you don't know which function calls the syscall and you (only) want rely on the
registers containing values that match the syscall you are expecting?  Do I
want gdb's `catch syscall` in lldb ?   Is a better way to solve the issue with
existing lldb capabilities?

/*/
(lldb) b syscall
Breakpoint 2: where = libsystem_kernel.dylib`__syscall, address =
0x7fff522079f0

/** Breakpoint fires **/
(lldb) frame info   
frame #0: 0x7fff522079f0 libsystem_kernel.dylib`__syscall

(lldb) po (char *) $arg2
"/path/to/debugger_challenge.app/Info.plist"
/*/

I can extend this breakpoint with a condition.  It almost achieves what I want.
The breakpoint stops in syscall when a substring is found in one register:

`br s -n syscall -c '(char *) strnstr((char *)$rsi, "Info.plist",
(int)strlen((char *) $rsi)) != NULL'`

I got this idea from Jim Ingham:
https://stackoverflow.com/questions/36679156/lldb-how-to-set-breakpoint-whch-stops-when-register-somevalue

/*** Challenge ***/
If the same syscall is written with inline ASM and C, a `syscall` breakpoint
won't fire, as expected.  I can't place a breakpoint as I don't have a function
name to feed the breakpoint.  I don't know where in the binary contains the
`svc` opcode.

I tried `watchpoints` but these never seemed to trigger correctly.

watchpoint set expression -w read_write -- $rsi
watchpoint set expression -w read -- $arg2


For completeness, please see an arm64 example of inline ASM that calls the C
API Access() to check if a file exists:

/*** code that calls ASM function ***/

NSString *filepath = [appbundle pathForResource:@"Info" ofType:@"plist"];
const char *fp = filepath.fileSystemRepresentation;
#if defined(__arm64__)
int64_t result = [self asmSyscallFunction:fp];

/*** Inline ASM function ***/
 +(int64_t) asmSyscallFunction:(const char *) fp{

 int64_t res = 99;   // signed 64 bit wide int, as api can
return -1
 #if defined(__arm64__)
 __asm (
"mov x0, #33\n"  // access syscall number on arm
"mov x1, %[input_path]\n"// copy char* to x1
"mov x2, #0\n"   // File exist check == 0
"mov x16, #0\n"
"svc #33\n"
"mov %[result], x0 \n"
 : [result] "=r" (res)
 : [input_path] "r" (fp)
 : "x0", "x1", "x2", "x16", "memory"
 );
#endif
return res;
}

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb 11.0.0-rc2 different behavior then gdb.

[Jim Ingham via lldb-dev]

> On Oct 7, 2020, at 5:29 PM, Greg Clayton  wrote:
> 
> 
> 
>> On Oct 7, 2020, at 12:16 PM, Jim Ingham via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> 
>> 
>>> On Oct 7, 2020, at 12:11 PM, Pavel Labath >> <mailto:pa...@labath.sk>> wrote:
>>> 
>>> On 07/10/2020 21:01, Jim Ingham wrote:
>>>>> On Oct 7, 2020, at 11:44 AM, Pavel Labath >>>> <mailto:pa...@labath.sk> <mailto:pa...@labath.sk 
>>>>> <mailto:pa...@labath.sk>>> wrote:
>>>>> 
>>>>> On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote:
>>>>>> There isn’t a built-in summary formatter for two dimensional arrays of 
>>>>>> chars, but the type is matching the regex for the one-dimensional 
>>>>>> StringSummaryFormat, but that doesn’t actually know how to format two 
>>>>>> dimensional arrays of chars.  The type regex for StringSummaryFormat:
>>>>>> char [[0-9]+]
>>>>>> We should refine this regex so it doesn’t catch up two dimensional 
>>>>>> strings.  We could also write a formatter for two-dimensional strings.
>>>>> 
>>>>> Do we need a special formatter for two-dimensional strings? What about 3D?
>>>>> 
>>>>> I'd hope that this could be handled by a combination of the simple string 
>>>>> formatter and the generic array dumping code...
>>>> That works as expected, for instance if you do:
>>>> (lldb) frame var z.i
>>>> (char [2][4]) z.i = {
>>>>  [0] = "FOO"
>>>>  [1] = "BAR"
>>>> }
>>>> The thing that isn’t working is when the array doesn’t get auto-expanded 
>>>> by lldb, then you see the summary instead,
>>> 
>>> Ah, interesting. I didn't realize that.
>>> 
>>>> which is what you are seeing with:
>>>> (lldb) frame var z
>>>> (b) z = (i = char [2][4] @ 0x7ffeefbff5f0)
>>>> You can fix this either by having a summary string for char [][] or by 
>>>> telling lldb to expand more pointer like children for you:
>>>> (lldb) frame var -P2 z
>>>> (b) z = {
>>>>  i = {
>>>>[0] = "FOO"
>>>>[1] = "BAR"
>>>>  }
>>>> }
>>>> I’m hesitant to up the default pointer depth, I have gotten lots of 
>>>> complaints already about lldb disclosing too many subfields when printing 
>>>> structures.
>>> 
>>> Yeah, I don't think we'd want to increase that.
>>> 
>>>> We could also try to be smarter about what constitutes a “pointer” so the 
>>>> arrays don’t count against the pointer depth? Not sure how workable that 
>>>> would be.
>>> 
>>> This sounds workable. I mean, an array struct member is not really a 
>>> pointer (it only decays to a pointer) and does not suffer from the issues 
>>> that pointers do -- infinite recursion with recursive data structures, etc.
>> 
>> In any case we should not have the simple string formatter trying to format 
>> these arrays, which it clearly doesn’t know how to do.
> 
> Should be easy to modify the regex to:
> 
> ^char \[[0-9]+\]$

I don’t think you want the ^ or this wouldn’t match “const char [5]”.  I wasn’t 
sure there were any post-decorators we might care about, but I can’t think of 
any.

Jim


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

Re: [lldb-dev] lldb 11.0.0-rc2 different behavior then gdb.

[Greg Clayton via lldb-dev]

> On Oct 7, 2020, at 12:16 PM, Jim Ingham via lldb-dev 
>  wrote:
> 
> 
> 
>> On Oct 7, 2020, at 12:11 PM, Pavel Labath  wrote:
>> 
>> On 07/10/2020 21:01, Jim Ingham wrote:
>>>> On Oct 7, 2020, at 11:44 AM, Pavel Labath >>> <mailto:pa...@labath.sk>> wrote:
>>>> 
>>>> On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote:
>>>>> There isn’t a built-in summary formatter for two dimensional arrays of 
>>>>> chars, but the type is matching the regex for the one-dimensional 
>>>>> StringSummaryFormat, but that doesn’t actually know how to format two 
>>>>> dimensional arrays of chars.  The type regex for StringSummaryFormat:
>>>>> char [[0-9]+]
>>>>> We should refine this regex so it doesn’t catch up two dimensional 
>>>>> strings.  We could also write a formatter for two-dimensional strings.
>>>> 
>>>> Do we need a special formatter for two-dimensional strings? What about 3D?
>>>> 
>>>> I'd hope that this could be handled by a combination of the simple string 
>>>> formatter and the generic array dumping code...
>>> That works as expected, for instance if you do:
>>> (lldb) frame var z.i
>>> (char [2][4]) z.i = {
>>>  [0] = "FOO"
>>>  [1] = "BAR"
>>> }
>>> The thing that isn’t working is when the array doesn’t get auto-expanded by 
>>> lldb, then you see the summary instead,
>> 
>> Ah, interesting. I didn't realize that.
>> 
>>> which is what you are seeing with:
>>> (lldb) frame var z
>>> (b) z = (i = char [2][4] @ 0x7ffeefbff5f0)
>>> You can fix this either by having a summary string for char [][] or by 
>>> telling lldb to expand more pointer like children for you:
>>> (lldb) frame var -P2 z
>>> (b) z = {
>>>  i = {
>>>[0] = "FOO"
>>>[1] = "BAR"
>>>  }
>>> }
>>> I’m hesitant to up the default pointer depth, I have gotten lots of 
>>> complaints already about lldb disclosing too many subfields when printing 
>>> structures.
>> 
>> Yeah, I don't think we'd want to increase that.
>> 
>>> We could also try to be smarter about what constitutes a “pointer” so the 
>>> arrays don’t count against the pointer depth? Not sure how workable that 
>>> would be.
>> 
>> This sounds workable. I mean, an array struct member is not really a pointer 
>> (it only decays to a pointer) and does not suffer from the issues that 
>> pointers do -- infinite recursion with recursive data structures, etc.
> 
> In any case we should not have the simple string formatter trying to format 
> these arrays, which it clearly doesn’t know how to do.

Should be easy to modify the regex to:

^char \[[0-9]+\]$


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

Re: [lldb-dev] lldb 11.0.0-rc2 different behavior then gdb.

[Jim Ingham via lldb-dev]

> On Oct 7, 2020, at 12:11 PM, Pavel Labath  wrote:
> 
> On 07/10/2020 21:01, Jim Ingham wrote:
>>> On Oct 7, 2020, at 11:44 AM, Pavel Labath >> <mailto:pa...@labath.sk>> wrote:
>>> 
>>> On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote:
>>>> There isn’t a built-in summary formatter for two dimensional arrays of 
>>>> chars, but the type is matching the regex for the one-dimensional 
>>>> StringSummaryFormat, but that doesn’t actually know how to format two 
>>>> dimensional arrays of chars.  The type regex for StringSummaryFormat:
>>>> char [[0-9]+]
>>>> We should refine this regex so it doesn’t catch up two dimensional 
>>>> strings.  We could also write a formatter for two-dimensional strings.
>>> 
>>> Do we need a special formatter for two-dimensional strings? What about 3D?
>>> 
>>> I'd hope that this could be handled by a combination of the simple string 
>>> formatter and the generic array dumping code...
>> That works as expected, for instance if you do:
>> (lldb) frame var z.i
>> (char [2][4]) z.i = {
>>   [0] = "FOO"
>>   [1] = "BAR"
>> }
>> The thing that isn’t working is when the array doesn’t get auto-expanded by 
>> lldb, then you see the summary instead,
> 
> Ah, interesting. I didn't realize that.
> 
>> which is what you are seeing with:
>> (lldb) frame var z
>> (b) z = (i = char [2][4] @ 0x7ffeefbff5f0)
>> You can fix this either by having a summary string for char [][] or by 
>> telling lldb to expand more pointer like children for you:
>> (lldb) frame var -P2 z
>> (b) z = {
>>   i = {
>> [0] = "FOO"
>> [1] = "BAR"
>>   }
>> }
>>  I’m hesitant to up the default pointer depth, I have gotten lots of 
>> complaints already about lldb disclosing too many subfields when printing 
>> structures.
> 
> Yeah, I don't think we'd want to increase that.
> 
>> We could also try to be smarter about what constitutes a “pointer” so the 
>> arrays don’t count against the pointer depth? Not sure how workable that 
>> would be.
> 
> This sounds workable. I mean, an array struct member is not really a pointer 
> (it only decays to a pointer) and does not suffer from the issues that 
> pointers do -- infinite recursion with recursive data structures, etc.

In any case we should not have the simple string formatter trying to format 
these arrays, which it clearly doesn’t know how to do.

Jim


> 
> pl

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

Re: [lldb-dev] lldb 11.0.0-rc2 different behavior then gdb.

[Pavel Labath via lldb-dev]

On 07/10/2020 21:01, Jim Ingham wrote:



On Oct 7, 2020, at 11:44 AM, Pavel Labath <mailto:pa...@labath.sk>> wrote:


On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote:
There isn’t a built-in summary formatter for two dimensional arrays 
of chars, but the type is matching the regex for the one-dimensional 
StringSummaryFormat, but that doesn’t actually know how to format two 
dimensional arrays of chars.  The type regex for StringSummaryFormat:

char [[0-9]+]
We should refine this regex so it doesn’t catch up two dimensional 
strings.  We could also write a formatter for two-dimensional strings.


Do we need a special formatter for two-dimensional strings? What about 3D?

I'd hope that this could be handled by a combination of the simple 
string formatter and the generic array dumping code...


That works as expected, for instance if you do:

(lldb) frame var z.i
(char [2][4]) z.i = {
   [0] = "FOO"
   [1] = "BAR"
}

The thing that isn’t working is when the array doesn’t get auto-expanded 
by lldb, then you see the summary instead,


Ah, interesting. I didn't realize that.

which is what you are seeing 
with:


(lldb) frame var z
(b) z = (i = char [2][4] @ 0x7ffeefbff5f0)

You can fix this either by having a summary string for char [][] or by 
telling lldb to expand more pointer like children for you:


(lldb) frame var -P2 z
(b) z = {
   i = {
     [0] = "FOO"
     [1] = "BAR"
   }
}

  I’m hesitant to up the default pointer depth, I have gotten lots of 
complaints already about lldb disclosing too many subfields when 
printing structures.


Yeah, I don't think we'd want to increase that.



We could also try to be smarter about what constitutes a “pointer” so 
the arrays don’t count against the pointer depth? Not sure how workable 
that would be.


This sounds workable. I mean, an array struct member is not really a 
pointer (it only decays to a pointer) and does not suffer from the 
issues that pointers do -- infinite recursion with recursive data 
structures, etc.


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

Re: [lldb-dev] lldb 11.0.0-rc2 different behavior then gdb.

[Jim Ingham via lldb-dev]

> On Oct 7, 2020, at 11:44 AM, Pavel Labath  wrote:
> 
> On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote:
>> There isn’t a built-in summary formatter for two dimensional arrays of 
>> chars, but the type is matching the regex for the one-dimensional 
>> StringSummaryFormat, but that doesn’t actually know how to format two 
>> dimensional arrays of chars.  The type regex for StringSummaryFormat:
>> char [[0-9]+]
>> We should refine this regex so it doesn’t catch up two dimensional strings.  
>> We could also write a formatter for two-dimensional strings.
> 
> Do we need a special formatter for two-dimensional strings? What about 3D?
> 
> I'd hope that this could be handled by a combination of the simple string 
> formatter and the generic array dumping code...

That works as expected, for instance if you do:

(lldb) frame var z.i
(char [2][4]) z.i = {
  [0] = "FOO"
  [1] = "BAR"
}

The thing that isn’t working is when the array doesn’t get auto-expanded by 
lldb, then you see the summary instead, which is what you are seeing with:

(lldb) frame var z
(b) z = (i = char [2][4] @ 0x7ffeefbff5f0)

You can fix this either by having a summary string for char [][] or by telling 
lldb to expand more pointer like children for you:

(lldb) frame var -P2 z
(b) z = {
  i = {
[0] = "FOO"
[1] = "BAR"
  }
}

 I’m hesitant to up the default pointer depth, I have gotten lots of complaints 
already about lldb disclosing too many subfields when printing structures.

We could also try to be smarter about what constitutes a “pointer” so the 
arrays don’t count against the pointer depth? Not sure how workable that would 
be.

Jim


> 
> pl

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

Re: [lldb-dev] lldb 11.0.0-rc2 different behavior then gdb.

[Pavel Labath via lldb-dev]

On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote:
There isn’t a built-in summary formatter for two dimensional arrays of 
chars, but the type is matching the regex for the one-dimensional 
StringSummaryFormat, but that doesn’t actually know how to format two 
dimensional arrays of chars.  The type regex for StringSummaryFormat:


char [[0-9]+]

We should refine this regex so it doesn’t catch up two dimensional 
strings.  We could also write a formatter for two-dimensional strings.


Do we need a special formatter for two-dimensional strings? What about 3D?

I'd hope that this could be handled by a combination of the simple 
string formatter and the generic array dumping code...


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

Re: [lldb-dev] lldb 11.0.0-rc2 different behavior then gdb.

[Jim Ingham via lldb-dev]

There isn’t a built-in summary formatter for two dimensional arrays of chars, 
but the type is matching the regex for the one-dimensional StringSummaryFormat, 
but that doesn’t actually know how to format two dimensional arrays of chars.  
The type regex for StringSummaryFormat: 

char [[0-9]+]

We should refine this regex so it doesn’t catch up two dimensional strings.  We 
could also write a formatter for two-dimensional strings.  

Would you file bugs about those two issues with http://bugs.llvm.org? 
<http://bugs.llvm.org/?>  Thanks.

Note that user added formatters are scanned first and the match is granted to 
the first hit, so if you need this yourself, in the meantime you could write 
your own formatter and it should fire.

Jim


> On Oct 7, 2020, at 5:26 AM, Chirag Patel via lldb-dev 
>  wrote:
> 
> Hello all,
>  
> While debugging and printing struct with multi-dimensional char array, gdb 
> successfully prints string while lldb bails out with only printing address.
> For simple C testcase,
>  
> struct b {
> char i[2][4];
> };
>  
> int main() {
> struct b z;
> z.i[0][0] = 'F';
> z.i[0][1] = 'O';
> z.i[0][2] = 'O';
> z.i[0][3] = 0;
> z.i[1][0] = 'B';
> z.i[1][1] = 'A';
> z.i[1][2] = 'R';
> z.i[1][3] = 0;
> return 0;
> }
>  
> On gdb,
> Reading symbols from /home/chirag/a.out...done.
> (gdb) l
> 1   struct b {
> 2   char i[2][4];
> 3   };
> 4
> 5   int main() {
> 6   struct b z;
> 7   z.i[0][0] = 'F';
> 8   z.i[0][1] = 'O';
> 9   z.i[0][2] = 'O';
> 10  z.i[0][3] = 0;
> (gdb) l
> 11  z.i[1][0] = 'B';
> 12  z.i[1][1] = 'A';
> 13  z.i[1][2] = 'R';
> 14  z.i[1][3] = 0;
> 15  return 0;
> 16  }
> (gdb) b 15
> Breakpoint 1 at 0x400511: file Desktop/test/struct.c, line 15.
> (gdb) r
> Starting program: /home/chirag/./a.out
>  
> Breakpoint 1, main () at Desktop/test/struct.c:15
> 15  return 0;
> Missing separate debuginfos, use: debuginfo-install 
> glibc-2.17-307.el7.1.x86_64
> (gdb) p z
> $1 = {i = {"FOO", "BAR"}}
> (gdb) q
> A debugging session is active.
>  
> While on lldb 11.0.0-rc2, (lldb) target create "/home/chirag/a.out"
> Current executable set to '/home/chirag/a.out' (x86_64).
> (lldb) b 15
> Breakpoint 1: where = a.out`main + 36 at struct.c:15, address = 
> 0x00400511
> (lldb) r
> Process 57100 launched: '/home/chirag/a.out' (x86_64)
> Process 57100 stopped
> * thread #1, name = 'a.out', stop reason = breakpoint 1.1
> frame #0: 0x00400511 a.out`main at struct.c:15
>12   z.i[1][1] = 'A';
>13   z.i[1][2] = 'R';
>14   z.i[1][3] = 0;
> -> 15   return 0;
>16   }
> (lldb) p z
> (b) $0 = (i = char [2][4] @ 0x01fe3ca0)
> (lldb) q
>  
> It seems like the type summary formatter is failing? Or is it the intended 
> behaviour?.
>  
> Thanks and Regards,
> Chirag Patel.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 47743] LLDB displays wrong values for packed bitfields

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47743

lab...@google.com changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |lab...@google.com

--- Comment #3 from lab...@google.com ---
I have a fix up at https://reviews.llvm.org/D88992. Could you please check
whether that fixes your problem? (The problem I ran into triggers in only very
specific circumstances, but judging by your description, you may have run into
something more generic.)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] n00b error running lldb tests on windows?

[Joseph Tremoulet via lldb-dev]

Hi,

I'm trying to run the lldb tests on Windows (fresh installs of VS2019 16.7.5, 
Python 3.8.5, and Swig 4.0.2).  The API tests crash immediately in python 
initialization code:

Windows fatal exception: access violation

Current thread 0x693c (most recent call first):
  File "", line 219 in _call_with_frames_removed
  File "", line 1101 in create_module
  File "", line 556 in module_from_spec
  File "", line 657 in _load_unlocked
  File "", line 975 in _find_and_load_unlocked
  File "", line 991 in _find_and_load
  File "", line 219 in _call_with_frames_removed
  File "", line 1042 in _handle_fromlist
  File "D:\Obj\lldb\Debug\Lib\site-packages\lldb\__init__.py", line 41 in 

  File "", line 219 in _call_with_frames_removed
  File "", line 783 in exec_module
  File "", line 671 in _load_unlocked
  File "", line 975 in _find_and_load_unlocked
  File "", line 991 in _find_and_load
  File "D:\Source\llvm-project\lldb\packages\Python\lldbsuite\test\dotest.py", 
line 898 in run_suite
  File "D:/Source/llvm-project/lldb\test\API\dotest.py", line 7 in 

Running in the debugger, I see "_PyRuntime.gc.generation0 was nullptr".

I presume I have something set up incorrectly in my environment, but I haven't 
had much luck figuring out what.  Is this by any chance an error/stack that 
somebody recognizes as a common/known issue?

Thanks,
-Joseph

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

[lldb-dev] [11.0.0 Release] Release Candidate 6 is here

[Hans Wennborg via lldb-dev]

Hello once again,

A few more issues appeared, so here is yet another release candidate:
llvmorg-11.0.0-rc6 was just tagged.

Source code and docs are available at
https://prereleases.llvm.org/11.0.0/#rc6
and
https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc6

Pre-built binaries will be added as they become ready.

Please file reports for any bugs you find as blockers of
https://llvm.org/pr46725

Release testers, if you still have cycles, please take this for a
quick spin. The changes from rc5 are minimal, and hopefully we can tag
this as the final version very soon now.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] lldb 11.0.0-rc2 different behavior then gdb.

[Chirag Patel via lldb-dev]

Hello all,

While debugging and printing struct with multi-dimensional char array, gdb 
successfully prints string while lldb bails out with only printing address.
For simple C testcase,

struct b {
char i[2][4];
};

int main() {
struct b z;
z.i[0][0] = 'F';
z.i[0][1] = 'O';
z.i[0][2] = 'O';
z.i[0][3] = 0;
z.i[1][0] = 'B';
z.i[1][1] = 'A';
z.i[1][2] = 'R';
z.i[1][3] = 0;
return 0;
}

On gdb,
Reading symbols from /home/chirag/a.out...done.
(gdb) l
1   struct b {
2   char i[2][4];
3   };
4
5   int main() {
6   struct b z;
7   z.i[0][0] = 'F';
8   z.i[0][1] = 'O';
9   z.i[0][2] = 'O';
10  z.i[0][3] = 0;
(gdb) l
11  z.i[1][0] = 'B';
12  z.i[1][1] = 'A';
13  z.i[1][2] = 'R';
14  z.i[1][3] = 0;
15  return 0;
16  }
(gdb) b 15
Breakpoint 1 at 0x400511: file Desktop/test/struct.c, line 15.
(gdb) r
Starting program: /home/chirag/./a.out

Breakpoint 1, main () at Desktop/test/struct.c:15
15  return 0;
Missing separate debuginfos, use: debuginfo-install glibc-2.17-307.el7.1.x86_64
(gdb) p z
$1 = {i = {"FOO", "BAR"}}
(gdb) q
A debugging session is active.

While on lldb 11.0.0-rc2, (lldb) target create "/home/chirag/a.out"
Current executable set to '/home/chirag/a.out' (x86_64).
(lldb) b 15
Breakpoint 1: where = a.out`main + 36 at struct.c:15, address = 
0x00400511
(lldb) r
Process 57100 launched: '/home/chirag/a.out' (x86_64)
Process 57100 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00400511 a.out`main at struct.c:15
   12   z.i[1][1] = 'A';
   13   z.i[1][2] = 'R';
   14   z.i[1][3] = 0;
-> 15   return 0;
   16   }
(lldb) p z
(b) $0 = (i = char [2][4] @ 0x01fe3ca0)
(lldb) q

It seems like the type summary formatter is failing? Or is it the intended 
behaviour?.

Thanks and Regards,
Chirag Patel.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 47743] New: LLDB displays wrong values for packed bitfields

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47743

Bug ID: 47743
   Summary: LLDB displays wrong values for packed bitfields
   Product: lldb
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: came...@moodycamel.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

When an 'unsigned' bitfield is in a packed structure, its bits may straddle two
aligned dwords in memory.

LLDB calculates the value by reading a single dword from the byte offset of the
first unsigned, then shifting and masking using the bitfield offset/size.
However, when the value straddles two unsigned dwords, the byte offset + bit
offset + size extends past the end of the first dword, and the displayed value
is cut off (missing trailing bits).

To reproduce on a little-endian machine:

struct __attribute__((packed)) foo
{
unsigned : 31;
unsigned u11Sample : 11;
unsigned : 22;
};

__attribute__((noinline))
int quux(struct foo* f)
{
// break here and inspect f->u11Sample
// the value should be 0x50, but it's not displayed as such
return f->u11Sample;
}

int main()
{
struct foo f = { 0 };
f.u11Sample = 0x50;
return quux();
}

To reproduce on a big-endian machine use this struct definition instead:

struct __attribute__((packed)) foo
{
unsigned : 22;
unsigned u11Sample : 11;
unsigned : 31;
};


As a starting point for whoever wants to investigate this, put a breakpoint on
'valobj->GetData(data, error);' (near line 91) in TypeFormat.cpp. Observe the
data read, as well as the
m_byte_offset/m_bitfield_bit_size/m_bitfield_bit_offset in valobj (it's of type
ValueObjectChild).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Deadlock loading DWARF symbols

[Pavel Labath via lldb-dev]

On 02/10/2020 23:13, Greg Clayton wrote:

Yes this is bad, and GetDescription() is used as a convenience to print out the 
module path (which might be a .o file within a .a file) and optionally 
architecture of the module. It probably shouldn't be taking the module lock as 
the only member variables that that GetDescription accesses are:

Module::m_arch
Module::m_file
Module::m_object_name

I would almost vote to take out the mutex lock in GetDescription() as the arch, 
file and name don't change after the module has been created. I am going to CC 
a few extra folks for discussion.

Anyone else have any objections to removing the mutex in GetDescription? Seems 
like this deadlock is easy to trigger if you have DWARF with errors or warnings 
inside of it.



That sounds reasonable to me. All of the above fields can change during 
the early stages of Module construction (while the ObjectFile is being 
parsed and such), but I would certainly hope they remain stable after 
that. And this early construction process should be single-threaded.


So, I am fine with saying any subsequent modification is a bug.

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

Re: [lldb-dev] [flang-dev] [llvm-dev] [11.0.0 Release] Release Candidate 4 is here

[Diana Picus via lldb-dev]

Hi,

Uploaded arm & aarch64:
3e2dbe0dcdaa82aaba4480c9b5d042846858903bff743259a1b63a36c75ba9d7
clang+llvm-11.0.0-rc4-armv7a-linux-gnueabihf.tar.xz
8fa05ddb6fe4e49c4347f3decdbcaa623f3b0e88fc6a264058f05fc0ed3d71e0
clang+llvm-11.0.0-rc4-aarch64-linux-gnu.tar.xz

No new regressions.

Cheers,
Diana

On Wed, 30 Sep 2020 at 20:24, Amy Kwan via flang-dev
 wrote:
>
> Hi Hans,
>
> I've completed release testing for llvm-11.0.0-rc4 on Power PC 64bit Little 
> Endian for Ubuntu 18.04 and Red Hat 7.4. I did not see any regressions for 
> RC4.
> I have uploaded the respective binaries and have attached the sha1 files.
>
> Thank you,
> Amy K.
>
> On Mon, 28 Sep 2020 at 13:28, Hans Wennborg via llvm-dev 
>  wrote:
>>
>> Hello everyone,
>>
>> A little less than a week after rc3, the llvmorg-11.0.0-rc4 tag was
>> just created.
>>
>> Source code and docs are available at
>> https://prereleases.llvm.org/11.0.0/#rc4
>> and
>> https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc4
>>
>> Pre-built binaries will be added as they become ready.
>>
>> Please file bug reports for any issues you find as blockers of
>> https://llvm.org/pr46725
>>
>> Release testers: if you still have cycles, please run the test script,
>> share your results, and upload binaries. And thank you very much for
>> your help so far.
>>
>> This is very similar to rc3, but picks up a few more fixes. Again,
>> there are currently no open release blockers, which means this is what
>> the final release could look like.
>>
>> Thanks,
>> Hans
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> ___
> flang-dev mailing list
> flang-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Deadlock loading DWARF symbols

[Greg Clayton via lldb-dev]

Yes this is bad, and GetDescription() is used as a convenience to print out the 
module path (which might be a .o file within a .a file) and optionally 
architecture of the module. It probably shouldn't be taking the module lock as 
the only member variables that that GetDescription accesses are:

Module::m_arch
Module::m_file
Module::m_object_name

I would almost vote to take out the mutex lock in GetDescription() as the arch, 
file and name don't change after the module has been created. I am going to CC 
a few extra folks for discussion.

Anyone else have any objections to removing the mutex in GetDescription? Seems 
like this deadlock is easy to trigger if you have DWARF with errors or warnings 
inside of it.

Greg


> On Oct 2, 2020, at 6:50 AM, Dmitry Antipov via lldb-dev 
>  wrote:
> 
> I'm observing the following deadlock:
> 
> One thread calls Module::PreloadSymbols() which takes m_mutex of this Module. 
> Module::PreloadSymbols()
> calls ManualDWARFIndex::Index(), which, in turn, creates thread pool and 
> waits for all threads completion:
> 
> (gdb)
> #0  futex_wait_cancelable (private=0, expected=0, futex_word=0x7f67f176914c) 
> at ../sysdeps/nptl/futex-internal.h:183
> #1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7f67f17690c8, 
> cond=0x7f67f1769120) at pthread_cond_wait.c:508
> #2  __pthread_cond_wait (cond=0x7f67f1769120, mutex=0x7f67f17690c8) at 
> pthread_cond_wait.c:638
> #3  0x7f67f3974890 in 
> std::condition_variable::wait(std::unique_lock&) () from 
> /lib64/libstdc++.so.6
> #4  0x7f67f4440c4b in 
> std::condition_variable::wait > 
> (__p=..., __lock=..., this=0x7f67f1769120)
>at /usr/include/c++/10/condition_variable:108
> #5  llvm::ThreadPool::wait (this=this@entry=0x7f67f1769060) at 
> source/llvm/lib/Support/ThreadPool.cpp:72
> #6  0x7f67fc6fa3a6 in lldb_private::ManualDWARFIndex::Index 
> (this=0x7f66fe87e950)
>at source/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp:94
> #7  0x7f67fc6b3825 in SymbolFileDWARF::PreloadSymbols 
> (this=0x7f67de7af6f0) at /usr/include/c++/10/bits/unique_ptr.h:421
> #8  0x7f67fc1ee488 in lldb_private::Module::PreloadSymbols 
> (this=0x7f67de79b620) at source/lldb/source/Core/Module.cpp:1397
> #9  0x7f67fc397a37 in lldb_private::Target::GetOrCreateModule 
> (this=this@entry=0x96c7a0, module_spec=..., notify=notify@entry=true, 
> error_ptr=error_ptr@entry=0x0)
>at /usr/include/c++/10/bits/shared_ptr_base.h:1324
> ...
> 
> OTOH one of pool threads makes an attempt to lock Module's mutex:
> 
> (gdb) bt
> #0  __lll_lock_wait (futex=futex@entry=0x7f67de79b638, private=0) at 
> lowlevellock.c:52
> #1  0x7f67fcd907f1 in __GI___pthread_mutex_lock (mutex=0x7f67de79b638) at 
> ../nptl/pthread_mutex_lock.c:115
> #2  0x7f67fc1ed922 in __gthread_mutex_lock (__mutex=0x7f67de79b638) at 
> /usr/include/c++/10/x86_64-redhat-linux/bits/gthr-default.h:749
> #3  __gthread_recursive_mutex_lock (__mutex=0x7f67de79b638) at 
> /usr/include/c++/10/x86_64-redhat-linux/bits/gthr-default.h:811
> #4  std::recursive_mutex::lock (this=0x7f67de79b638) at 
> /usr/include/c++/10/mutex:106
> #5  std::lock_guard::lock_guard (__m=..., 
> this=) at /usr/include/c++/10/bits/std_mutex.h:159
> #6  lldb_private::Module::GetDescription (this=this@entry=0x7f67de79b620, 
> s=..., level=level@entry=lldb::eDescriptionLevelBrief)
>at source/lldb/source/Core/Module.cpp:1083
> #7  0x7f67fc1f2070 in lldb_private::Module::ReportError 
> (this=0x7f67de79b620, format=0x7f67fca03660 "DW_FORM_ref* DIE reference 0x%lx 
> is outside of its CU")
>at source/lldb/include/lldb/Utility/Stream.h:358
> #8  0x7f67fc6adfb4 in DWARFFormValue::Reference 
> (this=this@entry=0x7f66f5ff29c0) at 
> /usr/include/c++/10/bits/shared_ptr_base.h:1324
> #9  0x7f67fc6aaa77 in DWARFDebugInfoEntry::GetAttributes 
> (this=this@entry=0x7f662e3580e0, cu=cu@entry=0x7f66ff6ebad0, attributes=...,
>recurse=recurse@entry=DWARFBaseDIE::Recurse::yes, 
> curr_depth=curr_depth@entry=0)
>at source/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp:439
> #10 0x7f67fc6f8f8f in DWARFDebugInfoEntry::GetAttributes 
> (recurse=DWARFBaseDIE::Recurse::yes, attrs=..., cu=0x7f66ff6ebad0, 
> this=0x7f662e3580e0)
>at source/lldb/source/./Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.h:54
> #11 lldb_private::ManualDWARFIndex::IndexUnitImpl (unit=..., 
> cu_language=cu_language@entry=lldb::eLanguageTypeRust, set=...)
>at source/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp:180
> #12 0x7f67fc6f96b7 in lldb_private::ManualDWARFIndex::IndexUnit 
> (this=, unit=..., dwp=0x0, set=...)
>at source/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp:126
> ...
>

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

[Greg Clayton via lldb-dev]

> On Oct 2, 2020, at 3:51 AM, Pavel Labath  wrote:
> 
> On 01/10/2020 22:32, Walter wrote:
>> After a chat with Greg, we agreed on this set of commands
>> 
>> 
>> trace load /path/to/json process trace start/stop process trace save
>> /path/to/json thread trace start/stop thread trace dump [instructions |
>> functions]
>> 
> 
> Thanks. The new commands look good to me.

Great, we can move the "trace dump" over to "thread trace dump" for 
https://reviews.llvm.org/D86670  and keep that 
moving.

> The multi-process trace concept is interesting. I don't question its
> usefulness -- I am sure it can be useful for various kinds of analysis
> (though I've never used that myself). I am wondering though about how to
> represent this thing in lldb, as we don't really have anything close to
> the concept of "debugging" all processes on a given system.
> 
> The only thing that comes close is probably the kernel-level debugging.
> One idea (which has just occurred to me, so it may not be good) might be
> to make these traces behave similarly to that. I.e., create a single
> target/process with one "thread" per physical cpu, and then have a
> special "os plugin" like thing which would present individual
> process/threads.

I don't know enough about how trace data is stored or annotated after the raw 
data is pulled from the cores, but to make it useful it must be able to be 
associated with processes and threads somehow otherwise it would be just a 
bunch of addresses that would all overlap between many processes. 

 
> That would have the advantage of maintaining the one trace-one target
> invariant and also would preserve the information about relative timings
> of individual "processes". I think that wuold be an interesting way to
> view these things, but I don't know if it would be the best one...

I might suggest that each trace plug-in should do its best to represent 
processes and threads as separate entities so that they all remain separate. 
What ever data starts out as should be abstracted and I think I would rather 
see individual processes with their threads if that is possible to do, but I am 
just thinking of this with just a bit of knowledge tracing data. I think many 
chip makers create these trace formats and they are designed from a "trace a 
core" perspective, but if we can tame this data and present it as users would 
want to see it instead of trying to represent it as the data is stored, I think 
we will have a compelling trace feature in our debugger.

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

[lldb-dev] Deadlock loading DWARF symbols

[Dmitry Antipov via lldb-dev]

I'm observing the following deadlock:

One thread calls Module::PreloadSymbols() which takes m_mutex of this Module. 
Module::PreloadSymbols()
calls ManualDWARFIndex::Index(), which, in turn, creates thread pool and waits 
for all threads completion:

(gdb)
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x7f67f176914c) at 
../sysdeps/nptl/futex-internal.h:183
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7f67f17690c8, 
cond=0x7f67f1769120) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x7f67f1769120, mutex=0x7f67f17690c8) at 
pthread_cond_wait.c:638
#3  0x7f67f3974890 in 
std::condition_variable::wait(std::unique_lock&) () from 
/lib64/libstdc++.so.6
#4  0x7f67f4440c4b in 
std::condition_variable::wait > (__p=..., 
__lock=..., this=0x7f67f1769120)
at /usr/include/c++/10/condition_variable:108
#5  llvm::ThreadPool::wait (this=this@entry=0x7f67f1769060) at 
source/llvm/lib/Support/ThreadPool.cpp:72
#6  0x7f67fc6fa3a6 in lldb_private::ManualDWARFIndex::Index 
(this=0x7f66fe87e950)
at source/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp:94
#7  0x7f67fc6b3825 in SymbolFileDWARF::PreloadSymbols (this=0x7f67de7af6f0) 
at /usr/include/c++/10/bits/unique_ptr.h:421
#8  0x7f67fc1ee488 in lldb_private::Module::PreloadSymbols 
(this=0x7f67de79b620) at source/lldb/source/Core/Module.cpp:1397
#9  0x7f67fc397a37 in lldb_private::Target::GetOrCreateModule 
(this=this@entry=0x96c7a0, module_spec=..., notify=notify@entry=true, 
error_ptr=error_ptr@entry=0x0)
at /usr/include/c++/10/bits/shared_ptr_base.h:1324
...

OTOH one of pool threads makes an attempt to lock Module's mutex:

(gdb) bt
#0  __lll_lock_wait (futex=futex@entry=0x7f67de79b638, private=0) at 
lowlevellock.c:52
#1  0x7f67fcd907f1 in __GI___pthread_mutex_lock (mutex=0x7f67de79b638) at 
../nptl/pthread_mutex_lock.c:115
#2  0x7f67fc1ed922 in __gthread_mutex_lock (__mutex=0x7f67de79b638) at 
/usr/include/c++/10/x86_64-redhat-linux/bits/gthr-default.h:749
#3  __gthread_recursive_mutex_lock (__mutex=0x7f67de79b638) at 
/usr/include/c++/10/x86_64-redhat-linux/bits/gthr-default.h:811
#4  std::recursive_mutex::lock (this=0x7f67de79b638) at 
/usr/include/c++/10/mutex:106
#5  std::lock_guard::lock_guard (__m=..., this=) at /usr/include/c++/10/bits/std_mutex.h:159
#6  lldb_private::Module::GetDescription (this=this@entry=0x7f67de79b620, 
s=..., level=level@entry=lldb::eDescriptionLevelBrief)
at source/lldb/source/Core/Module.cpp:1083
#7  0x7f67fc1f2070 in lldb_private::Module::ReportError (this=0x7f67de79b620, 
format=0x7f67fca03660 "DW_FORM_ref* DIE reference 0x%lx is outside of its CU")
at source/lldb/include/lldb/Utility/Stream.h:358
#8  0x7f67fc6adfb4 in DWARFFormValue::Reference 
(this=this@entry=0x7f66f5ff29c0) at 
/usr/include/c++/10/bits/shared_ptr_base.h:1324
#9  0x7f67fc6aaa77 in DWARFDebugInfoEntry::GetAttributes 
(this=this@entry=0x7f662e3580e0, cu=cu@entry=0x7f66ff6ebad0, attributes=...,
recurse=recurse@entry=DWARFBaseDIE::Recurse::yes, 
curr_depth=curr_depth@entry=0)
at source/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp:439
#10 0x7f67fc6f8f8f in DWARFDebugInfoEntry::GetAttributes 
(recurse=DWARFBaseDIE::Recurse::yes, attrs=..., cu=0x7f66ff6ebad0, 
this=0x7f662e3580e0)
at source/lldb/source/./Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.h:54
#11 lldb_private::ManualDWARFIndex::IndexUnitImpl (unit=..., 
cu_language=cu_language@entry=lldb::eLanguageTypeRust, set=...)
at source/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp:180
#12 0x7f67fc6f96b7 in lldb_private::ManualDWARFIndex::IndexUnit 
(this=, unit=..., dwp=0x0, set=...)
at source/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp:126
...

So this is a deadlock because thread pool is created with module lock held, and 
one (or more,
I'm observing two) pool thread(s) might want to grab the same lock to issue an 
error message.

Commenting out the whole body of Module::GetDescription() makes this deadlock 
disappear.

I'm not an expert in this area, but the whole thing looks like the Module 
object should have more
fine-granted locking rather than the only std::recursive_mutex for all 
synchronization purposes.

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

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

[Pavel Labath via lldb-dev]

On 01/10/2020 22:32, Walter wrote:
> After a chat with Greg, we agreed on this set of commands
> 
> 
> trace load /path/to/json process trace start/stop process trace save
> /path/to/json thread trace start/stop thread trace dump [instructions |
> functions]
> 

Thanks. The new commands look good to me.


The multi-process trace concept is interesting. I don't question its
usefulness -- I am sure it can be useful for various kinds of analysis
(though I've never used that myself). I am wondering though about how to
represent this thing in lldb, as we don't really have anything close to
the concept of "debugging" all processes on a given system.

The only thing that comes close is probably the kernel-level debugging.
One idea (which has just occurred to me, so it may not be good) might be
to make these traces behave similarly to that. I.e., create a single
target/process with one "thread" per physical cpu, and then have a
special "os plugin" like thing which would present individual
process/threads.

That would have the advantage of maintaining the one trace-one target
invariant and also would preserve the information about relative timings
of individual "processes". I think that wuold be an interesting way to
view these things, but I don't know if it would be the best one...

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

Re: [lldb-dev] [Release-testers] [11.0.0 Release] Release Candidate 5 is here

[Brian Cain via lldb-dev]

Uploaded binaries for SLES12 and Ubuntu 16 x86_64.  I realized that I'd
forgotten rc3,4 ones so I uploaded them too.

$ cat clang+llvm-11.0.0-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz.sha256
clang+llvm-11.0.0-rc3-x86_64-linux-sles12.4.tar.xz.sha256
clang+llvm-11.0.0-rc4-x86_64-linux-sles12.4.tar.xz.sha256
clang+llvm-11.0.0-rc5-x86_64-linux-gnu-ubuntu-16.04.tar.xz.sha256
clang+llvm-11.0.0-rc5-x86_64-linux-sles12.4.tar.xz.sha256

aaf668664769dfb071c59f5d2622f3459d457b58489ee79f69262cef8cf2abb4
 clang+llvm-11.0.0-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz
93394ee58b18ec72bf4455dc6055a9ba5100621282547c686bd4ef689fe1d8a5
 clang+llvm-11.0.0-rc3-x86_64-linux-sles12.4.tar.xz
91a0984c7d0be93af310a1d762e34e283952ce9734ecec040b6a90fd31466150
 clang+llvm-11.0.0-rc4-x86_64-linux-sles12.4.tar.xz
af8daead4a6d996fab7630759a9330d5eb0ceea06dbd6daa7fdd92126b0f02ee
 clang+llvm-11.0.0-rc5-x86_64-linux-gnu-ubuntu-16.04.tar.xz
b57ef3689a6bf161dab3fee644fe0837e1c9cb31875556f7be259b8eaf64a43d
 clang+llvm-11.0.0-rc5-x86_64-linux-sles12.4.tar.xz



On Wed, Sep 30, 2020 at 1:07 PM Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:

> Hello again,
>
> We had to pick up another bug fix, so here is another release
> candidate: llvmorg-11.0.0-rc5 tag was just created.
>
> Source code and docs are available at
> https://prereleases.llvm.org/11.0.0/#rc5
> and
> https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc5
>
> Pre-built binaries will be added as they become ready.
>
> Please file reports for any bugs you find as blockers of
> https://llvm.org/pr46725
>
> Release testers, if you still have cycles (perhaps you didn't even
> have time to start rc4 yet), please run the test script, share your
> results, and upload binaries.
>
> As mentioned above, this rc is very similar to the previous one. There
> are no open blockers, so it could be the last release candidate.
>
> Thanks,
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>


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

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

[Greg Clayton via lldb-dev]

I had accepted the patch https://reviews.llvm.org/D86670 
<https://reviews.llvm.org/D86670>, but then marked as "Request Changes" while 
we discuss the commands in this RFC after new comments came in.


> On Oct 1, 2020, at 1:42 PM, Greg Clayton  wrote:
> 
> We spoke a bit after Panel's comments which made sense and we propose the 
> commands Walter sent below. Let us know what everyone thinks of this 
> organization of the command structure!
> 
>> On Oct 1, 2020, at 1:32 PM, Walter > <mailto:a20012...@gmail.com>> wrote:
>> 
>> After a chat with Greg, we agreed on this set of commands
>> 
>> 
>> trace load /path/to/json
>> 
>> process trace start/stop
>> process trace save /path/to/json
>> 
>> thread trace start/stop
>> thread trace dump [instructions | functions]
>> 
>> 
>> Il giorno gio 1 ott 2020 alle ore 13:21 Greg Clayton > <mailto:clayb...@gmail.com>> ha scritto:
>> 
>> 
>> > On Oct 1, 2020, at 7:08 AM, Pavel Labath via lldb-dev 
>> > mailto:lldb-dev@lists.llvm.org>> wrote:
>> > 
>> > Thank you for writing this Walter. I think this document will be a
>> > useful reference both now and in the future.
>> > 
>> > The part that's not clear to me is what is the story with multi-process
>> > traces. The file format enables those, but it's not clear how are they
>> > going be created or used. Can you elaborate more on what you intend to
>> > use those for?
>> 
>> Mainly for system trace kinds of things where an entire system gets traced.
>> 
>> > 
>> > The main reason I am asking that is because I am thinking about the
>> > proposed command structure. I'm wondering if it would not be better to
>> > fit this into the existing target/process/thread commands instead of
>> > adding a new top-level command. For example, one could imagine the
>> > following set of commands:
>> > 
>> > - "process trace start" + "thread trace start" instead of "thread trace
>> > [tid]". That would be similar to "process continue" + "thread continue".
>> > - "thread trace dump [tid]" instead of "trace dump [-t tid]". That would
>> > be similar to "thread continue" and other thread control commands.
>> > - "target create --trace" instead of "trace load". (analogous to target
>> > create --core).
>> > - "process trace save" instead of "trace save" -- (mostly) analogous to
>> > "process save-core"
>> 
>> > I am thinking this composition may fit in better into the existing lldb
>> > command landscape, though I also see the appeal in grouping everything
>> > trace-related under a single top-level command. What do you think?
>> > 
>> > The main place where this idea breaks down is the multi-process traces.
>> > While we could certainly make "target create --trace" create multiple
>> > targets, that would be fairly unusual. OTOH, the whole concept of having
>> > multiple targets share something is a pretty unusual thing for lldb.
>> > That's why I'd like to hear more about where you want to go with this idea.
>> 
>> I kind of see tracing has having two sides:
>> 1 - post mortem tracing for individual or multiple processes
>> 2 - live debug session tracing for being able to see how you crashed where 
>> trace data is for current process only
>> 
>> For post mortem tracing, the trace top level command seemed to make sense 
>> here because there are no other target commands that act on more than one 
>> target. So "trace load" makes sense to me here for loading one or more 
>> traces. The idea is the trace JSON file has enough info to completely load 
>> up the state of the trace so we can symbolicate, dump and step around in 
>> history. So I would vote to keep "trace load" at the very least because it 
>> can create one or more targets. Options can be added to display the 
>> processes if needed:
>> 
>> (lldb) trace list 
>> 
>> But we could move "trace dump" over into "target trace dump" or "process 
>> trace dump" since that is effectively how we are coding these patches.
>> 
>> For live debugging where we gather trace data through the process plug-in, 
>> we will have a live process that may or may not have trace data. If tracing 
>> isn't available we will not be able to dump anything. But I would like to 
>> see process/

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

[Greg Clayton via lldb-dev]

We spoke a bit after Panel's comments which made sense and we propose the 
commands Walter sent below. Let us know what everyone thinks of this 
organization of the command structure!

> On Oct 1, 2020, at 1:32 PM, Walter  wrote:
> 
> After a chat with Greg, we agreed on this set of commands
> 
> 
> trace load /path/to/json
> 
> process trace start/stop
> process trace save /path/to/json
> 
> thread trace start/stop
> thread trace dump [instructions | functions]
> 
> 
> Il giorno gio 1 ott 2020 alle ore 13:21 Greg Clayton  <mailto:clayb...@gmail.com>> ha scritto:
> 
> 
> > On Oct 1, 2020, at 7:08 AM, Pavel Labath via lldb-dev 
> > mailto:lldb-dev@lists.llvm.org>> wrote:
> > 
> > Thank you for writing this Walter. I think this document will be a
> > useful reference both now and in the future.
> > 
> > The part that's not clear to me is what is the story with multi-process
> > traces. The file format enables those, but it's not clear how are they
> > going be created or used. Can you elaborate more on what you intend to
> > use those for?
> 
> Mainly for system trace kinds of things where an entire system gets traced.
> 
> > 
> > The main reason I am asking that is because I am thinking about the
> > proposed command structure. I'm wondering if it would not be better to
> > fit this into the existing target/process/thread commands instead of
> > adding a new top-level command. For example, one could imagine the
> > following set of commands:
> > 
> > - "process trace start" + "thread trace start" instead of "thread trace
> > [tid]". That would be similar to "process continue" + "thread continue".
> > - "thread trace dump [tid]" instead of "trace dump [-t tid]". That would
> > be similar to "thread continue" and other thread control commands.
> > - "target create --trace" instead of "trace load". (analogous to target
> > create --core).
> > - "process trace save" instead of "trace save" -- (mostly) analogous to
> > "process save-core"
> 
> > I am thinking this composition may fit in better into the existing lldb
> > command landscape, though I also see the appeal in grouping everything
> > trace-related under a single top-level command. What do you think?
> > 
> > The main place where this idea breaks down is the multi-process traces.
> > While we could certainly make "target create --trace" create multiple
> > targets, that would be fairly unusual. OTOH, the whole concept of having
> > multiple targets share something is a pretty unusual thing for lldb.
> > That's why I'd like to hear more about where you want to go with this idea.
> 
> I kind of see tracing has having two sides:
> 1 - post mortem tracing for individual or multiple processes
> 2 - live debug session tracing for being able to see how you crashed where 
> trace data is for current process only
> 
> For post mortem tracing, the trace top level command seemed to make sense 
> here because there are no other target commands that act on more than one 
> target. So "trace load" makes sense to me here for loading one or more 
> traces. The idea is the trace JSON file has enough info to completely load up 
> the state of the trace so we can symbolicate, dump and step around in 
> history. So I would vote to keep "trace load" at the very least because it 
> can create one or more targets. Options can be added to display the processes 
> if needed:
> 
> (lldb) trace list 
> 
> But we could move "trace dump" over into "target trace dump" or "process 
> trace dump" since that is effectively how we are coding these patches.
> 
> For live debugging where we gather trace data through the process plug-in, we 
> will have a live process that may or may not have trace data. If tracing 
> isn't available we will not be able to dump anything. But I would like to see 
> process/thread commands for this scenario:
> 
> - process trace start/stop (only succeeds if we can gather trace data through 
> the process plug-in)
> - thread trace start/stop (which can succeed only if current tracing can 
> enable tracing for only one thread)
> 
> Not sure if we need "process trace save" or "thread trace save" as the saving 
> can be done as an option to "process trace stop --save /path/to/save"
> 
> So I am all for fitting these commands in where they need to go.
> 
> > 
> > On 21/09/2020 22:17, Walter via lldb-dev wrote:
> >> Thanks for your feedback Fang

Re: [lldb-dev] LLDB got SIGCHLD on hitting the breakpoint

[Greg Clayton via lldb-dev]

LLDB 5 is really old and shouldn't be used for linux debugging as linux support 
had many issues back then. I would suggest downloading and building the latest 
and greatest LLDB from llvm.org <http://llvm.org/> or using the clang 10 
release version of LLDB, or the new clang 11 release version that is about to 
be released.

Greg

> On Sep 16, 2020, at 9:03 AM, le wang via lldb-dev  
> wrote:
> 
> Hello,everyone:
> I've got a problem, when debugging my process with lldb tool on linux 
> OS(CentOS7).While I use lldb command to set breakpoints, and launch my 
> process, my process will execute a binary code which contains debug 
> information, but when my process launched, all breakpoints can not be hit, 
> and after a while, received several informations like below:
> Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
> Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
> Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
> Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
> Process 4256 stopped and restarted: thread2 received signal:   SIGCHLD
> 
> Details can be seen in my snapshot in attachment.
> It seems that lldb crashed, and at last although my process is executed,  
> this is meaningless. I have checked that debug information in IR is correct. 
> I have no idea the reason. Can anyone tell me the reason and how to fix this 
> problem. My lldb version is 5.0.0, which got from http://www.llvm.org/ 
> <http://www.llvm.org/> with llvm5.0.0
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

[Walter via lldb-dev]

After a chat with Greg, we agreed on this set of commands


trace load /path/to/json process trace start/stop process trace save
/path/to/json thread trace start/stop thread trace dump [instructions |
functions]

Il giorno gio 1 ott 2020 alle ore 13:21 Greg Clayton 
ha scritto:

>
>
> > On Oct 1, 2020, at 7:08 AM, Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Thank you for writing this Walter. I think this document will be a
> > useful reference both now and in the future.
> >
> > The part that's not clear to me is what is the story with multi-process
> > traces. The file format enables those, but it's not clear how are they
> > going be created or used. Can you elaborate more on what you intend to
> > use those for?
>
> Mainly for system trace kinds of things where an entire system gets traced.
>
> >
> > The main reason I am asking that is because I am thinking about the
> > proposed command structure. I'm wondering if it would not be better to
> > fit this into the existing target/process/thread commands instead of
> > adding a new top-level command. For example, one could imagine the
> > following set of commands:
> >
> > - "process trace start" + "thread trace start" instead of "thread trace
> > [tid]". That would be similar to "process continue" + "thread continue".
> > - "thread trace dump [tid]" instead of "trace dump [-t tid]". That would
> > be similar to "thread continue" and other thread control commands.
> > - "target create --trace" instead of "trace load". (analogous to target
> > create --core).
> > - "process trace save" instead of "trace save" -- (mostly) analogous to
> > "process save-core"
>
> > I am thinking this composition may fit in better into the existing lldb
> > command landscape, though I also see the appeal in grouping everything
> > trace-related under a single top-level command. What do you think?
> >
> > The main place where this idea breaks down is the multi-process traces.
> > While we could certainly make "target create --trace" create multiple
> > targets, that would be fairly unusual. OTOH, the whole concept of having
> > multiple targets share something is a pretty unusual thing for lldb.
> > That's why I'd like to hear more about where you want to go with this
> idea.
>
> I kind of see tracing has having two sides:
> 1 - post mortem tracing for individual or multiple processes
> 2 - live debug session tracing for being able to see how you crashed where
> trace data is for current process only
>
> For post mortem tracing, the trace top level command seemed to make sense
> here because there are no other target commands that act on more than one
> target. So "trace load" makes sense to me here for loading one or more
> traces. The idea is the trace JSON file has enough info to completely load
> up the state of the trace so we can symbolicate, dump and step around in
> history. So I would vote to keep "trace load" at the very least because it
> can create one or more targets. Options can be added to display the
> processes if needed:
>
> (lldb) trace list 
>
> But we could move "trace dump" over into "target trace dump" or "process
> trace dump" since that is effectively how we are coding these patches.
>
> For live debugging where we gather trace data through the process plug-in,
> we will have a live process that may or may not have trace data. If tracing
> isn't available we will not be able to dump anything. But I would like to
> see process/thread commands for this scenario:
>
> - process trace start/stop (only succeeds if we can gather trace data
> through the process plug-in)
> - thread trace start/stop (which can succeed only if current tracing can
> enable tracing for only one thread)
>
> Not sure if we need "process trace save" or "thread trace save" as the
> saving can be done as an option to "process trace stop --save /path/to/save"
>
> So I am all for fitting these commands in where they need to go.
>
> >
> > On 21/09/2020 22:17, Walter via lldb-dev wrote:
> >> Thanks for your feedback Fangrui, I've just been checking Capn' Proto
> >> and it looks really good. I'll keep it in mind in the design and see how
> >> it can optimize the overall data transfer.
> >
> > I'm not sure how Cap'n Proto comes into play here. The way I understand
> > it, the real data is contained in a separate file in the specialized
> > intel format and the json is just for the metadata. I'd expect the
> > metadata file to be small even for enormous traces, so I'm not sure
> > what's to be gained by optimizing it.
> >
> > pl
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>

-- 
- Walter Erquínigo Pezo
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

[Greg Clayton via lldb-dev]

> On Oct 1, 2020, at 7:08 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> Thank you for writing this Walter. I think this document will be a
> useful reference both now and in the future.
> 
> The part that's not clear to me is what is the story with multi-process
> traces. The file format enables those, but it's not clear how are they
> going be created or used. Can you elaborate more on what you intend to
> use those for?

Mainly for system trace kinds of things where an entire system gets traced.

> 
> The main reason I am asking that is because I am thinking about the
> proposed command structure. I'm wondering if it would not be better to
> fit this into the existing target/process/thread commands instead of
> adding a new top-level command. For example, one could imagine the
> following set of commands:
> 
> - "process trace start" + "thread trace start" instead of "thread trace
> [tid]". That would be similar to "process continue" + "thread continue".
> - "thread trace dump [tid]" instead of "trace dump [-t tid]". That would
> be similar to "thread continue" and other thread control commands.
> - "target create --trace" instead of "trace load". (analogous to target
> create --core).
> - "process trace save" instead of "trace save" -- (mostly) analogous to
> "process save-core"

> I am thinking this composition may fit in better into the existing lldb
> command landscape, though I also see the appeal in grouping everything
> trace-related under a single top-level command. What do you think?
> 
> The main place where this idea breaks down is the multi-process traces.
> While we could certainly make "target create --trace" create multiple
> targets, that would be fairly unusual. OTOH, the whole concept of having
> multiple targets share something is a pretty unusual thing for lldb.
> That's why I'd like to hear more about where you want to go with this idea.

I kind of see tracing has having two sides:
1 - post mortem tracing for individual or multiple processes
2 - live debug session tracing for being able to see how you crashed where 
trace data is for current process only

For post mortem tracing, the trace top level command seemed to make sense here 
because there are no other target commands that act on more than one target. So 
"trace load" makes sense to me here for loading one or more traces. The idea is 
the trace JSON file has enough info to completely load up the state of the 
trace so we can symbolicate, dump and step around in history. So I would vote 
to keep "trace load" at the very least because it can create one or more 
targets. Options can be added to display the processes if needed:

(lldb) trace list 

But we could move "trace dump" over into "target trace dump" or "process trace 
dump" since that is effectively how we are coding these patches.

For live debugging where we gather trace data through the process plug-in, we 
will have a live process that may or may not have trace data. If tracing isn't 
available we will not be able to dump anything. But I would like to see 
process/thread commands for this scenario:

- process trace start/stop (only succeeds if we can gather trace data through 
the process plug-in)
- thread trace start/stop (which can succeed only if current tracing can enable 
tracing for only one thread)

Not sure if we need "process trace save" or "thread trace save" as the saving 
can be done as an option to "process trace stop --save /path/to/save"

So I am all for fitting these commands in where they need to go.

> 
> On 21/09/2020 22:17, Walter via lldb-dev wrote:
>> Thanks for your feedback Fangrui, I've just been checking Capn' Proto
>> and it looks really good. I'll keep it in mind in the design and see how
>> it can optimize the overall data transfer.
> 
> I'm not sure how Cap'n Proto comes into play here. The way I understand
> it, the real data is contained in a separate file in the specialized
> intel format and the json is just for the metadata. I'd expect the
> metadata file to be small even for enormous traces, so I'm not sure
> what's to be gained by optimizing it.
> 
> pl
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

[Walter via lldb-dev]

Hi Pavel, thanks for the comments. I'll reply inline

> The part that's not clear to me is what is the story with multi-process
traces. The file format enables those, but it's not clear how are they
going be created or used. Can you elaborate more on what you intend to
use those for?

Something we are doing at Facebook is having a global Intel PT collector
that can trace all processes of a given machine for some seconds. This can
produce a multi-process trace. I imagine these traces won't ever be
generated by LLDB, though. Having one single json trace file for this is
going to be useful for sharing the trace more easily. Multi-process tracing
is also something you can do with the perf tool, so It's not uncommon.

There are some technical details that are worth mentioning as well. Intel
PT offers two main modes of tracing: single thread tracing and logical CPU
tracing.
- The first one is the easiest to implement, but it requires having a
dedicated buffer per thread, which can consume too much RAM if there are
thousands of threads traced. It also adds a little bit of performance cost,
as the kernel disables and enables tracing whenever there's a context
switch.
- The other mode, logical CPU tracing, traces all the activity in one
logical core and uses one single buffer. Also it is more performant as the
kernel doesn't disable tracing intermittently. Sadly, that trace contains
no information regarding context switches, so a separated context switch
trace is used for splitting this big trace into per-thread subtraces. The
decoder we are implementing eventually will be able to do this splitting,
and it will require being fed with the information of all processes. This
is also a reason why allowing multi-process traces is important.

Regarding the commands structure, I'd prefer to keep it under "trace" for
now, because of the multi-process case and because we still have no users
that can report feedback. Very soon we'll start building some tools around
this feature, so we'll have more concrete experiences to share. Then it'll
be good to sync up and revisit the structure.

Btw, the gdb implementation of this kind of tracing is under the "record"
main command (
https://sourceware.org/gdb/current/onlinedocs/gdb/Process-Record-and-Replay.html).
I think this allows for some flexibility, as each trace plugin has
different characteristics.

> I'm not sure how Cap'n Proto comes into play here. The way I understand
it, the real data is contained in a separate file in the specialized intel
format and the json is just for the metadata. I'd expect the metadata file
to be small even for enormous traces, so I'm not sure what's to be gained
by optimizing it.

I didn't mention it in that email, but there is some additional information
that we'll eventually include in the traces, like the context-switch trace
I mentioned above. I think that we could probably use Cap'n Proto for cases
like this. We might also not use it at all as well, but it was nice to
learn about it and keep it in mind.


Thanks,
Walter

Il giorno gio 1 ott 2020 alle ore 07:08 Pavel Labath  ha
scritto:

> Thank you for writing this Walter. I think this document will be a
> useful reference both now and in the future.
>
> The part that's not clear to me is what is the story with multi-process
> traces. The file format enables those, but it's not clear how are they
> going be created or used. Can you elaborate more on what you intend to
> use those for?
>
> The main reason I am asking that is because I am thinking about the
> proposed command structure. I'm wondering if it would not be better to
> fit this into the existing target/process/thread commands instead of
> adding a new top-level command. For example, one could imagine the
> following set of commands:
>
> - "process trace start" + "thread trace start" instead of "thread trace
> [tid]". That would be similar to "process continue" + "thread continue".
> - "thread trace dump [tid]" instead of "trace dump [-t tid]". That would
> be similar to "thread continue" and other thread control commands.
> - "target create --trace" instead of "trace load". (analogous to target
> create --core).
> - "process trace save" instead of "trace save" -- (mostly) analogous to
> "process save-core"
>
> I am thinking this composition may fit in better into the existing lldb
> command landscape, though I also see the appeal in grouping everything
> trace-related under a single top-level command. What do you think?
>
> The main place where this idea breaks down is the multi-process traces.
> While we could certainly make "target create --trace" create multiple
> targets, that would be fairly unusual. OTOH, the whole concept of having
> multiple targets share something

Re: [lldb-dev] [Release-testers] [11.0.0 Release] Release Candidate 5 is here

[Dimitry Andric via lldb-dev]

On 30 Sep 2020, at 20:07, Hans Wennborg via Release-testers 
 wrote:
> 
> We had to pick up another bug fix, so here is another release
> candidate: llvmorg-11.0.0-rc5 tag was just created.

I've built both rc4 and rc5, and again these did not need any patches.

Main results on amd64-freebsd11:

  Unsupported:  5122 (rc4:  5122, rc3:  5122)
  Passed : 69761 (rc4: 69761, rc3: 69761)
  Expectedly Failed  :   245 (rc4:   245, rc3:   245)
  Timed Out  :16 (rc4:16, rc3:16)
  Failed :   481 (rc4:   481, rc3:   480)
  Unexpectedly Passed: 2 (rc4: 2, rc3: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc4: 2399, rc3: 2399)
  Failed:3 (rc4:3, rc3:3)

Main results on i386-freebsd11:

  Unsupported:   3513 (rc4:  3513, rc3:  3513)
  Passed :  66637 (rc4: 66637, rc3: 66636)
  Expectedly Failed  :230 (rc4:   230, rc3:   230)
  Timed Out  :  7 (rc4: 7, rc3: 7)
  Failed :321 (rc4:   321, rc3:   321)
  Unexpectedly Passed:  1 (rc4: 1, rc3: 1)

Uploaded:
SHA256 (clang+llvm-11.0.0-rc4-amd64-unknown-freebsd11.tar.xz) = 
b95c237df671ee507c607e8d36245126c5ea5241389aae0b20e3e4fce4f3df37
SHA256 (clang+llvm-11.0.0-rc4-i386-unknown-freebsd11.tar.xz) = 
60755863b49155d23c9fef9571aa09ca46425a9bd830d9ef498fe9855e741d11
SHA256 (clang+llvm-11.0.0-rc5-amd64-unknown-freebsd11.tar.xz) = 
712401cade6996bb7042cdd659b41ee4411cdd9cc34cbdd21e7a4cafe75ac267
SHA256 (clang+llvm-11.0.0-rc5-i386-unknown-freebsd11.tar.xz) = 
956bd26d28602f375853593631c1f413a869ba6087c51f7ef5405fa31263d06c

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

[Pavel Labath via lldb-dev]

Thank you for writing this Walter. I think this document will be a
useful reference both now and in the future.

The part that's not clear to me is what is the story with multi-process
traces. The file format enables those, but it's not clear how are they
going be created or used. Can you elaborate more on what you intend to
use those for?

The main reason I am asking that is because I am thinking about the
proposed command structure. I'm wondering if it would not be better to
fit this into the existing target/process/thread commands instead of
adding a new top-level command. For example, one could imagine the
following set of commands:

- "process trace start" + "thread trace start" instead of "thread trace
[tid]". That would be similar to "process continue" + "thread continue".
- "thread trace dump [tid]" instead of "trace dump [-t tid]". That would
be similar to "thread continue" and other thread control commands.
- "target create --trace" instead of "trace load". (analogous to target
create --core).
- "process trace save" instead of "trace save" -- (mostly) analogous to
"process save-core"

I am thinking this composition may fit in better into the existing lldb
command landscape, though I also see the appeal in grouping everything
trace-related under a single top-level command. What do you think?

The main place where this idea breaks down is the multi-process traces.
While we could certainly make "target create --trace" create multiple
targets, that would be fairly unusual. OTOH, the whole concept of having
multiple targets share something is a pretty unusual thing for lldb.
That's why I'd like to hear more about where you want to go with this idea.


On 21/09/2020 22:17, Walter via lldb-dev wrote:
> Thanks for your feedback Fangrui, I've just been checking Capn' Proto
> and it looks really good. I'll keep it in mind in the design and see how
> it can optimize the overall data transfer.

I'm not sure how Cap'n Proto comes into play here. The way I understand
it, the real data is contained in a separate file in the specialized
intel format and the json is just for the metadata. I'd expect the
metadata file to be small even for enormous traces, so I'm not sure
what's to be gained by optimizing it.

pl

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

Re: [lldb-dev] Weird results running lldb under Valgrind

[Greg Clayton via lldb-dev]

Glad we know why at least! Thanks for bringing this to our attention.

Greg

> On Sep 30, 2020, at 2:53 AM, Dmitry Antipov  wrote:
> 
> On 9/29/20 11:40 PM, Greg Clayton wrote:
> 
>> How could LLDB even function then? We are using the standard std::mutex + 
>> std::condition workflow here. Not sure how LLDB could even function if it 
>> locking was nor working as expected.
> 
> Well, obviously this is an issue (and probably the same one) with debugging 
> tools.
> 
>> Doing a quick web search, this seems to be due to a mismatched libc++ and 
>> libstdc++:
>> https://github.com/google/sanitizers/issues/1259
> 
> Nice. So if your libstdc++ is new enough to use pthread_cond_clockwait(), 
> both TSan and
> valgrind produces weird results just because they can handle 
> pthread_cond_timedwait() only.
> 
> Dmitry
> 

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

[lldb-dev] [11.0.0 Release] Release Candidate 5 is here

[Hans Wennborg via lldb-dev]

Hello again,

We had to pick up another bug fix, so here is another release
candidate: llvmorg-11.0.0-rc5 tag was just created.

Source code and docs are available at
https://prereleases.llvm.org/11.0.0/#rc5
and
https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc5

Pre-built binaries will be added as they become ready.

Please file reports for any bugs you find as blockers of
https://llvm.org/pr46725

Release testers, if you still have cycles (perhaps you didn't even
have time to start rc4 yet), please run the test script, share your
results, and upload binaries.

As mentioned above, this rc is very similar to the previous one. There
are no open blockers, so it could be the last release candidate.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Weird results running lldb under Valgrind

[Dmitry Antipov via lldb-dev]

On 9/29/20 11:40 PM, Greg Clayton wrote:


How could LLDB even function then? We are using the standard std::mutex + 
std::condition workflow here. Not sure how LLDB could even function if it 
locking was nor working as expected.


Well, obviously this is an issue (and probably the same one) with debugging 
tools.


Doing a quick web search, this seems to be due to a mismatched libc++ and 
libstdc++:

https://github.com/google/sanitizers/issues/1259


Nice. So if your libstdc++ is new enough to use pthread_cond_clockwait(), both 
TSan and
valgrind produces weird results just because they can handle 
pthread_cond_timedwait() only.

Dmitry

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

Re: [lldb-dev] Weird results running lldb under Valgrind

[Greg Clayton via lldb-dev]

How could LLDB even function then? We are using the standard std::mutex + 
std::condition workflow here. Not sure how LLDB could even function if it 
locking was nor working as expected.

Doing a quick web search, this seems to be due to a mismatched libc++ and 
libstdc++:

https://github.com/google/sanitizers/issues/1259

Greg

> On Sep 29, 2020, at 9:46 AM, Dmitry Antipov  wrote:
> 
> On 9/25/20 5:53 PM, Dmitry Antipov wrote:
> 
>> On 9/24/20 9:14 PM, Greg Clayton wrote:
>>> This must be a valgrind issue, there would be major problems if the OS 
>>> isn't able to lock mutex objects correctly ("mutex is locked simultaneously 
>>> by two threads"). It is getting confused by a recursive mutex? LLDB uses 
>>> recursive mutexes.
>> LLDB's Predicate.h uses plain std::mutex, which is not recursive, and 
>> std::lock_guard/std::unique_lock
>> on top of it.
>> This needs more digging in because the latest Valgrind snapshot reports the 
>> same "impossible" condition.
> 
> To whom it may be interesting, thread sanitizer reports nearly the same:
> 
> WARNING: ThreadSanitizer: double lock of a mutex (pid=2049545)
>#0 pthread_mutex_lock  (libtsan.so.0+0x528ac)
>#1 __gthread_mutex_lock 
> /usr/include/c++/10/x86_64-redhat-linux/bits/gthr-default.h:749 
> (liblldb.so.12git+0xd725c0)
>#2 std::mutex::lock() /usr/include/c++/10/bits/std_mutex.h:100 
> (liblldb.so.12git+0xd725c0)
>#3 std::lock_guard::lock_guard(std::mutex&) 
> /usr/include/c++/10/bits/std_mutex.h:159 (liblldb.so.12git+0xd725c0)
>#4 lldb_private::Predicate::SetValue(bool, 
> lldb_private::PredicateBroadcastType) 
> /home/antipov/llvm/source/lldb/include/lldb/Utility/Predicate.h:91 
> (liblldb.so.12git+0xd725c0)
>#5 lldb_private::EventDataReceipt::DoOnRemoval(lldb_private::Event*) 
> /home/antipov/llvm/source/lldb/include/lldb/Utility/Event.h:121 
> (liblldb.so.12git+0xd725c0)
>#6 lldb_private::Event::DoOnRemoval() 
> /home/antipov/llvm/source/lldb/source/Utility/Event.cpp:82 
> (liblldb.so.12git+0xedb7da)
>#7 
> lldb_private::Listener::FindNextEventInternal(std::unique_lock&, 
> lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, 
> unsigned int, std::shared_ptr&, bool) 
> /home/antipov/llvm/source/lldb/source/Utility/Listener.cpp:309 
> (liblldb.so.12git+0xee6099)
>#8 
> lldb_private::Listener::GetEventInternal(lldb_private::Timeout 100l> > const&, lldb_private::Broadcaster*, lldb_private::ConstString 
> const*, unsigned int, unsigned int, std::shared_ptr&) 
> /home/antipov/llvm/source/lldb/source/Utility/Listener.cpp:357 
> (liblldb.so.12git+0xee6b63)
>#9 
> lldb_private::Listener::GetEventForBroadcaster(lldb_private::Broadcaster*, 
> std::shared_ptr&, lldb_private::Timeout 100l> > const&) 
> /home/antipov/llvm/source/lldb/source/Utility/Listener.cpp:395 
> (liblldb.so.12git+0xee6dea)
>#10 
> lldb_private::Process::GetEventsPrivate(std::shared_ptr&,
>  lldb_private::Timeout > const&, bool) 
> /home/antipov/llvm/source/lldb/source/Target/Process.cpp:1139 
> (liblldb.so.12git+0xd7931d)
>#11 lldb_private::Process::RunPrivateStateThread(bool) 
> /home/antipov/llvm/source/lldb/source/Target/Process.cpp:3872 
> (liblldb.so.12git+0xda3648)
>#12 lldb_private::Process::PrivateStateThread(void*) 
> /home/antipov/llvm/source/lldb/source/Target/Process.cpp:3857 
> (liblldb.so.12git+0xda3f87)
>#13 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) 
> /home/antipov/llvm/source/lldb/source/Host/common/HostNativeThreadBase.cpp:68 
> (liblldb.so.12git+0xc2c0ea)
>#14   (libtsan.so.0+0x2d33f)
> 
> Again, lldb_private::Predicate uses plain std::mutex, which is not recursive.
> 
> Dmitry

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

Re: [lldb-dev] Weird results running lldb under Valgrind

[Dmitry Antipov via lldb-dev]

On 9/25/20 5:53 PM, Dmitry Antipov wrote:


On 9/24/20 9:14 PM, Greg Clayton wrote:

This must be a valgrind issue, there would be major problems if the OS isn't able to lock mutex objects correctly ("mutex is locked simultaneously by two threads"). It is getting confused by a 
recursive mutex? LLDB uses recursive mutexes.


LLDB's Predicate.h uses plain std::mutex, which is not recursive, and 
std::lock_guard/std::unique_lock
on top of it.

This needs more digging in because the latest Valgrind snapshot reports the same 
"impossible" condition.


To whom it may be interesting, thread sanitizer reports nearly the same:

WARNING: ThreadSanitizer: double lock of a mutex (pid=2049545)
#0 pthread_mutex_lock  (libtsan.so.0+0x528ac)
#1 __gthread_mutex_lock 
/usr/include/c++/10/x86_64-redhat-linux/bits/gthr-default.h:749 
(liblldb.so.12git+0xd725c0)
#2 std::mutex::lock() /usr/include/c++/10/bits/std_mutex.h:100 
(liblldb.so.12git+0xd725c0)
#3 std::lock_guard::lock_guard(std::mutex&) 
/usr/include/c++/10/bits/std_mutex.h:159 (liblldb.so.12git+0xd725c0)
#4 lldb_private::Predicate::SetValue(bool, 
lldb_private::PredicateBroadcastType) 
/home/antipov/llvm/source/lldb/include/lldb/Utility/Predicate.h:91 
(liblldb.so.12git+0xd725c0)
#5 lldb_private::EventDataReceipt::DoOnRemoval(lldb_private::Event*) 
/home/antipov/llvm/source/lldb/include/lldb/Utility/Event.h:121 
(liblldb.so.12git+0xd725c0)
#6 lldb_private::Event::DoOnRemoval() 
/home/antipov/llvm/source/lldb/source/Utility/Event.cpp:82 
(liblldb.so.12git+0xedb7da)
#7 lldb_private::Listener::FindNextEventInternal(std::unique_lock&, lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, unsigned int, 
std::shared_ptr&, bool) /home/antipov/llvm/source/lldb/source/Utility/Listener.cpp:309 (liblldb.so.12git+0xee6099)
#8 lldb_private::Listener::GetEventInternal(lldb_private::Timeout > const&, lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, unsigned int, 
std::shared_ptr&) /home/antipov/llvm/source/lldb/source/Utility/Listener.cpp:357 (liblldb.so.12git+0xee6b63)
#9 lldb_private::Listener::GetEventForBroadcaster(lldb_private::Broadcaster*, std::shared_ptr&, lldb_private::Timeout > const&) 
/home/antipov/llvm/source/lldb/source/Utility/Listener.cpp:395 (liblldb.so.12git+0xee6dea)
#10 lldb_private::Process::GetEventsPrivate(std::shared_ptr&, lldb_private::Timeout > const&, bool) 
/home/antipov/llvm/source/lldb/source/Target/Process.cpp:1139 (liblldb.so.12git+0xd7931d)

#11 lldb_private::Process::RunPrivateStateThread(bool) 
/home/antipov/llvm/source/lldb/source/Target/Process.cpp:3872 
(liblldb.so.12git+0xda3648)
#12 lldb_private::Process::PrivateStateThread(void*) 
/home/antipov/llvm/source/lldb/source/Target/Process.cpp:3857 
(liblldb.so.12git+0xda3f87)
#13 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) 
/home/antipov/llvm/source/lldb/source/Host/common/HostNativeThreadBase.cpp:68 
(liblldb.so.12git+0xc2c0ea)
#14   (libtsan.so.0+0x2d33f)

Again, lldb_private::Predicate uses plain std::mutex, which is not recursive.

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

Re: [lldb-dev] LLDB got SIGCHLD on hitting the breakpoint

[Pavel Labath via lldb-dev]

When you say "execute binary code", where exactly is this code being
executed? Is it executed by launching another process?

Lldb will not automatically debug all child process spawned by your
process -- they will run freely.

The SIGCHLDs are not coming from lldb -- they are signals which all
processes receive (from the operating system) when one of their children
dies. They just mean that your process has executed some subprocess and
that subprocess has terminated.

pl

On 21/09/2020 11:48, le wang via lldb-dev wrote:
> Hello,everyone:
> I've got a problem, when debugging my process with lldb tool on linux
> OS(CentOS7).While I use lldb command to set breakpoints, and launch my
> process, my process will execute a binary code which contains debug
> information, but when my process launched, all breakpoints can not be
> hit, The debug process and several received informations like below:  
> （lldb）target create  /home/out/lib/linux64/Debug/appEngine 
> Current executable set to '/home/out/lib/linux64/Debug/appEngine'
>  (x86_64)     
> （lldb）br s -f
> /home/out/lib/linux64/Debug/configDB/TestFunctionProcess.cpp -l1
> Breakpoint 1: no locations(pending).
> WARNING :  Unable to resolve breakpoint to any actual locations.
> （lldb）br s -f
> /home/out/lib/linux64/Debug/configDB/TestFunctionProcess.cpp -l2
> Breakpoint 2: no locations(pending).
> WARNING :  Unable to resolve breakpoint to any actual locations.
> （lldb）r
> Process 4256 launched: '/home/out/lib/linux64/Debug/appEngine'  (x86_64)
>     
> Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
> Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
> Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
> Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
> Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
> Process 4256 stopped and restarted: thread2 received signal:   SIGCHLD
> 
> Process stopped and restarted: thread 2 received signal: SIGCHLD
> It seems these repeated restart notifications come from lldb, and at
> last although my process is executed,  it is meaningless. I have checked
> that debug information in IR is correct. I have no idea the reason. Can
> anyone tell me the reason and how to fix this problem. My lldb version
> is 5.0.0, which got from http://www.llvm.org/ with llvm5.0.0
> 
> 
> Thanks,
> le wang
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

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

[lldb-dev] [11.0.0 Release] Release Candidate 4 is here

[Hans Wennborg via lldb-dev]

Hello everyone,

A little less than a week after rc3, the llvmorg-11.0.0-rc4 tag was
just created.

Source code and docs are available at
https://prereleases.llvm.org/11.0.0/#rc4
and
https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc4

Pre-built binaries will be added as they become ready.

Please file bug reports for any issues you find as blockers of
https://llvm.org/pr46725

Release testers: if you still have cycles, please run the test script,
share your results, and upload binaries. And thank you very much for
your help so far.

This is very similar to rc3, but picks up a few more fixes. Again,
there are currently no open release blockers, which means this is what
the final release could look like.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 47648] New: Lack of persistent history

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47648

Bug ID: 47648
   Summary: Lack of persistent history
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: bruno.card...@gmail.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

I've noticed that whenever LLDB crashes I lose all the history from a session.
This is fine for quick sessions but I often leave sessions open for days or
weeks and it's pretty sad to lose all the joy.

I looked up but didn't find a way to have LLDB regularly flushing that to disk
(or even a command to allow me to do that myself). Any solutions along those
lines would be great to have.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 47647] Use fzf (fuzzy finder) for search backward through history

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47647

Jonas Devlieghere  changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |jdevliegh...@apple.com

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 47647] New: Use fzf (fuzzy finder) for search backward through history

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47647

Bug ID: 47647
   Summary: Use fzf (fuzzy finder) for search backward through
history
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: bruno.card...@gmail.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

Pretty much what the summary says. This would be really handy for quick
searching history. Not sure how easy is to hook this up to LLDB but several
tools (bash, zsh, vim, ...) can currently leverage this.

Fuzzy Finder:
https://github.com/junegunn/fzf

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Weird results running lldb under Valgrind

[Dmitry Antipov via lldb-dev]

On 9/24/20 9:14 PM, Greg Clayton wrote:


This must be a valgrind issue, there would be major problems if the OS isn't able to lock 
mutex objects correctly ("mutex is locked simultaneously by two threads"). It 
is getting confused by a recursive mutex? LLDB uses recursive mutexes.W


LLDB's Predicate.h uses plain std::mutex, which is not recursive, and 
std::lock_guard/std::unique_lock
on top of it.

This needs more digging in because the latest Valgrind snapshot reports the same 
"impossible" condition.

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

Re: [lldb-dev] [llvm-dev] Optimised-code debugging experience Round Table

[Eric Christopher via lldb-dev]

Hi Paul,

I took it rather as a set of suggested topics depending on who is
interested rather than a proposed agenda.

-eric

On Wed, Sep 23, 2020 at 7:20 AM Robinson, Paul 
wrote:

> Hi Eric & Orlando,
>
>
>
> It’s great to see interest in a lot of different aspects of debug info. At
> the same time, I’m concerned about a risk to making the topic so broad that
> we don’t have time to get through all the things people want to get
> through.  I’m thinking there’s a different way to slice the topics,
> hopefully without much overlap, but that will allow a bit more focus.  No
> doubt a lot of the same people would be interested in multiple slices, but
> by limiting the scope of each conversation I’m hoping we’ll get more
> accomplished.  I daresay a lot of people interested in debug-info quality
> in general might totally tune out a DWARF-nerd discussion 
>
> The slicing could be something like this:
>
>
>
>1. Getting LLVM to do a better job of tracking info internally, so
>what gets emitted in the end is more representative of the original
>program. This should improve the debugging experience by letting the
>debugger do a better job of mapping the executing program to the original
>source, because the data it works with is more accurate/complete.
>   1. This is basically about IR/Metadata handling and representation,
>   although it might leak into things like the “is_stmt” flag, and doing
>   better with “prologue_end,” which are currently handled by AsmPrinter.
>   2. Better handling of induction variables, entry-values, variables
>   with multiple locations, etc.
>2. Changes to optimization passes/pipelines and codegen, to avoid
>borking the source-location and value/variable tracking; again this should
>improve the debugging experience by letting the debugger do a better job of
>mapping the executing program back to the original source, because that
>mapping is simpler.
>   1. This is basically about IR/MIR transforms, and is where an Og/O1
>   kind of topic would fit.
>   2. Also things like extended lifetimes, limiting code
>   motion/duplication, etc.
>3. Changing the DWARF spec itself to improve the completeness and
>efficiency of the information it contains.  This should improve the
>debugging experience by making the DWARF itself a richer information
>source, to the extent that it can describe more of what happened to the
>original program; also hopefully any efficiency improvements will allow the
>debugger to be more responsive.
>   1. This is obviously about DWARF itself, although to some extent
>   how we go about generating it.
>   2. Take better advantage of ranges and the .debug_addr table.
>   dblaikie and clayborg have put up ideas about this.
>   3. Figure out a way to allow tracking multiple source locations for
>   an individual instruction.  Right now we mostly give up and set 
> locations
>   to line-0 when this happens.
>   4. Understand the competing needs of profiling and debugging
>   consumers, and see what might be doable there.  (Although this might be
>   tough enough to be its own topic.)
>4. Debug-info testing/validation.  How do we decide what is
>“correct”?
>   1. What are the tools we have, what are they good/bad at, what’s
>   missing?
>
>
>
> I hear that round-tables can be proposed for either ~half hour or ~full
> hour, so with more focused topics we might rather have shorter sessions?
>
>
>
> Thanks,
>
> --paulr
>
>
>
> *From:* llvm-dev  *On Behalf Of *Eric
> Christopher via llvm-dev
> *Sent:* Tuesday, September 22, 2020 2:42 PM
> *To:* Cazalet-Hyams, Orlando ; LLDB Dev <
> lldb-dev@lists.llvm.org>
> *Cc:* llvm-...@lists.llvm.org
> *Subject:* Re: [llvm-dev] Optimised-code debugging experience Round Table
>
>
>
> +LLDB Dev 
>
>
>
> I'll sign up. :)
>
>
>
> My particular interests are:
>
>
>
> - Og (and O1 as Og)
>
> - Correctness testing tools
>
>
>
> Past that the rest of your list seems quite specific, but the overall
> "line tables" and "variable locations" are important.
>
>
>
> Relatedly we have a number of DWARF committee members in llvm and another
> possible discussion area could be: "what extensions do debug info consumers
> think should happen to make dwarf a better input into debugging".
>
>
>
> Thanks.
>
>
>
> -eric
>
>
>
>
>
> On Tue, Sep 22, 2020 at 8:43 AM Cazalet-Hyams, Orlando via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
> Hi all,
>
>
>
> I haven't seen a proposal for an optimised-code debugging experience Round
> Table yet so here goes!
>
> Please let me know if you are interested by emailing me at:
>
>
>
> orlando.hy...@sony.com
>
>
>
> Below is a non-exhaustive list of possible topics. Feel free to include
> any preferences and
>
> suggestions in your response.
>
>
>
>   a. Line tables:
>
> 1. Can we fix is_stmt?
>
> 2. Is prologue_end reliable?
>
> 3. General stepping 

Re: [lldb-dev] Odd output issue with lldb -s

[Greg Clayton via lldb-dev]

I would suggest using python here. You can make a new LLDB command in a python 
file and then "command script import /path/to/my/file.py". This python script 
would install a new command and you  can then just run that command. Happy to 
help you get this script working off the mailing lists if you need help.

In the python you might be able to do something a bit smarter than trying to 
subtract 24 from the PC. This if very error prone because opcodes for x86 vary 
in size and this value might be in the middle of an opcode. It might be better 
to get the function for the current PC and get its instructions in python:

>>> pc = frame.GetPCAddress()
>>> print(pc)
a.out`main + 36 [inlined] squares(int, int) at main.cpp:17
a.out`main + 36 at main.cpp:17
>>> function = pc.GetFunction()
>>> if not function.IsValid():
...   function = pc.GetSymbol()
... 
>>> print(function)
SBFunction: id = 0x7fff0122, name = main, type = main


Now "function" is either a lldb.SBFunction or lldb.SBSymbol. Both types have a 
"GetInstructions(...)" method which can be used to grab a 
lldb.SBInstructionList for all instructions in that function or symbol:

>>> instructions = function.GetInstructions(target)
>>> for instruction in instructions:
...   print(instruction)
... 
a.out[0x10f10]: pushq  %rbp
a.out[0x10f11]: movq   %rsp, %rbp
a.out[0x10f14]: subq   $0x30, %rsp
a.out[0x10f18]: movl   $0x0, -0x1c(%rbp)
a.out[0x10f1f]: movl   %edi, -0x20(%rbp)
a.out[0x10f22]: movq   %rsi, -0x28(%rbp)
a.out[0x10f26]: movl   $0xa, -0xc(%rbp)
a.out[0x10f2d]: movl   $0x14, -0x10(%rbp)
a.out[0x10f34]: movl   -0xc(%rbp), %eax
a.out[0x10f37]: movl   %eax, -0x8(%rbp)
a.out[0x10f3a]: movl   -0x8(%rbp), %eax
a.out[0x10f3d]: imull  -0x8(%rbp), %eax
a.out[0x10f41]: movl   %eax, -0x14(%rbp)
a.out[0x10f44]: movl   -0x10(%rbp), %eax
a.out[0x10f47]: movl   %eax, -0x4(%rbp)
a.out[0x10f4a]: movl   -0x4(%rbp), %eax
a.out[0x10f4d]: imull  -0x4(%rbp), %eax
a.out[0x10f51]: movl   %eax, -0x18(%rbp)
a.out[0x10f54]: movl   -0x18(%rbp), %eax
a.out[0x10f57]: addl   -0x14(%rbp), %eax
a.out[0x10f5a]: movl   %eax, -0x14(%rbp)
a.out[0x10f5d]: movl   -0x14(%rbp), %eax
a.out[0x10f60]: movl   %eax, -0x2c(%rbp)
a.out[0x10f63]: movl   -0x2c(%rbp), %esi
a.out[0x10f66]: leaq   0x35(%rip), %rdi
a.out[0x10f6d]: movb   $0x0, %al
a.out[0x10f6f]: callq  0x10f82
a.out[0x10f74]: xorl   %ecx, %ecx
a.out[0x10f76]: movl   %eax, -0x30(%rbp)
a.out[0x10f79]: movl   %ecx, %eax
a.out[0x10f7b]: addq   $0x30, %rsp
a.out[0x10f7f]: popq   %rbp
a.out[0x10f80]: retq   

Each "instruction" is a "lldb.SBInstruction" that has a "GetAddress()" method 
which returns the lldb.SBAddress for that instruction. You can compare that to 
the PC value:

>>> for instruction in instructions:
...   if instruction.GetAddress() == pc:
... print(instruction)
... 
a.out[0x10f34]: movl   -0xc(%rbp), %eax

So you can use this to find the index of the instruction that the PC is at 
within "instructions":

>>> for (i, instruction) in enumerate(instructions):
...   if instruction.GetAddress() == pc:
... print(instruction)
... break
... 
a.out[0x10f34]: movl   -0xc(%rbp), %eax
>>> print(i)
8

Now you can backup as many instructions as you want and not fear that you will 
end up in the middle of an x86 instruction.

Greg


 

> On Sep 24, 2020, at 10:30 AM, Ted Woodward via lldb-dev 
>  wrote:
> 
> I have a very simple lldb script:
>  
> thread select 1
> disassemble --start-address $pc-24 --end-address $pc+24
>  
>  
> When I run lldb with -o “process launch -s” and -s “dis.lldb”, I get odd 
> output – the disassembly from “thread select 1” and from the disassemble 
> command run together.
>  
> This is what I see with top-of-tree on Ubuntu 16:
>  
> bin/lldb /bin/ls -o "process launch -s" -s dis.lldb 
> (lldb) target create "/bin/ls"
> Current executable set to '/bin/ls' (x86_64).
> (lldb) process launch -s
> Process 32258 launched: '/bin/ls' (x86_64)
> (lldb) command source -s 0 'dis.lldb'
> Executing commands in '/local/mnt/ted/tip/full/dis.lldb'.
> (lldb) thread select 1
> (lldb) disassemble --start-address $pc-24 --end-address $pc+24
> * thread #1, name = 'ls', stop reason = signal SIGSTOP
> frame #0: 0x77dd7c30 ld-2.23.so`_start
> ld-2.23.so`_start:
> ->  0x77dd7c30 <+0>: movq   %rsp, %rdi
> 0x77dd7c33 <+3>: callq  0x77dd89b0; _dl_start at 
> rtld.c:353
>  
> ld-2.23.so`_dl_start_user:
> 0x77dd7c38 <+0>: movq   %rax, %r12
> 0x77dd7c3b <+3>: movl   0x225037(%rip), %eax  ; _dl_skip_args
> ld-

Re: [lldb-dev] Weird results running lldb under Valgrind

[Greg Clayton via lldb-dev]

This must be a valgrind issue, there would be major problems if the OS isn't 
able to lock mutex objects correctly ("mutex is locked simultaneously by two 
threads"). It is getting confused by a recursive mutex? LLDB uses recursive 
mutexes.


> On Sep 24, 2020, at 1:55 AM, Dmitry Antipov via lldb-dev 
>  wrote:
> 
> Does anyone has an explanation of this weird run of 'valgrind --tool=drd':
> 
> ==2715== drd, a thread error detector
> ==2715== Copyright (C) 2006-2017, and GNU GPL'd, by Bart Van Assche.
> ==2715== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
> ==2715== Command: /home/antipov/.local/llvm-12.0.0/bin/lldb
> ==2715== Parent PID: 1702
> 
> In LLDB, do 'process attach --pid [PID of running Firefox]', then:
> 
> ==2715== Thread 5:
> ==2715== The impossible happened: mutex is locked simultaneously by two 
> threads: mutex 0xe907d10, recursion count 1, owner 1.
> ==2715==at 0x4841015: pthread_mutex_lock_intercept 
> (drd_pthread_intercepts.c:893)
> ==2715==by 0x4841015: pthread_mutex_lock (drd_pthread_intercepts.c:903)
> ==2715==by 0x504FBEE: __gthread_mutex_lock (gthr-default.h:749)
> ==2715==by 0x504FBEE: lock (std_mutex.h:100)
> ==2715==by 0x504FBEE: lock_guard (std_mutex.h:159)
> ==2715==by 0x504FBEE: SetValue (Predicate.h:91)
> ==2715==by 0x504FBEE: 
> lldb_private::EventDataReceipt::DoOnRemoval(lldb_private::Event*) 
> (Event.h:121)
> ==2715==by 0x5113644: 
> lldb_private::Listener::FindNextEventInternal(std::unique_lock&, 
> lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, 
> unsigned int, std::shared_ptr&, bool) (Listener.cpp:309)
> ==2715==by 0x5113DD1: 
> lldb_private::Listener::GetEventInternal(lldb_private::Timeout 100l> > const&, lldb_private::Broadcaster*, lldb_private::ConstString 
> const*, unsigned int, unsigned int, std::shared_ptr&) 
> (Listener.cpp:357)
> ==2715==by 0x5113F4A: 
> lldb_private::Listener::GetEventForBroadcaster(lldb_private::Broadcaster*, 
> std::shared_ptr&, lldb_private::Timeout 100l> > const&) (Listener.cpp:395)
> ==2715==by 0x506ADD4: lldb_private::Process::RunPrivateStateThread(bool) 
> (Process.cpp:3872)
> ==2715==by 0x506B3F5: lldb_private::Process::PrivateStateThread(void*) 
> (Process.cpp:3857)
> ==2715==by 0x483DB9A: vgDrd_thread_wrapper (drd_pthread_intercepts.c:449)
> ==2715==by 0x488B3F8: start_thread (in /usr/lib64/libpthread-2.32.so)
> ==2715==by 0xDFCEA92: clone (in /usr/lib64/libc-2.32.so)
> ==2715== mutex 0xe907d10 was first observed at:
> ==2715==at 0x4840F55: pthread_mutex_lock_intercept 
> (drd_pthread_intercepts.c:890)
> ==2715==by 0x4840F55: pthread_mutex_lock (drd_pthread_intercepts.c:903)
> ==2715==by 0x5058502: __gthread_mutex_lock (gthr-default.h:749)
> ==2715==by 0x5058502: lock (std_mutex.h:100)
> ==2715==by 0x5058502: lock (unique_lock.h:138)
> ==2715==by 0x5058502: unique_lock (unique_lock.h:68)
> ==2715==by 0x5058502: 
> WaitFor::WaitForValueEqualTo:: 
> > (Predicate.h:123)
> ==2715==by 0x5058502: WaitForValueEqualTo (Predicate.h:157)
> ==2715==by 0x5058502: WaitForEventReceived (Event.h:114)
> ==2715==by 0x5058502: 
> lldb_private::Process::ControlPrivateStateThread(unsigned int) 
> (Process.cpp:3698)
> ==2715==by 0x505BC61: 
> lldb_private::Process::StartPrivateStateThread(bool) (Process.cpp:3647)
> ==2715==by 0x5065B96: 
> lldb_private::Process::Attach(lldb_private::ProcessAttachInfo&) 
> (Process.cpp:2961)
> ==2715==by 0x544DBB8: 
> PlatformPOSIX::Attach(lldb_private::ProcessAttachInfo&, 
> lldb_private::Debugger&, lldb_private::Target*, lldb_private::Status&) 
> (PlatformPOSIX.cpp:401)
> ==2715==by 0x509F531: 
> lldb_private::Target::Attach(lldb_private::ProcessAttachInfo&, 
> lldb_private::Stream*) (Target.cpp:3008)
> ==2715==by 0x54C3F17: 
> CommandObjectProcessAttach::DoExecute(lldb_private::Args&, 
> lldb_private::CommandReturnObject&) (CommandObjectProcess.cpp:386)
> ==2715==by 0x4FC0ACD: lldb_private::CommandObjectParsed::Execute(char 
> const*, lldb_private::CommandReturnObject&) (CommandObject.cpp:993)
> ==2715==by 0x4FBCBD7: 
> lldb_private::CommandInterpreter::HandleCommand(char const*, 
> lldb_private::LazyBool, lldb_private::CommandReturnObject&, 
> lldb_private::ExecutionContext*, bool, bool) (CommandInterpreter.cpp:1803)
> ==2715==by 0x4FBDB96: 
> lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&,
>  std::__cxx11::basic_string, 
> std::allocator >&) (CommandInterpreter.cpp:2838)
> ==2715==by 0x4EF21C0: lldb_private::IOHandlerEditline::Run() 
>

[lldb-dev] Odd output issue with lldb -s

[Ted Woodward via lldb-dev]

I have a very simple lldb script:

thread select 1
disassemble --start-address $pc-24 --end-address $pc+24


When I run lldb with -o "process launch -s" and -s "dis.lldb", I get odd output 
- the disassembly from "thread select 1" and from the disassemble command run 
together.

This is what I see with top-of-tree on Ubuntu 16:

bin/lldb /bin/ls -o "process launch -s" -s dis.lldb
(lldb) target create "/bin/ls"
Current executable set to '/bin/ls' (x86_64).
(lldb) process launch -s
Process 32258 launched: '/bin/ls' (x86_64)
(lldb) command source -s 0 'dis.lldb'
Executing commands in '/local/mnt/ted/tip/full/dis.lldb'.
(lldb) thread select 1
(lldb) disassemble --start-address $pc-24 --end-address $pc+24
* thread #1, name = 'ls', stop reason = signal SIGSTOP
frame #0: 0x77dd7c30 ld-2.23.so`_start
ld-2.23.so`_start:
->  0x77dd7c30 <+0>: movq   %rsp, %rdi
0x77dd7c33 <+3>: callq  0x77dd89b0; _dl_start at 
rtld.c:353

ld-2.23.so`_dl_start_user:
0x77dd7c38 <+0>: movq   %rax, %r12
0x77dd7c3b <+3>: movl   0x225037(%rip), %eax  ; _dl_skip_args
ld-2.23.so`oom:
0x77dd7c18 <+13>: xorl   %eax, %eax
0x77dd7c1a <+15>: callq  0x77de88f0; _dl_dprintf at 
dl-misc.c:275
0x77dd7c1f <+20>: movl   $0x7f, %edi
0x77dd7c24 <+25>: callq  0x77df24f0; __GI__exit at 
_exit.c:27
0x77dd7c29:   nopl   (%rax)
ld-2.23.so`_start:
->  0x77dd7c30 <+0>:  movq   %rsp, %rdi
0x77dd7c33 <+3>:  callq  0x77dd89b0; _dl_start at 
rtld.c:353

ld-2.23.so`_dl_start_user:
0x77dd7c38 <+0>:  movq   %rax, %r12
0x77dd7c3b <+3>:  movl   0x225037(%rip), %eax  ; _dl_skip_args
0x77dd7c41 <+9>:  popq   %rdx
0x77dd7c42 <+10>: leaq   (%rsp,%rax,8), %rsp
0x77dd7c46 <+14>: subl   %eax, %edx
(lldb)

Note that the address goes from c3b to c18 right after ld-2.23.so`oom.

How can I separate the outputs of thread select and disassemble? If I stick in 
something like "register read pc" in between the thread select and the dis, I 
get the output from it before the output from the thread select and dis.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] FW: [llvm-dev] Optimised-code debugging experience Round Table

[Tom Weaver via lldb-dev]

Tom Weaver will answer the councils call!

count me in, can't wait to have a good chin wag (talk for our non brit
brethren) about debug info and it's many faceted forms.

I somewhat agree with Paul's concern about discussing everything, but we
can make a judgement call on the day about what we wish to focus on the
most.

thanks for sorting this out Orlando, looking forward to it.

Tom W

On Thu, 24 Sep 2020 at 09:00, Cazalet-Hyams, Orlando via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Forwarding to lldb-dev now that I’ve signed up.
>
>
>
> *From:* llvm-dev  *On Behalf Of 
> *Cazalet-Hyams,
> Orlando via llvm-dev
> *Sent:* 24 September 2020 08:54
> *To:* Robinson, Paul ; Eric Christopher <
> echri...@gmail.com>; LLDB Dev ; '
> llvm-...@lists.llvm.org' 
> *Subject:* Re: [llvm-dev] Optimised-code debugging experience Round Table
>
>
>
> Hi Paul, Eric, lists,
>
>
> FWIW I agree with Paul here. Given the limited time available for the
> discussions I think it makes sense to split up the conversations to keep
> them focused. Though, it'd be good to coordinate non-overlapping time
> slots. As you say, it is likely that people (including me) would want to
> attend more than one of these.
>
>
> Saying that, I've only had 3 people outside of Sony express an interest in
> the Round Table that I proposed. At this rate we may not have the requisite
> numbers to split. Of course, if that number is indicative of actual turn
> out then we won't need to split anyway, but I suspect that there will be
> more attendees on the day.
>
> We must also remember that the Round Table submission deadline is tomorrow
> (tonight?). Unless more people express an interest very soon, I think we
> might need to fall back onto the single Round Table.
>
>
> Thanks,
>
> Orlando
>
> *From:* Robinson, Paul 
> *Sent:* 23 September 2020 15:21
> *To:* Eric Christopher ; Cazalet-Hyams, Orlando <
> orlando.hy...@sony.com>; LLDB Dev ; '
> llvm-...@lists.llvm.org' 
> *Subject:* RE: [llvm-dev] Optimised-code debugging experience Round Table
>
>
>
> Hi Eric & Orlando,
>
>
>
> It’s great to see interest in a lot of different aspects of debug info. At
> the same time, I’m concerned about a risk to making the topic so broad that
> we don’t have time to get through all the things people want to get
> through.  I’m thinking there’s a different way to slice the topics,
> hopefully without much overlap, but that will allow a bit more focus.  No
> doubt a lot of the same people would be interested in multiple slices, but
> by limiting the scope of each conversation I’m hoping we’ll get more
> accomplished.  I daresay a lot of people interested in debug-info quality
> in general might totally tune out a DWARF-nerd discussion 
>
> The slicing could be something like this:
>
>
>
>1. Getting LLVM to do a better job of tracking info internally, so
>what gets emitted in the end is more representative of the original
>program. This should improve the debugging experience by letting the
>debugger do a better job of mapping the executing program to the original
>source, because the data it works with is more accurate/complete.
>   1. This is basically about IR/Metadata handling and representation,
>   although it might leak into things like the “is_stmt” flag, and doing
>   better with “prologue_end,” which are currently handled by AsmPrinter.
>   2. Better handling of induction variables, entry-values, variables
>   with multiple locations, etc.
>2. Changes to optimization passes/pipelines and codegen, to avoid
>borking the source-location and value/variable tracking; again this should
>improve the debugging experience by letting the debugger do a better job of
>mapping the executing program back to the original source, because that
>mapping is simpler.
>   1. This is basically about IR/MIR transforms, and is where an Og/O1
>   kind of topic would fit.
>   2. Also things like extended lifetimes, limiting code
>   motion/duplication, etc.
>3. Changing the DWARF spec itself to improve the completeness and
>efficiency of the information it contains.  This should improve the
>debugging experience by making the DWARF itself a richer information
>source, to the extent that it can describe more of what happened to the
>original program; also hopefully any efficiency improvements will allow the
>debugger to be more responsive.
>   1. This is obviously about DWARF itself, although to some extent
>   how we go about generating it.
>   2. Take better advantage of ranges and the .debug_addr table.
>   dblaikie and clayborg have put up ideas about this.
>

[lldb-dev] Weird results running lldb under Valgrind

[Dmitry Antipov via lldb-dev]

Does anyone has an explanation of this weird run of 'valgrind --tool=drd':

==2715== drd, a thread error detector
==2715== Copyright (C) 2006-2017, and GNU GPL'd, by Bart Van Assche.
==2715== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==2715== Command: /home/antipov/.local/llvm-12.0.0/bin/lldb
==2715== Parent PID: 1702

In LLDB, do 'process attach --pid [PID of running Firefox]', then:

==2715== Thread 5:
==2715== The impossible happened: mutex is locked simultaneously by two 
threads: mutex 0xe907d10, recursion count 1, owner 1.
==2715==at 0x4841015: pthread_mutex_lock_intercept 
(drd_pthread_intercepts.c:893)
==2715==by 0x4841015: pthread_mutex_lock (drd_pthread_intercepts.c:903)
==2715==by 0x504FBEE: __gthread_mutex_lock (gthr-default.h:749)
==2715==by 0x504FBEE: lock (std_mutex.h:100)
==2715==by 0x504FBEE: lock_guard (std_mutex.h:159)
==2715==by 0x504FBEE: SetValue (Predicate.h:91)
==2715==by 0x504FBEE: 
lldb_private::EventDataReceipt::DoOnRemoval(lldb_private::Event*) (Event.h:121)
==2715==by 0x5113644: 
lldb_private::Listener::FindNextEventInternal(std::unique_lock&, 
lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, unsigned int, 
std::shared_ptr&, bool) (Listener.cpp:309)
==2715==by 0x5113DD1: 
lldb_private::Listener::GetEventInternal(lldb_private::Timeout > 
const&, lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, unsigned int, 
std::shared_ptr&) (Listener.cpp:357)
==2715==by 0x5113F4A: lldb_private::Listener::GetEventForBroadcaster(lldb_private::Broadcaster*, 
std::shared_ptr&, lldb_private::Timeout 
> const&) (Listener.cpp:395)
==2715==by 0x506ADD4: lldb_private::Process::RunPrivateStateThread(bool) 
(Process.cpp:3872)
==2715==by 0x506B3F5: lldb_private::Process::PrivateStateThread(void*) 
(Process.cpp:3857)
==2715==by 0x483DB9A: vgDrd_thread_wrapper (drd_pthread_intercepts.c:449)
==2715==by 0x488B3F8: start_thread (in /usr/lib64/libpthread-2.32.so)
==2715==by 0xDFCEA92: clone (in /usr/lib64/libc-2.32.so)
==2715== mutex 0xe907d10 was first observed at:
==2715==at 0x4840F55: pthread_mutex_lock_intercept 
(drd_pthread_intercepts.c:890)
==2715==by 0x4840F55: pthread_mutex_lock (drd_pthread_intercepts.c:903)
==2715==by 0x5058502: __gthread_mutex_lock (gthr-default.h:749)
==2715==by 0x5058502: lock (std_mutex.h:100)
==2715==by 0x5058502: lock (unique_lock.h:138)
==2715==by 0x5058502: unique_lock (unique_lock.h:68)
==2715==by 0x5058502: 
WaitFor::WaitForValueEqualTo:: > 
(Predicate.h:123)
==2715==by 0x5058502: WaitForValueEqualTo (Predicate.h:157)
==2715==by 0x5058502: WaitForEventReceived (Event.h:114)
==2715==by 0x5058502: 
lldb_private::Process::ControlPrivateStateThread(unsigned int) 
(Process.cpp:3698)
==2715==by 0x505BC61: lldb_private::Process::StartPrivateStateThread(bool) 
(Process.cpp:3647)
==2715==by 0x5065B96: 
lldb_private::Process::Attach(lldb_private::ProcessAttachInfo&) 
(Process.cpp:2961)
==2715==by 0x544DBB8: PlatformPOSIX::Attach(lldb_private::ProcessAttachInfo&, 
lldb_private::Debugger&, lldb_private::Target*, lldb_private::Status&) 
(PlatformPOSIX.cpp:401)
==2715==by 0x509F531: 
lldb_private::Target::Attach(lldb_private::ProcessAttachInfo&, 
lldb_private::Stream*) (Target.cpp:3008)
==2715==by 0x54C3F17: 
CommandObjectProcessAttach::DoExecute(lldb_private::Args&, 
lldb_private::CommandReturnObject&) (CommandObjectProcess.cpp:386)
==2715==by 0x4FC0ACD: lldb_private::CommandObjectParsed::Execute(char const*, 
lldb_private::CommandReturnObject&) (CommandObject.cpp:993)
==2715==by 0x4FBCBD7: lldb_private::CommandInterpreter::HandleCommand(char 
const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, 
lldb_private::ExecutionContext*, bool, bool) (CommandInterpreter.cpp:1803)
==2715==by 0x4FBDB96: 
lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, 
std::__cxx11::basic_string, std::allocator >&) 
(CommandInterpreter.cpp:2838)
==2715==by 0x4EF21C0: lldb_private::IOHandlerEditline::Run() 
(IOHandler.cpp:579)
==2715==by 0x4ED02B0: lldb_private::Debugger::RunIOHandlers() 
(Debugger.cpp:861)

Hopefully this is an issue with valgrind and not lldb. But still curious 
whether someone else can reproduce something similar.

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

[lldb-dev] FW: [llvm-dev] Optimised-code debugging experience Round Table

[Cazalet-Hyams, Orlando via lldb-dev]

Forwarding to lldb-dev now that I’ve signed up.

From: llvm-dev  On Behalf Of Cazalet-Hyams, 
Orlando via llvm-dev
Sent: 24 September 2020 08:54
To: Robinson, Paul ; Eric Christopher 
; LLDB Dev ; 
'llvm-...@lists.llvm.org' 
Subject: Re: [llvm-dev] Optimised-code debugging experience Round Table

Hi Paul, Eric, lists,

FWIW I agree with Paul here. Given the limited time available for the 
discussions I think it makes sense to split up the conversations to keep them 
focused. Though, it'd be good to coordinate non-overlapping time slots. As you 
say, it is likely that people (including me) would want to attend more than one 
of these.

Saying that, I've only had 3 people outside of Sony express an interest in the 
Round Table that I proposed. At this rate we may not have the requisite numbers 
to split. Of course, if that number is indicative of actual turn out then we 
won't need to split anyway, but I suspect that there will be more attendees on 
the day.
We must also remember that the Round Table submission deadline is tomorrow 
(tonight?). Unless more people express an interest very soon, I think we might 
need to fall back onto the single Round Table.

Thanks,
Orlando
From: Robinson, Paul mailto:paul.robin...@sony.com>>
Sent: 23 September 2020 15:21
To: Eric Christopher mailto:echri...@gmail.com>>; 
Cazalet-Hyams, Orlando mailto:orlando.hy...@sony.com>>; 
LLDB Dev mailto:lldb-dev@lists.llvm.org>>; 
'llvm-...@lists.llvm.org' 
mailto:llvm-...@lists.llvm.org>>
Subject: RE: [llvm-dev] Optimised-code debugging experience Round Table

Hi Eric & Orlando,

It’s great to see interest in a lot of different aspects of debug info. At the 
same time, I’m concerned about a risk to making the topic so broad that we 
don’t have time to get through all the things people want to get through.  I’m 
thinking there’s a different way to slice the topics, hopefully without much 
overlap, but that will allow a bit more focus.  No doubt a lot of the same 
people would be interested in multiple slices, but by limiting the scope of 
each conversation I’m hoping we’ll get more accomplished.  I daresay a lot of 
people interested in debug-info quality in general might totally tune out a 
DWARF-nerd discussion 
The slicing could be something like this:


  1.  Getting LLVM to do a better job of tracking info internally, so what gets 
emitted in the end is more representative of the original program. This should 
improve the debugging experience by letting the debugger do a better job of 
mapping the executing program to the original source, because the data it works 
with is more accurate/complete.
 *   This is basically about IR/Metadata handling and representation, 
although it might leak into things like the “is_stmt” flag, and doing better 
with “prologue_end,” which are currently handled by AsmPrinter.
 *   Better handling of induction variables, entry-values, variables with 
multiple locations, etc.
  2.  Changes to optimization passes/pipelines and codegen, to avoid borking 
the source-location and value/variable tracking; again this should improve the 
debugging experience by letting the debugger do a better job of mapping the 
executing program back to the original source, because that mapping is simpler.
 *   This is basically about IR/MIR transforms, and is where an Og/O1 kind 
of topic would fit.
 *   Also things like extended lifetimes, limiting code motion/duplication, 
etc.
  3.  Changing the DWARF spec itself to improve the completeness and efficiency 
of the information it contains.  This should improve the debugging experience 
by making the DWARF itself a richer information source, to the extent that it 
can describe more of what happened to the original program; also hopefully any 
efficiency improvements will allow the debugger to be more responsive.
 *   This is obviously about DWARF itself, although to some extent how we 
go about generating it.
 *   Take better advantage of ranges and the .debug_addr table.  dblaikie 
and clayborg have put up ideas about this.
 *   Figure out a way to allow tracking multiple source locations for an 
individual instruction.  Right now we mostly give up and set locations to 
line-0 when this happens.
 *   Understand the competing needs of profiling and debugging consumers, 
and see what might be doable there.  (Although this might be tough enough to be 
its own topic.)
  4.  Debug-info testing/validation.  How do we decide what is “correct”?
 *   What are the tools we have, what are they good/bad at, what’s missing?

I hear that round-tables can be proposed for either ~half hour or ~full hour, 
so with more focused topics we might rather have shorter sessions?

Thanks,
--paulr

From: llvm-dev 
mailto:llvm-dev-boun...@lists.llvm.org>> On 
Behalf Of Eric Christopher via llvm-dev
Sent: Tuesday, September 22, 2020 2:42 PM
To: Cazalet-Hyams, Orlando 
mailto:orlando.hy...@sony.com>>; LLDB Dev 
mailto:lldb-dev@lists.llvm.org>>
Cc: 

Re: [lldb-dev] [Release-testers] [11.0.0 Release] Release Candidate 3 is here

[Dimitry Andric via lldb-dev]

On 22 Sep 2020, at 17:12, Hans Wennborg via Release-testers 
 wrote:
> 
> After some delay, the llvmorg-11.0.0-rc3 tag was just created.

This rc3, like rc2, I could finally build and test without adding any
patches! :)

Main results on amd64-freebsd11:

  Unsupported:  5122 (rc2:  5121)
  Passed : 69761 (rc2: 69739)
  Expectedly Failed  :   245 (rc2:   245)
  Timed Out  :16 (rc2:16)
  Failed :   480 (rc2:   481)
  Unexpectedly Passed: 2 (rc2: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc2: 2399)
  Failed:3 (rc2:3)

Main results on i386-freebsd11:

  Unsupported:  3513 (rc2:  3512)
  Passed : 66636 (rc2: 66614)
  Expectedly Failed  :   230 (rc2:   230)
  Timed Out  : 7 (rc2: 7)
  Failed :   321 (rc2:   322)
  Unexpectedly Passed: 1 (rc2: 1)

Uploaded:
SHA256 (clang+llvm-11.0.0-rc3-amd64-unknown-freebsd11.tar.xz) = 
8ef0c820ff9865d54c2d2b79abc0aae3ca584218a3f90a31487590a90f398a26
SHA256 (clang+llvm-11.0.0-rc3-i386-unknown-freebsd11.tar.xz) = 
17e9f4bafbd34de102f0e8530ca154a57fa205cd183f402b366f873f3607f55b

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [11.0.0 Release] Release Candidate 3 is here

[Michał Górny via lldb-dev]

On Tue, 2020-09-22 at 17:12 +0200, Hans Wennborg via Release-testers
wrote:
> Hello everyone,
> 
> After some delay, the llvmorg-11.0.0-rc3 tag was just created.
> 
> Source code and docs are available at
> https://prereleases.llvm.org/11.0.0/#rc3
> and
> https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc3
> 
> Pre-built binaries will be added as they become ready.
> 
> Please file bug reports for any issues you find as blockers of
> https://llvm.org/pr46725
> 
> Release testers: please start your engines, run the script, share your
> results, and upload binaries. And thank you very much for your help so
> far.
> 
> There are currently no open release blockers, so unless anything new
> and bad comes up, this is what the final release will look like.
> 

Nothing really new on Gentoo end.  It seems that a few clangd and one
lld test failed when old version was installed on the system
but I suppose it's not important enough to care about it right now.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Optimised-code debugging experience Round Table

[Robinson, Paul via lldb-dev]

Hi Eric & Orlando,

It’s great to see interest in a lot of different aspects of debug info. At the 
same time, I’m concerned about a risk to making the topic so broad that we 
don’t have time to get through all the things people want to get through.  I’m 
thinking there’s a different way to slice the topics, hopefully without much 
overlap, but that will allow a bit more focus.  No doubt a lot of the same 
people would be interested in multiple slices, but by limiting the scope of 
each conversation I’m hoping we’ll get more accomplished.  I daresay a lot of 
people interested in debug-info quality in general might totally tune out a 
DWARF-nerd discussion 
The slicing could be something like this:


  1.  Getting LLVM to do a better job of tracking info internally, so what gets 
emitted in the end is more representative of the original program. This should 
improve the debugging experience by letting the debugger do a better job of 
mapping the executing program to the original source, because the data it works 
with is more accurate/complete.
 *   This is basically about IR/Metadata handling and representation, 
although it might leak into things like the “is_stmt” flag, and doing better 
with “prologue_end,” which are currently handled by AsmPrinter.
 *   Better handling of induction variables, entry-values, variables with 
multiple locations, etc.
  2.  Changes to optimization passes/pipelines and codegen, to avoid borking 
the source-location and value/variable tracking; again this should improve the 
debugging experience by letting the debugger do a better job of mapping the 
executing program back to the original source, because that mapping is simpler.
 *   This is basically about IR/MIR transforms, and is where an Og/O1 kind 
of topic would fit.
 *   Also things like extended lifetimes, limiting code motion/duplication, 
etc.
  3.  Changing the DWARF spec itself to improve the completeness and efficiency 
of the information it contains.  This should improve the debugging experience 
by making the DWARF itself a richer information source, to the extent that it 
can describe more of what happened to the original program; also hopefully any 
efficiency improvements will allow the debugger to be more responsive.
 *   This is obviously about DWARF itself, although to some extent how we 
go about generating it.
 *   Take better advantage of ranges and the .debug_addr table.  dblaikie 
and clayborg have put up ideas about this.
 *   Figure out a way to allow tracking multiple source locations for an 
individual instruction.  Right now we mostly give up and set locations to 
line-0 when this happens.
 *   Understand the competing needs of profiling and debugging consumers, 
and see what might be doable there.  (Although this might be tough enough to be 
its own topic.)
  4.  Debug-info testing/validation.  How do we decide what is “correct”?
 *   What are the tools we have, what are they good/bad at, what’s missing?

I hear that round-tables can be proposed for either ~half hour or ~full hour, 
so with more focused topics we might rather have shorter sessions?

Thanks,
--paulr

From: llvm-dev  On Behalf Of Eric Christopher 
via llvm-dev
Sent: Tuesday, September 22, 2020 2:42 PM
To: Cazalet-Hyams, Orlando ; LLDB Dev 

Cc: llvm-...@lists.llvm.org
Subject: Re: [llvm-dev] Optimised-code debugging experience Round Table

+LLDB Dev

I'll sign up. :)

My particular interests are:

- Og (and O1 as Og)
- Correctness testing tools

Past that the rest of your list seems quite specific, but the overall "line 
tables" and "variable locations" are important.

Relatedly we have a number of DWARF committee members in llvm and another 
possible discussion area could be: "what extensions do debug info consumers 
think should happen to make dwarf a better input into debugging".

Thanks.

-eric


On Tue, Sep 22, 2020 at 8:43 AM Cazalet-Hyams, Orlando via llvm-dev 
mailto:llvm-...@lists.llvm.org>> wrote:
Hi all,

I haven't seen a proposal for an optimised-code debugging experience Round 
Table yet so here goes!
Please let me know if you are interested by emailing me at:

orlando.hy...@sony.com

Below is a non-exhaustive list of possible topics. Feel free to include any 
preferences and
suggestions in your response.

  a. Line tables:
1. Can we fix is_stmt?
2. Is prologue_end reliable?
3. General stepping behaviour/quality.

  b. Variable locations:
1. The state of DW_OP_entry_values in llvm.
2. The state of the instruction-referencing DBG_VALUE work.
3. The state of multi-register DWARF expressions in llvm.
4. The possibility of salvaging out-of-liveness values using the 3 projects 
mentioned above.
5. Floating point debug-info quality in llvm.
6. Loop induction variable locations.

  c. Testing debug-info:
1. Variable correctness testing tools.
2. Location coverage testing 

Re: [lldb-dev] [llvm-dev] Optimised-code debugging experience Round Table

[Eric Christopher via lldb-dev]

+LLDB Dev 

I'll sign up. :)

My particular interests are:

- Og (and O1 as Og)
- Correctness testing tools

Past that the rest of your list seems quite specific, but the overall "line
tables" and "variable locations" are important.

Relatedly we have a number of DWARF committee members in llvm and another
possible discussion area could be: "what extensions do debug info consumers
think should happen to make dwarf a better input into debugging".

Thanks.

-eric


On Tue, Sep 22, 2020 at 8:43 AM Cazalet-Hyams, Orlando via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> Hi all,
>
>
>
> I haven't seen a proposal for an optimised-code debugging experience Round
> Table yet so here goes!
>
> Please let me know if you are interested by emailing me at:
>
>
>
> orlando.hy...@sony.com
>
>
>
> Below is a non-exhaustive list of possible topics. Feel free to include
> any preferences and
>
> suggestions in your response.
>
>
>
>   a. Line tables:
>
> 1. Can we fix is_stmt?
>
> 2. Is prologue_end reliable?
>
> 3. General stepping behaviour/quality.
>
>
>
>   b. Variable locations:
>
> 1. The state of DW_OP_entry_values in llvm.
>
> 2. The state of the instruction-referencing DBG_VALUE work.
>
> 3. The state of multi-register DWARF expressions in llvm.
>
> 4. The possibility of salvaging out-of-liveness values using the 3
> projects mentioned above.
>
> 5. Floating point debug-info quality in llvm.
>
> 6. Loop induction variable locations.
>
>
>
>   c. Testing debug-info:
>
> 1. Variable correctness testing tools.
>
> 2. Location coverage testing tools.
>
>
>
>   d. The state of -Og.
>
>
>
> Please respond before Friday (25th) if you are interested as that is the
> submission deadline.
>
>
>
> Thanks,
>
> Orlando
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [11.0.0 Release] Release Candidate 3 is here

[Hans Wennborg via lldb-dev]

Hello everyone,

After some delay, the llvmorg-11.0.0-rc3 tag was just created.

Source code and docs are available at
https://prereleases.llvm.org/11.0.0/#rc3
and
https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc3

Pre-built binaries will be added as they become ready.

Please file bug reports for any issues you find as blockers of
https://llvm.org/pr46725

Release testers: please start your engines, run the script, share your
results, and upload binaries. And thank you very much for your help so
far.

There are currently no open release blockers, so unless anything new
and bad comes up, this is what the final release will look like.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

[Walter via lldb-dev]

Thanks for your feedback Fangrui, I've just been checking Capn' Proto and
it looks really good. I'll keep it in mind in the design and see how it can
optimize the overall data transfer.

- Walter

Il giorno dom 20 set 2020 alle ore 11:24 Fangrui Song 
ha scritto:

> On 2020-09-18, Eric Christopher via lldb-dev wrote:
> >Hi Walter,
> >
> >I've only done a brief scan of the document but, in general, I'm favorable
> >of the goals, aim, and approach. Something I think would be good would be
> >to compare/contrast against rr as an "exploring alternatives" section of
> >the document. I think the document should also be made available/adapted
> to
> >be part of the documentation on "why lldb is implementing this
> feature/what
> >it can be used for/why".
> >
> >Thanks so much for starting this and looking forward to the work and
> >collaboration.
> >
> >-eric
>
> Same. I am really excited that this work will open up possibilities for
> reverse debugging, which is the most important factor impeding me from
> migrating (from gdb) to lldb :)
>
> For unit tests, a json format tracing record is probably convenient, but
> for practical usage we may need a compacter format, e.g. Cap'n Proto
> used by rr
> (https://robert.ocallahan.org/2017/08/stabilizing-rr-trace-format.html)
> Hope the framework can be easily adapted to such a compact format.
>
> >On Thu, Sep 17, 2020 at 8:28 PM Walter via lldb-dev <
> lldb-dev@lists.llvm.org>
> >wrote:
> >
> >> Hi all,
> >>
> >>
> >>
> >> Here I propose, along with Greg Clayton, Processor Trace support for
> LLDB. I’m attaching a link to the document that contains this proposal if
> that’s easier to read for you:
> https://docs.google.com/document/d/1cOVTGp1sL_HBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI/edit#heading=h.t5mblb9ugv8f
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1cOVTGp1sL-5FHBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI_edit-23heading-3Dh.t5mblb9ugv8f=DwMGaQ=5VD0RTtNlTh3ycd41b3MUw=erxV6KMIZvIQjyWYW8YpOiKz-WqJt4giKQA34YMHsRY=DuuwXHUQJpW4TcCay4hPsBund-eBI2uVaVimqEPsp5k=o6vqoYYbn-Tz_d34hoLJvWhEnnhracOO6yDsMzq8wR0=>.
> Please make any comments in this mail list.
> >>
> >>
> >>
> >> If you want to quickly know what Processor Trace can do, you can read
> this https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__easyperf.net_blog_2019_08_23_Intel-2DProcessor-2DTrace=DwMGaQ=5VD0RTtNlTh3ycd41b3MUw=erxV6KMIZvIQjyWYW8YpOiKz-WqJt4giKQA34YMHsRY=DuuwXHUQJpW4TcCay4hPsBund-eBI2uVaVimqEPsp5k=iaErHaf8byXlZb1YFUk0BpQ-duMhNouUUMyktLm3soQ=
> >.
> >>
> >>
> >>
> >> Any comments are appreciated, especially the ones regarding the
> commands the user will interact with.
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Walter Erquinigo.
> >>
> >>
> >>
> >>
> >>
> >> # RFC: Processor Trace Support in LLDB
> >>
> >>
> >>
> >>
> >>
> >> # What is processor tracing?
> >>
> >>
> >>
> >> Processor tracing works by capturing information about the execution of
> a process so that the control flow of the program can be reconstructed
> later. Implementations of this are Intel Processor Trace for X86, x86_64 ([
> https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html](https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html))
> and ARM CoreSight for some ARM devices ([
> https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace](https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace)
> ).
> >>
> >>
> >>
> >> As a clarifying example, with these technologies it’s possible to trace
> all the threads of a process, and after the process has finished,
> reconstruct every single instruction address each thread has executed. This
> could include some additional information like timestamps, async CPU
> events, kernel instructions, bus clock ratio changes, etc. On the other
> hand, memory and registers are not traced as a way to limit the size of the
> trace.
> >>
> >>
> >>
> >>
> >>
> >> # Intel Processor Trace as the first implementation
> >>
> >>
> >>
> >> We’ll focus on Intel Processor Trace (Intel PT), but in a generic way
> so that in the future similar technologies can be onboarded in LLDB.
> >>
> >>
> >>
> >> Intel PT has the following fea

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

[Walter via lldb-dev]

Hi Eric, thanks for the feedback
> Something I think would be good would be to compare/contrast against rr
as an "exploring alternatives" section of the document.

I'll include that. I've done some comparative research on rr and I think I
can provide valuable input.

> I think the document should also be made available/adapted to be part of
the documentation on "why lldb is implementing this feature/what it can be
used for/why".

I think this information is scattered throughout the document, but I'll
make sure to answer this in one of the first paragraphs.

Thanks!
- Walter

Il giorno ven 18 set 2020 alle ore 19:58 Eric Christopher <
echri...@gmail.com> ha scritto:

> Hi Walter,
>
> I've only done a brief scan of the document but, in general, I'm favorable
> of the goals, aim, and approach. Something I think would be good would be
> to compare/contrast against rr as an "exploring alternatives" section of
> the document. I think the document should also be made available/adapted to
> be part of the documentation on "why lldb is implementing this feature/what
> it can be used for/why".
>
> Thanks so much for starting this and looking forward to the work and
> collaboration.
>
> -eric
>
> On Thu, Sep 17, 2020 at 8:28 PM Walter via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi all,
>>
>>
>>
>> Here I propose, along with Greg Clayton, Processor Trace support for LLDB. 
>> I’m attaching a link to the document that contains this proposal if that’s 
>> easier to read for you: 
>> https://docs.google.com/document/d/1cOVTGp1sL_HBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI/edit#heading=h.t5mblb9ugv8f
>>  
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1cOVTGp1sL-5FHBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI_edit-23heading-3Dh.t5mblb9ugv8f=DwMGaQ=5VD0RTtNlTh3ycd41b3MUw=erxV6KMIZvIQjyWYW8YpOiKz-WqJt4giKQA34YMHsRY=DuuwXHUQJpW4TcCay4hPsBund-eBI2uVaVimqEPsp5k=o6vqoYYbn-Tz_d34hoLJvWhEnnhracOO6yDsMzq8wR0=>.
>>  Please make any comments in this mail list.
>>
>>
>>
>> If you want to quickly know what Processor Trace can do, you can read this 
>> https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace 
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__easyperf.net_blog_2019_08_23_Intel-2DProcessor-2DTrace=DwMGaQ=5VD0RTtNlTh3ycd41b3MUw=erxV6KMIZvIQjyWYW8YpOiKz-WqJt4giKQA34YMHsRY=DuuwXHUQJpW4TcCay4hPsBund-eBI2uVaVimqEPsp5k=iaErHaf8byXlZb1YFUk0BpQ-duMhNouUUMyktLm3soQ=>.
>>
>>
>>
>> Any comments are appreciated, especially the ones regarding the commands the 
>> user will interact with.
>>
>>
>>
>> Thanks,
>>
>> Walter Erquinigo.
>>
>>
>>
>>
>>
>> # RFC: Processor Trace Support in LLDB
>>
>>
>>
>>
>>
>> # What is processor tracing?
>>
>>
>>
>> Processor tracing works by capturing information about the execution of a 
>> process so that the control flow of the program can be reconstructed later. 
>> Implementations of this are Intel Processor Trace for X86, x86_64 
>> ([https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html](https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html))
>>  and ARM CoreSight for some ARM devices 
>> ([https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace](https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace)).
>>
>>
>>
>> As a clarifying example, with these technologies it’s possible to trace all 
>> the threads of a process, and after the process has finished, reconstruct 
>> every single instruction address each thread has executed. This could 
>> include some additional information like timestamps, async CPU events, 
>> kernel instructions, bus clock ratio changes, etc. On the other hand, memory 
>> and registers are not traced as a way to limit the size of the trace.
>>
>>
>>
>>
>>
>> # Intel Processor Trace as the first implementation
>>
>>
>>
>> We’ll focus on Intel Processor Trace (Intel PT), but in a generic way so 
>> that in the future similar technologies can be onboarded in LLDB.
>>
>>
>>
>> Intel PT has the following features:
>>
>>
>>
>>
>>
>>
>>
>> *   Control flow tracing in a highly encoded format
>>
>> *   3% to 5% slowdown when capturing
>>
>> *   No memory nor registers captured
>>
>> *   Kernel tracing support
>>
>> *   Timestamps of branches are produced, which can be used for profiling
>>
>> *   A

[lldb-dev] LLDB got SIGCHLD on hitting the breakpoint

[le wang via lldb-dev]

Hello,everyone:
I've got a problem, when debugging my process with lldb tool on linux
OS(CentOS7).While I use lldb command to set breakpoints, and launch my
process, my process will execute a binary code which contains debug
information, but when my process launched, all breakpoints can not be hit,
The debug process and several received informations like below:
（lldb）target create  /home/out/lib/linux64/Debug/appEngine
Current executable set to '/home/out/lib/linux64/Debug/appEngine'  (x86_64)

（lldb）br s -f /home/out/lib/linux64/Debug/configDB/TestFunctionProcess.cpp
-l1
Breakpoint 1: no locations(pending).
WARNING :  Unable to resolve breakpoint to any actual locations.
（lldb）br s -f /home/out/lib/linux64/Debug/configDB/TestFunctionProcess.cpp
-l2
Breakpoint 2: no locations(pending).
WARNING :  Unable to resolve breakpoint to any actual locations.
（lldb）r
Process 4256 launched: '/home/out/lib/linux64/Debug/appEngine'  (x86_64)

Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
Process 4256 stopped and restarted: thread2 received signal:   SIGCHLD

Process stopped and restarted: thread 2 received signal: SIGCHLD
It seems these repeated restart notifications come from lldb, and at last
although my process is executed,  it is meaningless. I have checked that
debug information in IR is correct. I have no idea the reason. Can anyone
tell me the reason and how to fix this problem. My lldb version is 5.0.0,
which got from http://www.llvm.org/ with llvm5.0.0


Thanks,
le wang
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

[Fangrui Song via lldb-dev]

On 2020-09-18, Eric Christopher via lldb-dev wrote:

Hi Walter,

I've only done a brief scan of the document but, in general, I'm favorable
of the goals, aim, and approach. Something I think would be good would be
to compare/contrast against rr as an "exploring alternatives" section of
the document. I think the document should also be made available/adapted to
be part of the documentation on "why lldb is implementing this feature/what
it can be used for/why".

Thanks so much for starting this and looking forward to the work and
collaboration.

-eric


Same. I am really excited that this work will open up possibilities for
reverse debugging, which is the most important factor impeding me from
migrating (from gdb) to lldb :)

For unit tests, a json format tracing record is probably convenient, but
for practical usage we may need a compacter format, e.g. Cap'n Proto
used by rr
(https://robert.ocallahan.org/2017/08/stabilizing-rr-trace-format.html)
Hope the framework can be easily adapted to such a compact format.


On Thu, Sep 17, 2020 at 8:28 PM Walter via lldb-dev 
wrote:


Hi all,



Here I propose, along with Greg Clayton, Processor Trace support for LLDB. I’m attaching a link to the 
document that contains this proposal if that’s easier to read for you: 
https://docs.google.com/document/d/1cOVTGp1sL_HBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI/edit#heading=h.t5mblb9ugv8f 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1cOVTGp1sL-5FHBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI_edit-23heading-3Dh.t5mblb9ugv8f=DwMGaQ=5VD0RTtNlTh3ycd41b3MUw=erxV6KMIZvIQjyWYW8YpOiKz-WqJt4giKQA34YMHsRY=DuuwXHUQJpW4TcCay4hPsBund-eBI2uVaVimqEPsp5k=o6vqoYYbn-Tz_d34hoLJvWhEnnhracOO6yDsMzq8wR0=>.
 Please make any comments in this mail list.



If you want to quickly know what Processor Trace can do, you can read this 
https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__easyperf.net_blog_2019_08_23_Intel-2DProcessor-2DTrace=DwMGaQ=5VD0RTtNlTh3ycd41b3MUw=erxV6KMIZvIQjyWYW8YpOiKz-WqJt4giKQA34YMHsRY=DuuwXHUQJpW4TcCay4hPsBund-eBI2uVaVimqEPsp5k=iaErHaf8byXlZb1YFUk0BpQ-duMhNouUUMyktLm3soQ=>.



Any comments are appreciated, especially the ones regarding the commands the 
user will interact with.



Thanks,

Walter Erquinigo.





# RFC: Processor Trace Support in LLDB





# What is processor tracing?



Processor tracing works by capturing information about the execution of a 
process so that the control flow of the program can be reconstructed later. 
Implementations of this are Intel Processor Trace for X86, x86_64 
([https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html](https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html))
 and ARM CoreSight for some ARM devices 
([https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace](https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace)).



As a clarifying example, with these technologies it’s possible to trace all the 
threads of a process, and after the process has finished, reconstruct every 
single instruction address each thread has executed. This could include some 
additional information like timestamps, async CPU events, kernel instructions, 
bus clock ratio changes, etc. On the other hand, memory and registers are not 
traced as a way to limit the size of the trace.





# Intel Processor Trace as the first implementation



We’ll focus on Intel Processor Trace (Intel PT), but in a generic way so that 
in the future similar technologies can be onboarded in LLDB.



Intel PT has the following features:







*   Control flow tracing in a highly encoded format

*   3% to 5% slowdown when capturing

*   No memory nor registers captured

*   Kernel tracing support

*   Timestamps of branches are produced, which can be used for profiling

*   Adjustable size of trace buffer

*   Supported on most Intel CPUs since 2015

*   X86 and x86_64 only

*   Official support only on Linux

*   Basic support on Windows

*   Decoding/analysis can be done on any operating system



A very nice introduction to Intel PT can be found 
[https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html](https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html)
 and 
[https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace](https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace).
 Totally recommended to fully grasp the impact of this project.



More technical details are in 
[https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/perf-intel-pt.txt](https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/perf-intel-pt.txt).



Even more technical details are in the processor manual 
[https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3c-part-3-manual.pdf](https://www.

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

[Vedant Kumar via lldb-dev]

Hi Walter & Greg,

Thanks for sharing this RFC, and for your work in this area.

> On Sep 17, 2020, at 5:28 PM, Walter via lldb-dev  
> wrote:
> 
> Hi all,
>  
> Here I propose, along with Greg Clayton, Processor Trace support for LLDB. 
> I’m attaching a link to the document that contains this proposal if that’s 
> easier to read for you: 
> https://docs.google.com/document/d/1cOVTGp1sL_HBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI/edit#heading=h.t5mblb9ugv8f
>  
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1cOVTGp1sL-5FHBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI_edit-23heading-3Dh.t5mblb9ugv8f=DwMGaQ=5VD0RTtNlTh3ycd41b3MUw=erxV6KMIZvIQjyWYW8YpOiKz-WqJt4giKQA34YMHsRY=DuuwXHUQJpW4TcCay4hPsBund-eBI2uVaVimqEPsp5k=o6vqoYYbn-Tz_d34hoLJvWhEnnhracOO6yDsMzq8wR0=>.
>  Please make any comments in this mail list.
>  
>  
> If you want to quickly know what Processor Trace can do, you can read this 
> https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__easyperf.net_blog_2019_08_23_Intel-2DProcessor-2DTrace=DwMGaQ=5VD0RTtNlTh3ycd41b3MUw=erxV6KMIZvIQjyWYW8YpOiKz-WqJt4giKQA34YMHsRY=DuuwXHUQJpW4TcCay4hPsBund-eBI2uVaVimqEPsp5k=iaErHaf8byXlZb1YFUk0BpQ-duMhNouUUMyktLm3soQ=>.
>  
> Any comments are appreciated, especially the ones regarding the commands the 
> user will interact with. 
>  
> Thanks,
> Walter Erquinigo.
>  
>  
> # RFC: Processor Trace Support in LLDB
>  
>  
> # What is processor tracing?
>  
> Processor tracing works by capturing information about the execution of a 
> process so that the control flow of the program can be reconstructed later. 
> Implementations of this are Intel Processor Trace for X86, x86_64 
> ([https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html](https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html)
>  
> <https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html](https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html)>)
>  and ARM CoreSight for some ARM devices 
> ([https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace](https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace)
>  
> <https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace](https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace)>).
>  
>  
> As a clarifying example, with these technologies it’s possible to trace all 
> the threads of a process, and after the process has finished, reconstruct 
> every single instruction address each thread has executed. This could include 
> some additional information like timestamps, async CPU events, kernel 
> instructions, bus clock ratio changes, etc. On the other hand, memory and 
> registers are not traced as a way to limit the size of the trace.
>  
>  
> # Intel Processor Trace as the first implementation
>  
> We’ll focus on Intel Processor Trace (Intel PT), but in a generic way so that 
> in the future similar technologies can be onboarded in LLDB.
>  
> Intel PT has the following features:
>  
>  
>  
> *   Control flow tracing in a highly encoded format
> *   3% to 5% slowdown when capturing
> *   No memory nor registers captured
> *   Kernel tracing support
> *   Timestamps of branches are produced, which can be used for profiling
> *   Adjustable size of trace buffer
> *   Supported on most Intel CPUs since 2015
> *   X86 and x86_64 only
> *   Official support only on Linux
> *   Basic support on Windows
> *   Decoding/analysis can be done on any operating system
>  
> A very nice introduction to Intel PT can be found 
> [https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html](https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html)
>  
> <https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html](https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html)>
>  and 
> [https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace](https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace)
>  
> <https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace](https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace)>.
>  Totally recommended to fully grasp the impact of this project. 
>  
> More technical details are in 
> [https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/perf-intel-pt.txt](https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/perf-intel-pt.txt)
>  
> <https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/perf-intel-pt.txt](https://github.com/torvalds/li

Re: [lldb-dev] [Release-testers] [11.0.0 Release] Please help writing release notes!

[Ahsan Saghir via lldb-dev]

Hi Hans,
 Here are the PowerPC release notes for 11.0.0:

Optimization:

   - Improved Loop Unroll-and-Jam legality checks, allowing it to handle
   more than two level loop nests
   - Improved Loop Unroll to be able to unroll more loops
   - Implemented an option to allow loop fusion to work on loops with
   different constant trip counts

Codegen:

   - POWER10 support
  - Added PC Relative addressing
  - Added __int128 vector bool support
   - Security enhancement via probe-stack attribute support to protect
   against stack clash
   - Floating point support enhancements
  - Improved half precision and quad precision support, including GLIBC
  - constrained FP operation support for arithmetic/rounding/max/min
  - cleaning up fast math flags checks in DAGCombine, Legalizer, and
  Lowering
   - Performance improvements from instruction exploitation, especially for
   vector permute on LE
   - Scheduling enhancements
  - Added MacroFusion for POWER8
  - Added post-ra heuristics for POWER9
   - Target dependent passes tuning
  - Updated LoopStrengthReduce to use instruction number as first
  priority
  - Enhanced MachineCombiner to expose more ILP
   - Code quality and maintenance enhancements
  - Enabled more machine verification passes
  - Added ability to parse and emit additional extended mnemonics
  - Numerous bug fixes

AIX Support Improvements:

   - Enabled compile and link such that a simple  "Hello World"
   program works with standard headers
   - Added support for the C calling convention for non-vector code
   - Implemented correct stack frame layout for functions
   - In llvm-objdump, added support for relocations, improved selection of
   symbol labels, and added the --symbol-description option


Thanks,

Regards,
Ahsan Saghir.

On Tue, 25 Aug 2020 at 14:00, Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:

> Hello everyone,
>
> With the release drawing near, it would be great to get the release
> notes into better shape.
>
> You can see the notes from rc2 online here:
> https://prereleases.llvm.org/11.0.0/#rc2
>
> The release notes are typically the first thing people look at after
> the release, so it's a great opportunity to highlight the work that's
> been done since the last release.
>
> If you can think of anything interesting that happened over the last
> six months, please consider adding to the notes by sending me a patch,
> committing directly to the notes on the release/11.x branch, or just
> sending me some text in an email.
>
> Thanks,
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 47528] New: LLDB isn't checking signatures when loading modules from a minidump

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47528

Bug ID: 47528
   Summary: LLDB isn't checking signatures when loading modules
from a minidump
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: amcca...@google.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

When loading a minidump for post-mortem debugging, LLDB may select the wrong
executable as the target because it checks only file names rather then
signatures, timestamps, etc.  (Also applies to other modules, like DLLs.)

For example, given a minidump from a crashed `C:\Program Files\foo.exe` on a
user's machine, loading that minidump in LLDB in a developer machine might load
a local `foo.exe` simply because it happens to have the same path, even if it
is a different version of the program.

The local one should be rejected based on signature (UUID) and/or other version
information stored in the minidump.  Once rejected, LLDB should continue
searching for a matching binary until it finds one that matches or exhausts all
the locations to be searched.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 47524] New: Calling functions with a null pointer-to-typedef-of-anonymous-struct argument fail

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47524

Bug ID: 47524
   Summary: Calling functions with a null
pointer-to-typedef-of-anonymous-struct argument fail
   Product: lldb
   Version: 11.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: ja...@google.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

The LLDB expression evaluator fails to evaluate a function call
with a null argument of the pointer to typedef of anonymous struct type.
See below for detailed repro steps. The error message is:

```
error: function 'f' is used but not defined in this translation unit, and
cannot be defined in any other translation unit because its type does not have
linkage
```

The problem reproduces on the latest master as well as on LLDB 9 and 10 (have
not tried 11). 

It is also interesting to note that the problem goes away after the first
evaluation of the function call with non-null argument (as shown in the
example below). The problem also goes away if I make the struct non-anonymous.

```
$ cat a.cc
typedef struct {
  int f;
} S;

S s;

int f(S* s) {
  return s == nullptr;
}

int main() {
  return f(nullptr);  // break here, evaluate `f(nullptr)`
}

$ clang -g a.cc
$ lldb --version
lldb version 12.0.0
  clang revision 687e1d7121645d23aa5e919ed4d3c0e57af975cd
  llvm revision 687e1d7121645d23aa5e919ed4d3c0e57af975cd
$ lldb a.out
...
(lldb) b main
...
(lldb) r
...
-> 12 return f(nullptr);
...
(lldb) p f(nullptr)
error: error: function 'f' is used but not defined in this translation unit,
and cannot be defined in any other translation unit because its type does not
have linkage
:1:1: used here
f(nullptr)
^
(lldb) p f()
(int) $1 = 0
(lldb) p f(nullptr)
(int) $2 = 1
```

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 47522] New: Assertion `isHandleInSync() && "invalid iterator access!"' failed

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47522

Bug ID: 47522
   Summary: Assertion `isHandleInSync() && "invalid iterator
access!"' failed
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: dmanti...@yandex.ru
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

Attempt to complete symbol name produces the following crash:

sysroot@/home/antipov/llvm> /home/antipov/.local/llvm-devel-12.0.0/bin/lldb
/home/antipov/.local/llvm-devel-12.0.0/bin/clang
(lldb) target create "/home/antipov/.local/llvm-devel-12.0.0/bin/clang"
Current executable set to '/home/antipov/.local/llvm-devel-12.0.0/bin/clang'
(x86_64).
(lldb) breakpoint set -f Gnu.cpp -l 1958
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) process launch -- -xc++ /dev/null
Process 1028276 launched: '/home/antipov/.local/llvm-devel-12.0.0/bin/clang'
(x86_64)
1 location added to breakpoint 1
Process 1028276 stopped
* thread #1, name = 'clang', stop reason = breakpoint 1.1
frame #0: 0x7693c6ac
libclang-cpp.so.12git`clang::driver::toolchains::Generic_GCC::GCCInstallationDetector::init(this=0x00499aa0,
TargetTriple=, Args=, ExtraTripleAliases=(Data =
0x, Length = 0)) at Gnu.cpp:1958:12
   1955 }
   1956 for (StringRef Suffix : CandidateBiarchLibDirs) {
   1957   const std::string LibDir = Prefix + Suffix.str();
-> 1958   if (!D.getVFS().exists(LibDir))
   1959 continue;
   1960   for (StringRef Candidate : CandidateBiarchTripleAliases)
   1961 ScanLibDirForGCCTriple(TargetTriple, Args, LibDir, Candidate,
(lldb) p Can[THEN PRESS TAB HERE]

==>

lldb: /home/antipov/llvm/source/llvm/include/llvm/ADT/DenseMap.h:1263:
DenseMapIterator
::DenseMapIterator,
llvm::detail::DenseMapPair,
false>::operator++() [KeyT = clang::DeclarationName, ValueT =
clang::StoredDeclsList, KeyInfoT = llvm::DenseMapInfo,
Bucket = llvm::detail::DenseMapPair, IsConst = false]: Assertion `isHandleInSync() &&
"invalid iterator access!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0.  Program arguments: /home/antipov/.local/llvm-devel-12.0.0/bin/lldb
/home/antipov/.local/llvm-devel-12.0.0/bin/clang 
1.  :1:1: current parser token 'Can'
2.  :42:1: parsing function body
'clang::driver::toolchains::Generic_GCC::GCCInstallationDetector::$__lldb_expr'
3.  :42:1: in compound statement ('{}')
 #0 0x7f0367b537b3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
/home/antipov/llvm/source/llvm/lib/Support/Unix/Signals.inc:563:13
 #1 0x7f0367b51b00 llvm::sys::RunSignalHandlers()
/home/antipov/llvm/source/llvm/lib/Support/Signals.cpp:71:18
 #2 0x7f0367b53ae5 SignalHandler(int)
/home/antipov/llvm/source/llvm/lib/Support/Unix/Signals.inc:0:3
 #3 0x7f0371c0da90 __restore_rt (/lib64/libpthread.so.0+0x14a90)
 #4 0x7f0366ab89e5 raise (/lib64/libc.so.6+0x3c9e5)
 #5 0x7f0366aa1895 abort (/lib64/libc.so.6+0x25895)
 #6 0x7f0366aa1769 _nl_load_domain.cold (/lib64/libc.so.6+0x25769)
 #7 0x7f0366ab0e76 (/lib64/libc.so.6+0x34e76)
 #8 0x7f036dd8af09 llvm::DenseMapIterator,
llvm::detail::DenseMapPair,
false>::operator!=(llvm::DenseMapIterator,
llvm::detail::DenseMapPair,
true> const&) const
/home/antipov/llvm/source/llvm/include/llvm/ADT/DenseMap.h:1257:5
 #9 0x7f036dd8af09 clang::DeclContext::all_lookups_iterator::operator++()
/home/antipov/llvm/source/llvm/tools/clang/include/clang/AST/DeclLookups.h:54:17
#10 0x7f036e8300fd (anonymous
namespace)::LookupVisibleHelper::lookupInDeclContext(clang::DeclContext*,
clang::LookupResult&, bool, bool)
/home/antipov/llvm/source/llvm/tools/clang/lib/Sema/SemaLookup.cpp:0:36
#11 0x7f036e82f984 (anonymous
namespace)::LookupVisibleHelper::lookupInScope(clang::Scope*,
clang::LookupResult&, (anonymous namespace)::UnqualUsingDirectiveSet&)
/home/antipov/llvm/source/llvm/tools/clang/lib/Sema/SemaLookup.cpp:0:9
#12 0x7f036e824f4f
std::__cxx11::list,
llvm::DenseMapInfo,
llvm::detail::DenseMapPair > >,
std::allocator,
llvm::DenseMapInfo,
llvm::detail::DenseMapPair > > > >::pop_back()
/usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/stl_list.h:1247:55
#13 0x7f036e824f4f (anonymous
namespace)::ShadowContextRAII::~ShadowContextRAII()
/home/antipov/llvm/source/llvm/tools/clang/lib/Sema/SemaLookup.cpp:3603:24
#14 0x7f036e824f4f (anonymous
namespace)::LookupVisibleHelper::lookupVisibleDecls(clang::Sema&,
clang::Scope*, clang::Sema::LookupNameKind, bool)
/home/antipov/llvm/source/llvm/tools/clang/lib/Sema/SemaLookup.cpp:3683:3
#15 0x7f036e824f4f clang::Sema::LookupVisibleDecls(clang::Scope*,
clang::Sema::LookupNameKind, 

[lldb-dev] [11.0.0 Release] Release status

[Hans Wennborg via lldb-dev]

Hello everyone,

As those following along have noticed, the release is late.

There are currently six blocking bugs at
https://bugs.llvm.org/show_bug.cgi?id=46725

I'm trying to nudge those along as best as I can, but any help would
be very welcome.

Once those issues are resolved, the plan is to tag rc3, after which we
can release if there are no bad surprises.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB build searching for the wrong Python, again.

[Adrian McCarthy via lldb-dev]

I've figured out some of the *what* but I still don't understand the *why*.

I checked the Windows registry, and found some remnants referencing Python
3.6.  I doubt that's related, but I obliterated them anyway.

I scrutinized the very noisy output of Cmake and discovered two things:

1.  Cmake found my Python 3.8, right where it should be, then it said,
"Could NOT find Python3 (missing: Development)".  I'm not sure why it
didn't think that version has the development files--it does.
2.  Next, Cmake found Python 3.7 buried in the Visual Studio 2019
installation tree.  (I keep forgetting that VS smuggles other software onto
the machine.)  I have no idea HOW Cmake found this version.  It's not
anywhere in the PATH.  It's not referenced by any other environment
variables.  If it's referenced from the Windows registry, I couldn't find
it.  It's just magic, I guess.

So I spun up the Visual Studio Installer and removed every package that
mentioned Python.  I then trashed my build tree and started again.

This time, Cmake selected my Python 3.8 tree, apparently satisfied that it
does indeed have the development files.  (Why does the presence of an
unreferenced Python 3.7 cause Cmake to think the easy-to-find 3.8
installation doesn't have development files???  Sounds like a Cmake bug to
me.)

So, for the moment, I have a working build again.

It's interesting to note that, in the four or five times since last fall
that I've been bit by the wrong-version-of-Python-while-building-LLDB bug,
the "solution" has been different.  I wonder what it'll be next time.

Thanks to the folks who sent me advice off-list.

Adrian.

On Thu, Sep 3, 2020 at 1:42 PM Adrian McCarthy  wrote:

> After rebasing, my local LLDB builds have again broken because it goes
> looking for the wrong Python DLL.  I'm searching through git logs, but I'm
> not seeing a related change.
>
> Does anyone know what causes CMake to get confused about which Python
> versions are installed?
>
> LINK : fatal error LNK1104: *cannot open file 'python37_d.lib'*
>
> Why is it looking for 3.7?  My CMake command uses every hint I know about
> to ensure that it finds Python 3.8:
>
> cmake -GNinja -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON
> -DCMAKE_BUILD_TYPE=Debug -DLLDB_TEST_DEBUG_TEST_CRASHES=1
> -DPYTHON_HOME="C:\Program Files\Python*38*"
> -DLLDB_PYTHON_HOME="C:\Program Files\Python*38*"
> -DPython3_ROOT_DIR="C:\Program Files\Python*38*"
> -DPython3_FIND_REGISTRY=LAST
> -DLLDB_TEST_COMPILER=D:\src\llvm\build\ninja_dbg\bin\clang.exe
> ..\..\llvm-project\llvm -DLLVM_ENABLE_ZLIB=OFF
> -DLLVM_ENABLE_PROJECTS="clang;lld;lldb;clang-tools-extra;compiler-rt"
>
> My environment doesn't reference any other version of Python:
>
> D:\src\llvm\llvm-project>set | find /I "python"
> Path=C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Professional\VC\Tools\MSVC\14.24.28314\bin\HostX64\x64;C:\Program
> Files (x86)\Microsoft Visual
> Studio\2019\Professional\Common7\IDE\VC\VCPackages;C:\Program Files
> (x86)\Microsoft Visual
> Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program
> Files (x86)\Microsoft Visual
> Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team
> Explorer;C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Professional\MSBuild\Current\bin\Roslyn;C:\Program Files
> (x86)\Microsoft Visual Studio\2019\Professional\Team Tools\Performance
> Tools\x64;C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Professional\Team Tools\Performance Tools;C:\Program Files
> (x86)\Microsoft Visual
> Studio\Shared\Common\VSPerfCollectionTools\vs2019\\x64;C:\Program Files
> (x86)\Microsoft Visual
> Studio\Shared\Common\VSPerfCollectionTools\vs2019\;C:\Program Files
> (x86)\Windows Kits\10\bin\10.0.18362.0\x64;C:\Program Files (x86)\Windows
> Kits\10\bin\x64;C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Professional\\MSBuild\Current\Bin;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program
> Files (x86)\Microsoft Visual
> Studio\2019\Professional\Common7\IDE\;C:\Program Files (x86)\Microsoft
> Visual
> Studio\2019\Professional\Common7\Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\corpam;C:\Windows\ccmsetup;C:\Program
> Files\Git\cmd;C:\Program
> Files\Git\usr\bin;D:\src\util\GnuWin32\bin;C:\Program
> Files\doxygen\bin;C:\Program
> Files\Notepad++;D:\src\llvm\build\ninja_dbg\bin;D:\src\llvm\llvm-project\clang\tools\clang-format;C:\Program
> Files\Python38;D:\src\llvm\llvm-project\llvm\utils\git-svn\;D:\src\util;D:\src\util\swigwin-3.0.12;C:\Program
> Files (x86)\Microsoft Visual
> Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;C:\Program
> Files (x86)\Microsoft Visual
> Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja
> 

[lldb-dev] LLDB build searching for the wrong Python, again.

[Adrian McCarthy via lldb-dev]

After rebasing, my local LLDB builds have again broken because it goes
looking for the wrong Python DLL.  I'm searching through git logs, but I'm
not seeing a related change.

Does anyone know what causes CMake to get confused about which Python
versions are installed?

LINK : fatal error LNK1104: *cannot open file 'python37_d.lib'*

Why is it looking for 3.7?  My CMake command uses every hint I know about
to ensure that it finds Python 3.8:

cmake -GNinja -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON
-DCMAKE_BUILD_TYPE=Debug -DLLDB_TEST_DEBUG_TEST_CRASHES=1
-DPYTHON_HOME="C:\Program Files\Python*38*" -DLLDB_PYTHON_HOME="C:\Program
Files\Python*38*" -DPython3_ROOT_DIR="C:\Program Files\Python*38*"
-DPython3_FIND_REGISTRY=LAST
-DLLDB_TEST_COMPILER=D:\src\llvm\build\ninja_dbg\bin\clang.exe
..\..\llvm-project\llvm -DLLVM_ENABLE_ZLIB=OFF
-DLLVM_ENABLE_PROJECTS="clang;lld;lldb;clang-tools-extra;compiler-rt"

My environment doesn't reference any other version of Python:

D:\src\llvm\llvm-project>set | find /I "python"
Path=C:\Program Files (x86)\Microsoft Visual
Studio\2019\Professional\VC\Tools\MSVC\14.24.28314\bin\HostX64\x64;C:\Program
Files (x86)\Microsoft Visual
Studio\2019\Professional\Common7\IDE\VC\VCPackages;C:\Program Files
(x86)\Microsoft Visual
Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program
Files (x86)\Microsoft Visual
Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team
Explorer;C:\Program Files (x86)\Microsoft Visual
Studio\2019\Professional\MSBuild\Current\bin\Roslyn;C:\Program Files
(x86)\Microsoft Visual Studio\2019\Professional\Team Tools\Performance
Tools\x64;C:\Program Files (x86)\Microsoft Visual
Studio\2019\Professional\Team Tools\Performance Tools;C:\Program Files
(x86)\Microsoft Visual
Studio\Shared\Common\VSPerfCollectionTools\vs2019\\x64;C:\Program Files
(x86)\Microsoft Visual
Studio\Shared\Common\VSPerfCollectionTools\vs2019\;C:\Program Files
(x86)\Windows Kits\10\bin\10.0.18362.0\x64;C:\Program Files (x86)\Windows
Kits\10\bin\x64;C:\Program Files (x86)\Microsoft Visual
Studio\2019\Professional\\MSBuild\Current\Bin;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program
Files (x86)\Microsoft Visual
Studio\2019\Professional\Common7\IDE\;C:\Program Files (x86)\Microsoft
Visual
Studio\2019\Professional\Common7\Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\corpam;C:\Windows\ccmsetup;C:\Program
Files\Git\cmd;C:\Program
Files\Git\usr\bin;D:\src\util\GnuWin32\bin;C:\Program
Files\doxygen\bin;C:\Program
Files\Notepad++;D:\src\llvm\build\ninja_dbg\bin;D:\src\llvm\llvm-project\clang\tools\clang-format;C:\Program
Files\Python38;D:\src\llvm\llvm-project\llvm\utils\git-svn\;D:\src\util;D:\src\util\swigwin-3.0.12;C:\Program
Files (x86)\Microsoft Visual
Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;C:\Program
Files (x86)\Microsoft Visual
Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja
__VSCMD_PREINIT_PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\corpam;C:\Windows\ccmsetup;C:\Program
Files\Git\cmd;C:\Program
Files\Git\usr\bin;D:\src\util\GnuWin32\bin;C:\Program
Files\doxygen\bin;C:\Program
Files\Notepad++;D:\src\llvm\build\ninja_dbg\bin;D:\src\llvm\llvm-project\clang\tools\clang-format;*C:\Program
Files\Python38*
;D:\src\llvm\llvm-project\llvm\utils\git-svn\;D:\src\util;D:\src\util\swigwin-3.0.12

D:\src\llvm\llvm-project>where python
C:\Program Files\Python38\python.exe

D:\src\llvm\build\ninja_dbg>which python
/c/Program Files/Python38/python

I do not have 3.7 on my machine.  For a long while now, I've had to keep
exactly one version of Python on my machine specifically to prevent LLDB
builds from trying to mix versions.

But I'm stumped once again.

Clues appreciated,
Adrian.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] HTTP library in LLVM

[Petr Hosek via lldb-dev]

These are the ones I found so far:

* [libmicrohttpd](https://www.gnu.org/software/libmicrohttpd/) is used by
elfutils' debuginfod, but it's LGPL licensed.
* [libcURL](https://curl.haxx.se/libcurl/) would be an option for the
client, but we'd need a different library for the server.
* [libhttp](https://github.com/lammertb/libhttp) is another MIT licensed
library that could be a fit, but it seems bigger and more featureful than
httplib.
* [cpprestsdk](https://github.com/microsoft/cpprestsdk) has a lot of extra
features we don't need, like websockets.
* [pistache](https://github.com/oktal/pistache) similarly has additional
features and dependencies that are likely unnecessary.
* [crow](https://github.com/ipkn/crow) is similar to cpprestsdk and
pistache, it depends on Boost.
* [cpp-netlib](https://github.com/cpp-netlib/cpp-netlib) looks nice but
depends on Boost.
* [proxygen](https://github.com/facebook/proxygen) is also nice but has a
lot of dependencies including Boost.

On Mon, Aug 31, 2020 at 4:48 PM Jonas Devlieghere 
wrote:

> On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> There are several options, I've looked at couple of them and the one I
>> like the most so far is https://github.com/yhirose/cpp-httplib for a few
>> reasons:
>>
>> * It's MIT licensed.
>> * It supports Linux, macOS and Windows (and presumably other platforms).
>> * It doesn't have any dependencies, it can optionally use zlib and
>> OpenSSL.
>> * It's a modern C++11 implementation, the entire library is a single
>> header.
>>
>
> This looks appealing indeed. Out of curiosity, what are the other
> alternatives you considered?
>
>
>>
>> On Mon, Aug 31, 2020 at 4:31 PM Eric Christopher 
>> wrote:
>>
>>> +LLDB Dev  as well for visibility. +Pavel
>>> Labath  since he and I have talked about such things.
>>>
>>> On Mon, Aug 31, 2020 at 7:26 PM David Blaikie 
>>> wrote:
>>>
 [+debug info folks, just as FYI - since the immediate question's more
 about 3rd party library deps than the nuances of DWARF, etc]

 I'd imagine avoiding writing such a thing from scratch would be
 desirable, but that the decision might depend somewhat on what libraries
 out there you/we would consider including, what their licenses and further
 dependencies are.

 On Mon, Aug 31, 2020 at 4:22 PM Petr Hosek via llvm-dev <
 llvm-...@lists.llvm.org> wrote:

> We're considering implementing [debuginfod](
> https://sourceware.org/elfutils/Debuginfod.html) library in LLVM.
> Initially, we'd like to start with the client implementation, which would
> enable debuginfod support in tools like llvm-symbolizer, but later we'd
> also like to provide LLVM-based debuginfod server implementation.
>
> debuginfod uses HTTP and so we need an HTTP library, ideally one that
> supports both client and server.
>
> The question is, would it be acceptable to use an existing C++ HTTP
> library or would it be preferred to implement an HTTP library in LLVM from
> scratch?
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
 ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] HTTP library in LLVM

[Jonas Devlieghere via lldb-dev]

On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> There are several options, I've looked at couple of them and the one I
> like the most so far is https://github.com/yhirose/cpp-httplib for a few
> reasons:
>
> * It's MIT licensed.
> * It supports Linux, macOS and Windows (and presumably other platforms).
> * It doesn't have any dependencies, it can optionally use zlib and OpenSSL.
> * It's a modern C++11 implementation, the entire library is a single
> header.
>

This looks appealing indeed. Out of curiosity, what are the other
alternatives you considered?


>
> On Mon, Aug 31, 2020 at 4:31 PM Eric Christopher 
> wrote:
>
>> +LLDB Dev  as well for visibility. +Pavel Labath
>>  since he and I have talked about such things.
>>
>> On Mon, Aug 31, 2020 at 7:26 PM David Blaikie  wrote:
>>
>>> [+debug info folks, just as FYI - since the immediate question's more
>>> about 3rd party library deps than the nuances of DWARF, etc]
>>>
>>> I'd imagine avoiding writing such a thing from scratch would be
>>> desirable, but that the decision might depend somewhat on what libraries
>>> out there you/we would consider including, what their licenses and further
>>> dependencies are.
>>>
>>> On Mon, Aug 31, 2020 at 4:22 PM Petr Hosek via llvm-dev <
>>> llvm-...@lists.llvm.org> wrote:
>>>
 We're considering implementing [debuginfod](
 https://sourceware.org/elfutils/Debuginfod.html) library in LLVM.
 Initially, we'd like to start with the client implementation, which would
 enable debuginfod support in tools like llvm-symbolizer, but later we'd
 also like to provide LLVM-based debuginfod server implementation.

 debuginfod uses HTTP and so we need an HTTP library, ideally one that
 supports both client and server.

 The question is, would it be acceptable to use an existing C++ HTTP
 library or would it be preferred to implement an HTTP library in LLVM from
 scratch?
 ___
 LLVM Developers mailing list
 llvm-...@lists.llvm.org
 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

>>> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] HTTP library in LLVM

[David Blaikie via lldb-dev]

On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek  wrote:

> There are several options, I've looked at couple of them and the one I
> like the most so far is https://github.com/yhirose/cpp-httplib for a few
> reasons:
>
> * It's MIT licensed.
>

I hesitate to get into it on the list, not-a-lawyer, etc. But does that
seem like it'd be as usable as other code we have (zlib, gtest, etc) used
by/in LLVM?


> * It supports Linux, macOS and Windows (and presumably other platforms).
> * It doesn't have any dependencies, it can optionally use zlib and OpenSSL.
> * It's a modern C++11 implementation, the entire library is a single
> header.
>

Handy - I guess you'd want to check that in (ala gtest, rather than ala
zlib which is used from the system) to the llvm-project repository, then?


>
> On Mon, Aug 31, 2020 at 4:31 PM Eric Christopher 
> wrote:
>
>> +LLDB Dev  as well for visibility. +Pavel Labath
>>  since he and I have talked about such things.
>>
>> On Mon, Aug 31, 2020 at 7:26 PM David Blaikie  wrote:
>>
>>> [+debug info folks, just as FYI - since the immediate question's more
>>> about 3rd party library deps than the nuances of DWARF, etc]
>>>
>>> I'd imagine avoiding writing such a thing from scratch would be
>>> desirable, but that the decision might depend somewhat on what libraries
>>> out there you/we would consider including, what their licenses and further
>>> dependencies are.
>>>
>>> On Mon, Aug 31, 2020 at 4:22 PM Petr Hosek via llvm-dev <
>>> llvm-...@lists.llvm.org> wrote:
>>>
 We're considering implementing [debuginfod](
 https://sourceware.org/elfutils/Debuginfod.html) library in LLVM.
 Initially, we'd like to start with the client implementation, which would
 enable debuginfod support in tools like llvm-symbolizer, but later we'd
 also like to provide LLVM-based debuginfod server implementation.

 debuginfod uses HTTP and so we need an HTTP library, ideally one that
 supports both client and server.

 The question is, would it be acceptable to use an existing C++ HTTP
 library or would it be preferred to implement an HTTP library in LLVM from
 scratch?
 ___
 LLVM Developers mailing list
 llvm-...@lists.llvm.org
 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] [llvm-dev] HTTP library in LLVM

[Eric Christopher via lldb-dev]

+LLDB Dev  as well for visibility. +Pavel Labath
 since he and I have talked about such things.

On Mon, Aug 31, 2020 at 7:26 PM David Blaikie  wrote:

> [+debug info folks, just as FYI - since the immediate question's more
> about 3rd party library deps than the nuances of DWARF, etc]
>
> I'd imagine avoiding writing such a thing from scratch would be desirable,
> but that the decision might depend somewhat on what libraries out there
> you/we would consider including, what their licenses and further
> dependencies are.
>
> On Mon, Aug 31, 2020 at 4:22 PM Petr Hosek via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> We're considering implementing [debuginfod](
>> https://sourceware.org/elfutils/Debuginfod.html) library in LLVM.
>> Initially, we'd like to start with the client implementation, which would
>> enable debuginfod support in tools like llvm-symbolizer, but later we'd
>> also like to provide LLVM-based debuginfod server implementation.
>>
>> debuginfod uses HTTP and so we need an HTTP library, ideally one that
>> supports both client and server.
>>
>> The question is, would it be acceptable to use an existing C++ HTTP
>> library or would it be preferred to implement an HTTP library in LLVM from
>> scratch?
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [11.0.0 Release] Release Candidate 2 is here

[Michał Górny via lldb-dev]

On Thu, 2020-08-20 at 22:34 +0200, Hans Wennborg via Release-testers
wrote:
> Hello everyone,
> 
> The llvmorg-11.0.0-rc2 tag was just created.
> 
> Source code and docs are available at
> https://prereleases.llvm.org/11.0.0/#rc2 and
> https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc2
> 
> Pre-built binaries will be added as they become ready.
> 
> Please file bug reports for any issues you find as blockers of
> https://llvm.org/pr46725
> 
> Release testers: please start your engines, run the script, share your
> results, and upload binaries.
> 

Gentoo amd64 looks reasonably good.  LLDB tests are broken as usual.

I've also tried i686.  Clang-tools-extra fails one test, and compiler-rt 
fails to run tests due to empty gwp-asan set.  However, I'm not sure if
it's worth reporting as I doubt anyone cares.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [11.0.0 Release] Release Candidate 2 is here

[Dimitry Andric via lldb-dev]

On 20 Aug 2020, at 22:34, Hans Wennborg via Release-testers 
 wrote:
> 
> The llvmorg-11.0.0-rc2 tag was just created.

This rc2, I could finally build and test without adding any patches! :)

Main results on amd64-freebsd11:

  Unsupported:  5121 (rc1:  5121)
  Passed : 69739 (rc1: 69722)
  Expectedly Failed  :   245 (rc1:   245)
  Timed Out  :16 (rc1:12)
  Failed :   481 (rc1:   485)
  Unexpectedly Passed: 2 (rc1: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc1: 2399)
  Failed:3 (rc1:3)

Main results on i386-freebsd11:

  Unsupported:  3512 (rc1:  3512)
  Passed : 66614 (rc1: 66597)
  Expectedly Failed  :   230 (rc1:   230)
  Timed Out  : 7 (rc1: 7)
  Failed :   322 (rc1:   322)
  Unexpectedly Passed: 1 (rc1: 1)

Uploaded:
SHA256 (clang+llvm-11.0.0-rc2-amd64-unknown-freebsd11.tar.xz) = 
6d6733f3b996c90621d7712ad08c7722ca4d8f5ec75357ee3755ec9e2f337906
SHA256 (clang+llvm-11.0.0-rc2-i386-unknown-freebsd11.tar.xz) = 
4ccba28c955ba0fce5de11c0d772d2304d7e7053a71b1042e11dc86c7fdab5c0

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [11.0.0 Release] Please help writing release notes!

[Hans Wennborg via lldb-dev]

Hello everyone,

With the release drawing near, it would be great to get the release
notes into better shape.

You can see the notes from rc2 online here:
https://prereleases.llvm.org/11.0.0/#rc2

The release notes are typically the first thing people look at after
the release, so it's a great opportunity to highlight the work that's
been done since the last release.

If you can think of anything interesting that happened over the last
six months, please consider adding to the notes by sending me a patch,
committing directly to the notes on the release/11.x branch, or just
sending me some text in an email.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 47284] [lldb] Merge 1ce07cd614be into 11.0

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47284

Hans Wennborg  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 CC||h...@chromium.org

--- Comment #1 from Hans Wennborg  ---
Pushed to 11.x as 6406b6fa5ac8192b0861c343509d98368b555d12.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [11.0.0 Release] Release Candidate 2 is here

[Brian Cain via lldb-dev]

Uploaded Ubuntu 16 and SLES12 binaries:

$ cat clang+llvm-11.0.0-rc2-x86_64-linux-gnu-ubuntu-16.04.tar.xz.sha256
clang+llvm-11.0.0-rc2-x86_64-linux-sles12.4.tar.xz.sha256
051d288dfc6ef9ff8e37d97b722695390427c617d3b538a93f2d0d413fb6f54a
 clang+llvm-11.0.0-rc2-x86_64-linux-gnu-ubuntu-16.04.tar.xz
5d1a54fbca4e3c9865094c8c4602d5761adc49a1f4c58d2a481cbe502ea35f74
 clang+llvm-11.0.0-rc2-x86_64-linux-sles12.4.tar.xz

On Thu, Aug 20, 2020 at 3:34 PM Hans Wennborg via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> Hello everyone,
>
> The llvmorg-11.0.0-rc2 tag was just created.
>
> Source code and docs are available at
> https://prereleases.llvm.org/11.0.0/#rc2 and
> https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc2
>
> Pre-built binaries will be added as they become ready.
>
> Please file bug reports for any issues you find as blockers of
> https://llvm.org/pr46725
>
> Release testers: please start your engines, run the script, share your
> results, and upload binaries.
>
> We're a bit behind schedule, but I also don't think we have any super
> bad bugs open, so hopefully we can still wrap up fairly soon.
>
> Thanks,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


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

[lldb-dev] [Bug 47284] New: [lldb] Merge 1ce07cd614be into 11.0

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47284

Bug ID: 47284
   Summary: [lldb] Merge 1ce07cd614be into 11.0
   Product: lldb
   Version: 11.0
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: dimi...@andric.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

Please merge https://reviews.llvm.org/D86355 /
https://reviews.llvm.org/rG1ce07cd614be into 11.0. This fixes an unhandled
llvm::Error return in lldb's Target::GetEntryPointAddress().

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [11.0.0 Release] Release Candidate 2 is here

[Hans Wennborg via lldb-dev]

Hello everyone,

The llvmorg-11.0.0-rc2 tag was just created.

Source code and docs are available at
https://prereleases.llvm.org/11.0.0/#rc2 and
https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc2

Pre-built binaries will be added as they become ready.

Please file bug reports for any issues you find as blockers of
https://llvm.org/pr46725

Release testers: please start your engines, run the script, share your
results, and upload binaries.

We're a bit behind schedule, but I also don't think we have any super
bad bugs open, so hopefully we can still wrap up fairly soon.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] RFC: AArch64 Linux Memory Tagging Support for LLDB

[David Spickett via lldb-dev]

> The initial idea of commands like "memory showptrtag", "memory showtag", 
> "memory checktag" - it might be better to put all of these under "memory tag 
> ...", similar to how "breakpoint command ..." works.

Sounds good to me, I didn't know there was a 3 level command in there
already. The names get a bit redundant since "memory tag set" doesn't
tell you which one of the pair it's setting. So we could have "memory
tag setptrtag" "memory tag setmemorytag", or make "set" one command
with variable arguments:
Set logical tag: memory tag set  
Set logical and allocation: memory tag set  
 
Set only allocation: memory tag set  --only-memory  
(which I think is a bit neater)

Where "pointer tag" and "memory tag" were the best generic names for
"logical" and "allocation" I came up with. (think of it like the
memory tag is attached to the memory, pointer tag is attached to a
pointer)
Also "memory tag check" can be removed since it's just "memory tag
show" with a warning on mismatch.

> My general design is that the Process object will keep track of the # of bits 
> used for virtual addresses.

I hadn't considered this issue thanks for bringing it up. Your scheme
seems reasonable to me. I see that "addressing_bits" is in the
upstream qHostInfo but only in the RNBRemote, does that mean that
upstream already uses this in some way? (presumably just for Apple
platforms?)

> I am working on a kernel patch which will make this information available via 
> siginfo, and once the tag becomes available from the kernel you shouldn't 
> need to decode the instruction.

Great! I'll keep an eye on it.

On Fri, 14 Aug 2020 at 02:40, Peter Collingbourne  wrote:
>
>
>
> On Mon, Aug 10, 2020 at 3:41 AM David Spickett via lldb-dev 
>  wrote:
>>
>> Hi all,
>>
>> What follows is my proposal for supporting AArch64's memory tagging
>> extension in LLDB. I think the link in the first paragraph is a good
>> introduction if you haven't come across memory tagging before.
>>
>> I've also put the document in a Google Doc if that's easier for you to
>> read: 
>> https://docs.google.com/document/d/13oRtTujCrWOS_2RSciYoaBPNPgxIvTF2qyOfhhUTj1U/edit?usp=sharing
>> (please keep comments to this list though)
>>
>> Any and all comments welcome. Particularly I would like opinions on
>> the naming of the commands, as this extension is AArch64 specific but
>> the concept of memory tagging itself is not.
>> (I've added some people on Cc who might have particular interest)
>>
>> Thanks,
>> David Spickett.
>>
>> 
>>
>> # RFC: AArch64 Linux Memory Tagging Support for LLDB
>>
>> ## What is memory tagging?
>>
>> Memory tagging is an extension added in the Armv8.5-a architecture for 
>> AArch64.
>> It allows tagging pointers and storing those tags so that hardware can 
>> validate
>> that a pointer matches the memory address it is trying to access. These 
>> paired
>> tags are stored in the upper bits of the pointer (the “logical” tag) and in
>> special memory in hardware (the “allocation” tag). Each tag is 4 bits in 
>> size.
>>
>> https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety
>>
>> ## Definitions
>>
>> * memtag - This is the clang name for the extension as in
>> “-march=armv8.5-a+memtag”
>> * mte - An alternative name for mmtag, also the llvm backend name for
>> the extension.
>>   This document may use memtag/memory tagging/MTE at times, they mean
>> the same thing.
>> * logical tag - The tag stored inside a pointer variable (accessible
>> via normal shift and mask)
>> * allocation tag - The tag stored in tag memory (which the hardware provides)
>>   for a particular tag granule
>> * tag granule - The amount of memory that a single tag applies to,
>> which is 16 bytes.
>>
>> ## Existing Tool Support
>>
>> * GCC/Clang can generate MTE instructions
>> * Clang has an option to memory tag the stack (discussed later)
>> * QEMU support has been merged
>> * Linux Kernel patches are in progress
>>   (git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
>> “devel/mte-v5” branch)
>> * GDB support is in review and this design takes a lot of direction from that
>>   
>> (https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/luisgpm/aarch64-mte-v2)
>>   (originally proposed
>> https://sourceware.org/pipermail/gdb-patches/2019-August/159881.html)
>>
>> ## New lldb features
>>

[lldb-dev] [Bug 45112] Tests import "lldb.macosx.heap" incorrectly

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=45112

Raphael Isemann  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||teempe...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Raphael Isemann  ---
Davide fixed those tests (by using `command script import` instead of `script
import`) in 8fcfe2862fd4fde4793e232cfeebe6c5540c80a5 and 
0cceb54366b406649fdfe7bb11b133ab96f3cd70. I re-enabled them in
7208cb1ac43e4be806bcb91c622fc1f8641e010b.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [11.0.0 Release] Release Candidate 1 is here

[Ahsan Saghir via lldb-dev]

Hi,

I finished testing llvm-11.0.0-rc1 on Power PC 64bit Little Endian for
- Ubuntu 18.04
- Red Hat 7.4
I have uploaded the binaries from IBM. The sha1 files are attached.

PR46995 opened for the bug found. Other than that I saw errors as reported
by others for matrix-types-spec.cpp (no matching function for call to
'initRandom').

Thanks,
Ahsan Saghir.

On Tue, 28 Jul 2020 at 13:50, Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:

> Hello everyone,
>
> We're a little bit behind schedule, but RC1 is now here. It was tagged
> earlier today as llvmorg-11.0.0-rc1.
>
> Source code and docs are available at
> https://prereleases.llvm.org/11.0.0/#rc1 and
> https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc1
>
> Pre-built binaries will be added as they become available.
>
> Please file bug reports for any issues you find as blockers of
> https://llvm.org/pr46725
>
> Release testers: please start your engines, run the script, share your
> results, and upload binaries.
>
> RC2 was originally scheduled for Friday, but seeing as we just cut
> this one it will come a little later.
>
> Thanks,
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>


clang+llvm-11.0.0-rc1-powerpc64le-linux-rhel-7.4.sha1
Description: Binary data


clang+llvm-11.0.0-rc1-powerpc64le-linux-ubuntu-18.04.sha1
Description: Binary data
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] RFC: AArch64 Linux Memory Tagging Support for LLDB

[Peter Collingbourne via lldb-dev]

On Mon, Aug 10, 2020 at 3:41 AM David Spickett via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi all,
>
> What follows is my proposal for supporting AArch64's memory tagging
> extension in LLDB. I think the link in the first paragraph is a good
> introduction if you haven't come across memory tagging before.
>
> I've also put the document in a Google Doc if that's easier for you to
> read:
> https://docs.google.com/document/d/13oRtTujCrWOS_2RSciYoaBPNPgxIvTF2qyOfhhUTj1U/edit?usp=sharing
> (please keep comments to this list though)
>
> Any and all comments welcome. Particularly I would like opinions on
> the naming of the commands, as this extension is AArch64 specific but
> the concept of memory tagging itself is not.
> (I've added some people on Cc who might have particular interest)
>
> Thanks,
> David Spickett.
>
> 
>
> # RFC: AArch64 Linux Memory Tagging Support for LLDB
>
> ## What is memory tagging?
>
> Memory tagging is an extension added in the Armv8.5-a architecture for
> AArch64.
> It allows tagging pointers and storing those tags so that hardware can
> validate
> that a pointer matches the memory address it is trying to access. These
> paired
> tags are stored in the upper bits of the pointer (the “logical” tag) and in
> special memory in hardware (the “allocation” tag). Each tag is 4 bits in
> size.
>
>
> https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety
>
> ## Definitions
>
> * memtag - This is the clang name for the extension as in
> “-march=armv8.5-a+memtag”
> * mte - An alternative name for mmtag, also the llvm backend name for
> the extension.
>   This document may use memtag/memory tagging/MTE at times, they mean
> the same thing.
> * logical tag - The tag stored inside a pointer variable (accessible
> via normal shift and mask)
> * allocation tag - The tag stored in tag memory (which the hardware
> provides)
>   for a particular tag granule
> * tag granule - The amount of memory that a single tag applies to,
> which is 16 bytes.
>
> ## Existing Tool Support
>
> * GCC/Clang can generate MTE instructions
> * Clang has an option to memory tag the stack (discussed later)
> * QEMU support has been merged
> * Linux Kernel patches are in progress
>   (git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
> “devel/mte-v5” branch)
> * GDB support is in review and this design takes a lot of direction from
> that
>   (
> https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/luisgpm/aarch64-mte-v2
> )
>   (originally proposed
> https://sourceware.org/pipermail/gdb-patches/2019-August/159881.html)
>
> ## New lldb features
>
> Assuming your software is acting correctly, memory tagging can “just work”
> without debugger support. This assumes the compiler/toolchain/user are
> always correct.
>
> For when that isn’t the case we want to be able to:
> * Read/write the logical tags in a pointer
> * Read/write the allocation tags assigned to a given area of memory
> * Test whether the logical tag in a pointer matches the allocation tag of
> the
>   memory it refers to
> * Read/write memory even when tags are mismatched
>
> The most obvious use case for this is working through issues where bugs in
> the
> toolchain don’t generate correct code. On the other hand there’s a good
> case for
> deliberately messing with pointers in your code to prove that such
> protection
> actually works.
>
> Note: potential extensions to scripting such as tags as attributes of
> values and
> such are not being proposed here. Of course the new commands will be
> added in the
> standard ways so you can use those.
>
> ## New Commands
>
> ### Command Availability
>
> Note: commands will be listed in tab completion and help regardless of
> these checks
>
> * The remote server must support memory tagging packets. lldb will
> send/check
>   for the “memory-tagging” feature in the qSupported packet. (this
> name aligns with gdb)
> * The process must have MTE available. We check HWCAP2_MTE for this.
> * The process must have enabled tagged addressing using prctl
>   (see “New Registers” for details)
> * The address given must be in a range that has MTE enabled, since you can
> mmap
>   with or without MTE. (this information is in /proc/.../smaps)
>
>  Interaction With Clang’s Stack Tagging
>
> We’re relying on the kernel to tell us if MTE is enabled, so stack tagging
> will
> not be visible to the debugger this way.
> (
> https://github.com/google/sanitizers/wiki/Stack-instrumentation-with-ARM-Memory-Tagging-Extension-(MTE)
> )
>
> E.g. {int x; use(); } where x i

Re: [lldb-dev] RFC: AArch64 Linux Memory Tagging Support for LLDB

[Jason Molenda via lldb-dev]

l changes for jitting expressions, and to be honest 
> it's been ages since I've looked at that code so I can't speak on it very 
> authoritatively without re-reading a bunch (and I authored very little of 
> it).  
> 
> 
> 
> A good place to start IMO, is the base idea of Process being the knower of 
> the # of addressing bits, and the ABI being the knower of how to strip PAC 
> bits off.  I chose the ABI for this method because this *is* ABI, but given 
> my ideas about an all-encompassing ABI::GetAsVirtualAddress that different 
> parts of lldb pass things that can be signed in every ABI, maybe it doesn't 
> even make sense to bother putting it in the ABI, it could go in Process and 
> only strip off bits if the # of virtual addressing bits has been set.
> 
> 
>> On Aug 13, 2020, at 12:56 AM, Omair Javaid  wrote:
>> 
>> Hi Jason,
>> 
>> I wanted to bring this to your attention that we are also working on pointer 
>> authentication support. We have so far only done register context changes to 
>> allow for enabling/disabling pointer authentication features and read/write 
>> pauth Cmask/Dmask registers when available. I am currently investigating 
>> unwinder support which means any further implementation from my side will be 
>> an overlap with what you guys have done already. There can also be design 
>> conflicts and I would really appreciate it if we can come on some common 
>> ground regarding upstreaming of Apple's downstream pointer authentication 
>> patches. We may collaborate and upstream unwinder support.
>> 
>> Thanks!
>> 
>> On Tue, 11 Aug 2020 at 04:13, Jason Molenda via lldb-dev 
>>  wrote:
>> Hi David, thanks for the great writeup.  I hadn't been following the gdb MTE 
>> support.
>> 
>> This all looks reasonable to me.  A few quick thoughts --
>> 
>> The initial idea of commands like "memory showptrtag", "memory showtag", 
>> "memory checktag" - it might be better to put all of these under "memory tag 
>> ...", similar to how "breakpoint command ..." works.
>> 
>> It makes sense to have lldb read/write the control pseudo-register as if it 
>> were a normal reg, in its own register grouping.  You mentioned that you had 
>> some thoughts about how to make it more readable to users - I know this is 
>> something Greg has been hoping to do / see done at some point, for control 
>> registers where we could annotate the registers a lot better.  I noticed 
>> that qemu for x86 provides exactly this kind of annotation information in 
>> its register target.xml definitions (v. 
>> lldb/test/API/functionalities/gdb_remote_client/TestRegDefinitionInParts.py 
>> ) but I don't THINK we do anything with these annotations today.  Not at all 
>> essential to this work, but just noting that this is something we all would 
>> like to see better support for.
>> 
>> As for annotating the reason the program stopped on an MTE exception, Ismail 
>> was working on something similar in the past - although as you note, the 
>> really cool thing would be decoding the faulting instruction to understand 
>> what target register was responsible for the fault (and maybe even working 
>> back via the debug info to figure out what user-level variable it was??) to 
>> annotate it, which is something we're not doing anywhere right now.  There 
>> was a little proof-of-concept thing that Sean Callanan did years ago "frame 
>> diagnose" which would try to annotate to the user in high-level source terms 
>> why a fault happened, but I think it was using some string matching of x86 
>> instructions to figure out what happened. :)
>> 
>> We're overdue to upstream the PAC support for lldb that we're using, it's 
>> dependent on some other work being upstreamed that hasn't been done yet, but 
>> the general scheme involves querying the lldb-server / debugserver / 
>> corefile to get the number of bits used for virtual addressing, and then it 
>> just stomps on all the other high bits when trying to dereference values.  
>> If you do 'register read' of a function pointer, we show the actual value 
>> with PAC bits, then we strip the PAC bits off and if it resolves to a 
>> symbol, we print the stripped value and symbol that we're pointing to. It 
>> seems similar to what MTE will need -- if you have a variable pointing to 
>> heap using MTE, and you do `x/g var`, lldb should strip off the MTE bits 
>> before sending the address to read to lldb-server. The goal with the PAC UI 
>> design is to never hide the PAC details from the user, but to additionally 
>> show the PAC-

Re: [lldb-dev] RFC: AArch64 Linux Memory Tagging Support for LLDB

[Jason Molenda via lldb-dev]

able. I am currently investigating 
> unwinder support which means any further implementation from my side will be 
> an overlap with what you guys have done already. There can also be design 
> conflicts and I would really appreciate it if we can come on some common 
> ground regarding upstreaming of Apple's downstream pointer authentication 
> patches. We may collaborate and upstream unwinder support.
> 
> Thanks!
> 
> On Tue, 11 Aug 2020 at 04:13, Jason Molenda via lldb-dev 
>  wrote:
> Hi David, thanks for the great writeup.  I hadn't been following the gdb MTE 
> support.
> 
> This all looks reasonable to me.  A few quick thoughts --
> 
> The initial idea of commands like "memory showptrtag", "memory showtag", 
> "memory checktag" - it might be better to put all of these under "memory tag 
> ...", similar to how "breakpoint command ..." works.
> 
> It makes sense to have lldb read/write the control pseudo-register as if it 
> were a normal reg, in its own register grouping.  You mentioned that you had 
> some thoughts about how to make it more readable to users - I know this is 
> something Greg has been hoping to do / see done at some point, for control 
> registers where we could annotate the registers a lot better.  I noticed that 
> qemu for x86 provides exactly this kind of annotation information in its 
> register target.xml definitions (v. 
> lldb/test/API/functionalities/gdb_remote_client/TestRegDefinitionInParts.py ) 
> but I don't THINK we do anything with these annotations today.  Not at all 
> essential to this work, but just noting that this is something we all would 
> like to see better support for.
> 
> As for annotating the reason the program stopped on an MTE exception, Ismail 
> was working on something similar in the past - although as you note, the 
> really cool thing would be decoding the faulting instruction to understand 
> what target register was responsible for the fault (and maybe even working 
> back via the debug info to figure out what user-level variable it was??) to 
> annotate it, which is something we're not doing anywhere right now.  There 
> was a little proof-of-concept thing that Sean Callanan did years ago "frame 
> diagnose" which would try to annotate to the user in high-level source terms 
> why a fault happened, but I think it was using some string matching of x86 
> instructions to figure out what happened. :)
> 
> We're overdue to upstream the PAC support for lldb that we're using, it's 
> dependent on some other work being upstreamed that hasn't been done yet, but 
> the general scheme involves querying the lldb-server / debugserver / corefile 
> to get the number of bits used for virtual addressing, and then it just 
> stomps on all the other high bits when trying to dereference values.  If you 
> do 'register read' of a function pointer, we show the actual value with PAC 
> bits, then we strip the PAC bits off and if it resolves to a symbol, we print 
> the stripped value and symbol that we're pointing to. It seems similar to 
> what MTE will need -- if you have a variable pointing to heap using MTE, and 
> you do `x/g var`, lldb should strip off the MTE bits before sending the 
> address to read to lldb-server. The goal with the PAC UI design is to never 
> hide the PAC details from the user, but to additionally show the PAC-less 
> address when we're sure that it's an address in memory.  Tougher to do that 
> with MTE because we'll never be pointing to a symbol, it will be heap or 
> stack.
> 
> J
> 
> 
> 
> 
> 
> > On Aug 10, 2020, at 3:41 AM, David Spickett via lldb-dev 
> >  wrote:
> > 
> > Hi all,
> > 
> > What follows is my proposal for supporting AArch64's memory tagging
> > extension in LLDB. I think the link in the first paragraph is a good
> > introduction if you haven't come across memory tagging before.
> > 
> > I've also put the document in a Google Doc if that's easier for you to
> > read: 
> > https://docs.google.com/document/d/13oRtTujCrWOS_2RSciYoaBPNPgxIvTF2qyOfhhUTj1U/edit?usp=sharing
> > (please keep comments to this list though)
> > 
> > Any and all comments welcome. Particularly I would like opinions on
> > the naming of the commands, as this extension is AArch64 specific but
> > the concept of memory tagging itself is not.
> > (I've added some people on Cc who might have particular interest)
> > 
> > Thanks,
> > David Spickett.
> > 
> > 
> > 
> > # RFC: AArch64 Linux Memory Tagging Support for LLDB
> > 
> > ## What is memory tagging?
> > 
> > Memory tagging is an extension added in the Armv8.5-a architecture for 
&g

Re: [lldb-dev] RFC: AArch64 Linux Memory Tagging Support for LLDB

[Omair Javaid via lldb-dev]

Hi Jason,

I wanted to bring this to your attention that we are also working on
pointer authentication support. We have so far only done register context
changes to allow for enabling/disabling pointer authentication features and
read/write pauth Cmask/Dmask registers when available. I am currently
investigating unwinder support which means any further implementation from
my side will be an overlap with what you guys have done already. There can
also be design conflicts and I would really appreciate it if we can come on
some common ground regarding upstreaming of Apple's downstream pointer
authentication patches. We may collaborate and upstream unwinder support.

Thanks!

On Tue, 11 Aug 2020 at 04:13, Jason Molenda via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi David, thanks for the great writeup.  I hadn't been following the gdb
> MTE support.
>
> This all looks reasonable to me.  A few quick thoughts --
>
> The initial idea of commands like "memory showptrtag", "memory showtag",
> "memory checktag" - it might be better to put all of these under "memory
> tag ...", similar to how "breakpoint command ..." works.
>
> It makes sense to have lldb read/write the control pseudo-register as if
> it were a normal reg, in its own register grouping.  You mentioned that you
> had some thoughts about how to make it more readable to users - I know this
> is something Greg has been hoping to do / see done at some point, for
> control registers where we could annotate the registers a lot better.  I
> noticed that qemu for x86 provides exactly this kind of annotation
> information in its register target.xml definitions (v.
> lldb/test/API/functionalities/gdb_remote_client/TestRegDefinitionInParts.py
> ) but I don't THINK we do anything with these annotations today.  Not at
> all essential to this work, but just noting that this is something we all
> would like to see better support for.
>
> As for annotating the reason the program stopped on an MTE exception,
> Ismail was working on something similar in the past - although as you note,
> the really cool thing would be decoding the faulting instruction to
> understand what target register was responsible for the fault (and maybe
> even working back via the debug info to figure out what user-level variable
> it was??) to annotate it, which is something we're not doing anywhere right
> now.  There was a little proof-of-concept thing that Sean Callanan did
> years ago "frame diagnose" which would try to annotate to the user in
> high-level source terms why a fault happened, but I think it was using some
> string matching of x86 instructions to figure out what happened. :)
>
> We're overdue to upstream the PAC support for lldb that we're using, it's
> dependent on some other work being upstreamed that hasn't been done yet,
> but the general scheme involves querying the lldb-server / debugserver /
> corefile to get the number of bits used for virtual addressing, and then it
> just stomps on all the other high bits when trying to dereference values.
> If you do 'register read' of a function pointer, we show the actual value
> with PAC bits, then we strip the PAC bits off and if it resolves to a
> symbol, we print the stripped value and symbol that we're pointing to. It
> seems similar to what MTE will need -- if you have a variable pointing to
> heap using MTE, and you do `x/g var`, lldb should strip off the MTE bits
> before sending the address to read to lldb-server. The goal with the PAC UI
> design is to never hide the PAC details from the user, but to additionally
> show the PAC-less address when we're sure that it's an address in memory.
> Tougher to do that with MTE because we'll never be pointing to a symbol, it
> will be heap or stack.
>
> J
>
>
>
>
>
> > On Aug 10, 2020, at 3:41 AM, David Spickett via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi all,
> >
> > What follows is my proposal for supporting AArch64's memory tagging
> > extension in LLDB. I think the link in the first paragraph is a good
> > introduction if you haven't come across memory tagging before.
> >
> > I've also put the document in a Google Doc if that's easier for you to
> > read:
> https://docs.google.com/document/d/13oRtTujCrWOS_2RSciYoaBPNPgxIvTF2qyOfhhUTj1U/edit?usp=sharing
> > (please keep comments to this list though)
> >
> > Any and all comments welcome. Particularly I would like opinions on
> > the naming of the commands, as this extension is AArch64 specific but
> > the concept of memory tagging itself is not.
> > (I've added some people on Cc who might have particular interest)
> >
> > Thanks,
> > David Spickett.
> >
&

Re: [lldb-dev] Deprecating Python2 and adding type-annotations to the python API

[Pavel Labath via lldb-dev]

On 04/08/2020 02:37, Jonas Devlieghere via lldb-dev wrote:
> Hi Nathan,
> 
> Thanks for bringing this up. I've been expecting this question for a
> while now. 
> 
> Python 2 is end-of-life and we should move to Python 3. I'm pretty sure
> nobody here disagrees with that. Unfortunately though, we still have
> consumers, both internally and externally, that still rely on it. We're
> actively making an effort to change that, but we're not quite there yet. 
> 
> That said, I think we should continue moving in that direction. In line
> with the rest of LLVM moving to Python 3 by the end of the year, we've
> already made it the default. All our bots on GreenDragon are also
> building against Python 3.
> 
> As a first step, for the next release, I propose we remove the fallback
> to Python 2 and make it the only supported configuration. At the same
> time we can convert any scripts and tools (I'm thinking of the lit
> configurations, the lldb-dotest and lldb-repro wrappers, etc) to be
> Python 3 only. During this time however, we'd ask that the bindings and
> the test suite remain compatible with Python 2. Given that Python 3 is
> the only supported configuration for developers, we'd take on the burden
> of maintaining Python 2 compatibility in the test suite and correcting
> (accidental) incompatibilities.
> 
> When the 12.0 release is cut, we can reconsider the situation. If we're
> still not ready by then to drop Python 2 support, I  propose another
> intermediate step where we remove Python 2 support from the upstream
> repository, but ask the community to not actively modernize the test
> suite and the bindings. In this situation we'd be dealing with the merge
> conflicts in our downstream fork and this would avoid an endless number
> of conflicts in the test suite. 
> 
> Finally, presumably after the 13.0 release, we'd drop that last
> requirement. 
> 
> Please let me know if you think that sounds like a reasonable timeline.
> 
> Thanks,
> Jonas
> 



This sounds like a good plan to me. If lldb is supposed to remain
buildable with python2, then I also don't see a problem with keeping the
cmake bits which enable that. We could make it harder to build with
python2 accidentally by requiring the user to set a variable similar to
the LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN thingy.

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

[lldb-dev] [Bug 47100] A project should not contain unreachable code.(Code is commented out partially)(project/lldb/source/Plugins/Platform/MacOSX/PlatformRemoteAppleBridge.cpp:line 101)

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47100

Jonas Devlieghere  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Jonas Devlieghere  ---
Tatyana fixed this in bc056b3aa7130923ab9ad0505c5a8d65ea721e39

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 47101] LHS and RHS of a logical binary-operator (&&, ||), relational/equality binary-operator expression should not contain the same sub-expression.(llvm-project/lldb/source/Plugins/Sy

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47101

Jonas Devlieghere  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Jonas Devlieghere  ---
Fixed in b448eda4066ff5dee2517018e386893ab629f9e8.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev