Re: [lldb-dev] Symbol Server for LLDB

[Adrian McCarthy via lldb-dev]

I know several people here have been looking for a generic, cross-platform
way to locate symbols.  One idea here was to make the symbol fetcher a
Python script that could use the SBAPI to interrogate the debugger to
determine what's needed.  This isn't that different than a separate binary,
but it might make it easier for users to customize it for their environment.

Anyway, I like the idea of a query out to possibly user-provided symbol
fetcher, regardless of the details.

On Fri, Jul 12, 2019 at 3:29 PM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> This is currently handled in each Platform subclass. The only platform
> that has the ability to locate symbol automatically are the Darwin
> platforms and those use DebugSymbols.framework to locate the symbols.
>
> That being said, I have been thinking about doing this in a generic way
> that would work for all platforms. My idea is to allow a setting that would
> be set that could specify a executable that would get run with arguments
> that specify the data to be looked up. My first inclination was we would
> pass down a JSON request, and the executable would try to fetch the binary
> requested the JSON, and responsd with a JSON reply specifying where the
> symbols were fetched locally (or made available on a network mount). So we
> might send JSON request that looks something like:
>
> { "type": "symbol-fetch", "basename": "libfoo.so", "uuid":
> "307E4F5E-EB63-3CC8-B940-9F89BB46098D", "arch": "armv7-apple-ios" }
>
> and it could respond with success:
> { "status": "success", "path": "/path/to/cache/.../debug/info/libfoo.so" }
>
> We can include more details in here, like the source path remapping that
> might need to happen so paths can be remapped and used in LLDB to display
> the sources correctly. For info on how we did this for
> DebugSymbols.framework on Darwin see:
>
> http://lldb.llvm.org/use/symbols.html
>
> We specified the "arch" in the original packet so we can have one or more
> symbol servers registered with the LLDB settings:
>
> (lldb) setting append target.symbol-servers /path/to/ios-symbol-server
> (lldb) setting append target.symbol-servers /path/to/linux-symbol-server
>
> and each binary could respond with an status stating that the binary isn't
> support by a plugin:
>
> { "status": "unsupported" }
>
> or return an error if we found the right plug-in but the file wasn't
> available for some reason:
>
> { "status": "failed", "error": "file not available in ..." }
>
> The idea is the Platform.cpp would be the one that would run these scripts
> if the settings were set.
>
> If we want to get really fancy the symbol-server binaries could also be
> asked to return a list of supported target triples so we could avoid call
> all of the symbol servers in the "target.symbol-servers" list. So we would
> ask each symbol server to register itself:
>
> { "type": "register" }
>
> And they could respond with a list of supported triples or other data:
>
> { "supported-arch": [ "*-apple-macos", "*-apple-ios", "*-tvos-ios" ] }
>
> Comments?
>
> On Mar 24, 2019, at 11:11 PM, Murali Venu Thyagarajan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hello,
>
> Is there a way to setup a symbol server for lldb just like how I could
> setup a centralized and indexed symbol server for Windbg. Please let me
> know.
>
> Thanks,
> Murali
> ___
> 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 mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Needs help contributing to lldb-vscode.

[Greg Clayton via lldb-dev]

Fine to refactor any way that makes it easier for people to re-use or add new 
VS Code DAP plug-ins! I agree with all comments so far.

Greg

> On Mar 13, 2019, at 12:50 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> On 12/03/2019 20:34, Leonard Mosescu via lldb-dev wrote:
>> Greg, what do you think?
>> On Tue, Mar 12, 2019 at 11:50 AM Qianli Ma > > wrote:
>>Hi lldb community,
>>I am currently working on a project related to lldb. I'd like to
>>write a DAP RPC server similars to lldb-vscode.cc
>>
>> 
>>  but
>>exports I/O to internal RPC clients. Doing so requires me to reuse
>>some functions defined in lldb-vscode.cc
>>
>> .
>>However as those functions are defined using forward declaration I
>>am not able to do that.
>>I'd like refactor the code a bit. More specifically, I'd like to
>>extract all helper functions in lldb-vscode.cc
>>
>> 
>>  into
>>a separate file and create a header for it.  BTW, IMO it's good to
>>make this lldb-vscode more general so that it can be used by other
>>debugger frontends besides vscode.
>>Please let me know WDYT and how I can proceed to submit changes for
>>review.
>>Thanks and Regards
>>Qianli
> 
> The way I understand this idea, you want to make (parts of) lldb-vscode a 
> library. The way this is usually done in llvm is that you put all of the 
> library stuff in a separate folder, with its own headers, cmake target and 
> everything. Then, you can make lldb-vscode executable (or whatever its 
> called) link against that library. Your downstream tool can do the same.
> 
> I think doing that is a good idea. The only part we need to figure out is 
> where to put the new library code. Normally, all our library-ized code lives 
> under source/, but this library would be special in that it sits on top of 
> the SB api rather than beneath it. So, even though it sounds a weird to have 
> a library living under tools/, it might be better to have the new library be 
> there instead of under source/.
> 
> regards,
> 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] Symbol Server for LLDB

[Greg Clayton via lldb-dev]

This is currently handled in each Platform subclass. The only platform that has 
the ability to locate symbol automatically are the Darwin platforms and those 
use DebugSymbols.framework to locate the symbols.

That being said, I have been thinking about doing this in a generic way that 
would work for all platforms. My idea is to allow a setting that would be set 
that could specify a executable that would get run with arguments that specify 
the data to be looked up. My first inclination was we would pass down a JSON 
request, and the executable would try to fetch the binary requested the JSON, 
and responsd with a JSON reply specifying where the symbols were fetched 
locally (or made available on a network mount). So we might send JSON request 
that looks something like:

{ "type": "symbol-fetch", "basename": "libfoo.so", "uuid": 
"307E4F5E-EB63-3CC8-B940-9F89BB46098D", "arch": "armv7-apple-ios" }

and it could respond with success:
{ "status": "success", "path": "/path/to/cache/.../debug/info/libfoo.so" }

We can include more details in here, like the source path remapping that might 
need to happen so paths can be remapped and used in LLDB to display the sources 
correctly. For info on how we did this for DebugSymbols.framework on Darwin see:

http://lldb.llvm.org/use/symbols.html 

We specified the "arch" in the original packet so we can have one or more 
symbol servers registered with the LLDB settings:

(lldb) setting append target.symbol-servers /path/to/ios-symbol-server
(lldb) setting append target.symbol-servers /path/to/linux-symbol-server

and each binary could respond with an status stating that the binary isn't 
support by a plugin:

{ "status": "unsupported" }

or return an error if we found the right plug-in but the file wasn't available 
for some reason:

{ "status": "failed", "error": "file not available in ..." }

The idea is the Platform.cpp would be the one that would run these scripts if 
the settings were set.

If we want to get really fancy the symbol-server binaries could also be asked 
to return a list of supported target triples so we could avoid call all of the 
symbol servers in the "target.symbol-servers" list. So we would ask each symbol 
server to register itself:

{ "type": "register" }

And they could respond with a list of supported triples or other data:

{ "supported-arch": [ "*-apple-macos", "*-apple-ios", "*-tvos-ios" ] }

Comments?

> On Mar 24, 2019, at 11:11 PM, Murali Venu Thyagarajan via lldb-dev 
>  wrote:
> 
> Hello,
> 
> Is there a way to setup a symbol server for lldb just like how I could setup 
> a centralized and indexed symbol server for Windbg. Please let me know.
> 
> Thanks,
> Murali
> ___
> 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] Process 45245 exited with status = -1 (0xffffffff) debugserver died with an exit status of 0x00000000

[Greg Clayton via lldb-dev]

You might be able to set LLDB_DEBUGSERVER_LOG_FILE in the lldb program's 
environment with a path, then set LLDB_SERVER_LOG_CHANNELS to a set of channels 
that lldb-server will use when logging. It might give you some insight as to 
what is going on. These environment variables will get passed along to the 
lldb-server when it runs allowing lldb-server to log anything so you might be 
able to tell what is going on.


> On Apr 4, 2019, at 9:44 AM, Steve Ravet via lldb-dev 
>  wrote:
> 
> lldb developers, I am having a problem with lldb that I hope you can help 
> with. I am debugging some C++ by running it, and attaching to the process 
> with lldb.  I get a nonsensical backtrace like this:
> 
> thread #37, name = 'xmsim', stop reason = signal SIGSTOP
>   frame #0: 0x2b96a2ab1409
> thread #38, name = 'xmsim', stop reason = signal SIGSTOP
>   frame #0: 0x2b96a2ab1409
> thread #39, name = 'xmsim', stop reason = signal SIGSTOP
>   frame #0: 0x2b96a2ab1409
> thread #40, name = 'xmsim', stop reason = signal SIGSTOP
>   frame #0: 0x2b96a2ab1409
> thread #41, name = 'xmsim', stop reason = signal SIGSTOP
>   frame #0: 0x2b96a2ab1409
> thread #42, name = 'xmsim', stop reason = signal SIGSTOP
>   frame #0: 0x2b96a2ab1409
> 
> And the first lldb command I try, I get the message in the subject, and the 
> debug session is dead.
> 
> I am on CentOS 6 with no possibility of moving to something newer.  I had 
> this problem with lldb 6.0.0, but recently moved to lldb 8.0.0 and still have 
> it. The compile toolchain is llvm 6.0.0. Where do I look to further debug 
> this, either why the process exited or why the debugserver died?
> 
> thanks,
> --steve
> ___
> 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] OS awareness in LLDB

[Greg Clayton via lldb-dev]

> On Apr 3, 2019, at 10:05 AM, Alexander Polyakov via lldb-dev 
>  wrote:
> 
> Hi lldb-dev,
> 
> Currently I'm working on an OS plug-in for multiple operating systems and 
> architectures, during my work, I noted a few moments I want to discuss with 
> the community.
> 
> 1) Adding RegisterContext to SB API:

Are you asking for the ability to create external native plug-ins instead of 
the python OS plug-in interface? 

> if you want your OS plug-in to support multiple architectures you need to 
> implement
> things like get_register_info, get_register_data... for each architecture.
> In my mind, we could do that using RegisterContext, for example: 
> get_register_info could just call 
> RegisterContext::GetRegisterContextAtIndex(idx), the number 
> of registers could be obtained from RegisterContext::GetRegisterCount();

What is missing from the python OS plug-in interface here? A register context 
represents all of the registers so I don't follow what you mean with what is 
stated above about asking for a register context by index. So you want multiple 
architectures to show up in the same process? If so this will require many 
changes to LLDB as each thread currently is assumed to have the same 
architecture as the process.

> get_register_data could return SBRegisterContext instead of just bytes, 
> then the process of
> fetching the register values might look as: for each register 
> SBRegisterContext::WriteRegister(reg_info, reg_value).
> Please correct me if I'm missing something.

I know the python OS plug-in doesn't have the ability to write a register right 
now. Again, a RegisterContext is a group of all of the register for a thread, 
so I am not sure SBRegisterContext is the right naming here. 

If we do make native plug-in we could do things very similar to the python OS 
plug-in:
- Define the registers for threads, possibly adding the ability to specify more 
than one register context to allow different threads to have different 
registers. This register context would define which registers are available, 
how they are grouped, etc.
- For each thread, figure out which register context it will use from one of 
the register layouts that was specified in above step
- allow read/write access to registers

The python OS plug-in has the ability to define a single different register 
context for threads, and the ability read registers. The architecture is 
assumed to be the same. 

> 
> 2) New lldb-mi command: -info-os
> the gdb-mi documentation defines this command and there is a problem with 
> it. To fully
> implement it, we should be able to get CPU ID a thread is running on, but 
> lldb
> does not have an abstraction for CPU ID at all, so it becomes unreal at 
> least for now.
> I'm going to partly implement this command for Zephyr (e.g. return some 
> value to indicate 
> that the CPU ID is undefined) and I want to know if the community is 
> interested in implementing
> that command inside lldb-mi (at least in part).

We could implement the ability for a target to have registers for registers 
that are globally accessible, like the CPU ID register. Any register that has a 
single value for all threads in a  process would fall into this category. The 
discovery and reading and writing would be very similar to 
lldb_private::RegisterContext, just a different set.

> 
> -- 
> Alexander
> ___
> 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] Support for AArch64/Arm64 scalable vector extension (SVE)

[Greg Clayton via lldb-dev]

Sounds like each register can very in size each time you stop if I read the 
docs correctly. As Pavel said "dynamic_size_dwarf_expr" might work for you 
here. Registers in a lldb_private::RegisterContext can have their sizes using:

  uint32_t RegisterContext::UpdateDynamicRegisterSize(const 
lldb_private::ArchSpec &arch, RegisterInfo *reg_info);

Now this function isn't currently virtual, so it currently has one way to 
update the register size that must use the 
RegisterInfo::dynamic_size_dwarf_expr_bytes and 
RegisterInfo::dynamic_size_dwarf_len members. But it could be made virtual if 
your the register size couldn't be determined a DWARF expression and then your 
register context would need to figure things out on the fly.

lldb_private::RegisterContext has ReadAllRegisterValues and 
WriteAllRegisterValues that is used to save/restore register state before we 
modify registers values for an expression that gets run in a thread. This might 
be tricky for this case if the expression you run modifies the SVE register 
state and prior to running the expression you have a few registers that are a 
certain number of bytes in size, but after the expression, they have changed. 
In that case, can you modify the kernels notion of this so that saving and 
restoring registers works correctly?

> On Apr 24, 2019, at 3:07 PM, Omair Javaid via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I am going to be starting work on implementing LLDB support for AArch64/Arm64 
> scalable vector extension (SVE) in coming weeks. For a quick walk through of 
> SVE please read through this doc here: 
> https://www.kernel.org/doc/Documentation/arm64/sve.txt 
> 
> 
> In summary it allows hardware + kernel which support SVE to have variable 
> vector register lengths which can be configured as per system requirements on 
> per process or thread basis. 
> 
> I have been informed that there might be some downstream patches and I would 
> like to collaborate with anyone who is willing to contribute their completed 
> or in-progress work.
> 
> I would also like to open a discussion on how we can implement variable 
> length registers in LLDB and what could be the consequences of those changes.
> 
> Looking forward to hearing from the community.
> 
> Thanks!
> 
> --
> Omair Javaid
> www.linaro.org 
> 
> ___
> 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: Removing SymbolVendor indirection

[Greg Clayton via lldb-dev]

Pavel stopped by a few days ago and we discussed this. SymbolVendor was 
originally made to allow one or more object files to be used to provide the 
most complete view of a program when debugging, but what happened is we put all 
of the "using multiple files" kind of support down into the SymbolFile level 
where it coordinates with the Module (via common sections lists and symbols). 
So the SymbolVendor level ends up being used to locate symbols mostly these 
days. So I am fine with looking at a patch that splits this up and possibly 
renames or moves the SymbolVendor functionality that locates symbol files to 
another class.

CC'ing Jim in case he has anything he wants to chime in with.

Greg

> On Jun 11, 2019, at 6:11 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> Hello all,
> 
> we currently have an almost identical set of about 20-odd functions on 
> ModuleList, Module, SymbolVendor and SymbolFile classes. The only thing that 
> the SymbolVendor functions are doing is taking the Module mutex, and then 
> calling the equivalent SymbolFile function to do the work. The only useful 
> task the objects of this class do is to hold the list of parsed compile units 
> and types.
> 
> It also seems like at some point the intention was for the SymbolVendor to be 
> able to host multiple SymbolFiles, but right now nobody makes use of that 
> feature.
> 
> Therefore, I propose to remove the SymbolVendor indirection and have Module 
> functions (and everybody else) call the SymbolFile directly when they need to.
> 
> Holding the compile unit and type lists is something that can be easily 
> implemented in the base SymbolFile class instead of the symbol vendor. In 
> fact, I would say that it is more natural to implement it that way, as it 
> would change code like
>  m_obj_file->GetModule()->GetSymbolVendor()->SetCompileUnitAtIndex(
>dwarf_cu->GetID(), cu_sp);
> into
>  SetCompileUnitAtIndex(dwarf_cu->GetID(), cu_sp);
> 
> Locking the module mutex is also a responsibility that can be handled by the 
> SymbolFile class. I would say that this also makes things cleaner, because 
> even right now, the SymbolFile instances need to be aware of locking. E.g., 
> some functions in SymbolFileDWARF (which is the only battle-tested symbol 
> file implementation right now) take the module mutex themselves, while others 
> assert that the module mutex is already taken.
> 
> The ability to have more than one SymbolFile for a module sounds useful, but: 
> a) nobody uses it; b) I'm not sure it would really work in the current form. 
> The reason for (b) is that the SymbolFile interface assumes a fixed numbering 
> of compile units starting with zero. As such, this would require two 
> SymbolFile instances to be aware of themselves anyway, in order to present a 
> coherent compile unit list to the rest of lldb.
> 
> I don't think that the removal of SymbolVendor indirection would remove the 
> possibility of multiple SymbolFiles though. Should anyone wish to do so, he 
> can always implement a CombiningSymbolFile class, which will contain other 
> symbol files, and delegate to them. This is kind of what is already 
> happening, with SymbolFileDWARFDebugMap, and the external module lists in 
> SymbolFileDWARF.
> 
> I already have a proof of concept patch which implements this idea. It's not 
> a particularly big one -- it touches about 1k lines of code. If we agree this 
> is the way to go, I can clean it up and submit for review as a sequence of 
> smaller patches.
> 
> regards,
> pavel
> 
> PS: I am not saying anything about the role of the SymbolVendor in finding 
> the symbol files. This is because I am not planning to change that in any 
> way. The idea is that the SymbolVendor will still be responsible for finding 
> the symbol file, but it will then return the symbol file directly, instead of 
> wrapping it in a SymbolVendor instance.
> 
> PPS: To get an idea of the changes involved, here's a stat of the changes 
> required. Most of the changes are in SymbolVendor.cpp, and involve deleting 
> code. The changes in other files are mostly mechanical and involve changing 
> code fetching the SymbolVendor to access the SymbolFile directly.
> 
> include/lldb/Core/Module.h |  43 +-
> include/lldb/Symbol/SymbolFile.h   |  39 +-
> include/lldb/Symbol/SymbolVendor.h | 135 +-
> include/lldb/Symbol/Type.h |   2 -
> include/lldb/lldb-private-interfaces.h |   4 +-
> source/API/SBCompileUnit.cpp   |   9 +-
> source/API/SBModule.cpp|  37 +-
> source/Commands/CommandObjectTarget.cpp| 173 
> source/Core/Address.cpp|  38 +-
> source/Core/Module.cpp | 121 +++---
> source/Core/SearchFilter.cpp   |   8 +-
> source/Expression/IRExecutionUnit.cpp  |   6 +-
> .../MacOSX-DYLD/DynamicLoad

Re: [lldb-dev] Adding a new architecture into LLDB

[Greg Clayton via lldb-dev]

> On Jun 18, 2019, at 7:08 AM, Romaric Jodin via lldb-dev 
>  wrote:
> 
> Hello everyone,
> 
> I am trying to add a new architecture into LLDB.
> My architecture is a accelerator with its own ISA for which we have a LLVM 
> backend (release 7.1).
> 
> I have started by creating a new NativeProcessProtocol for my architecture. 
> So I have a lldb-server that run on a x86, but which takes care of process of 
> my architecture. I have forced it to use my NativeProcessProtocol.
> I have a issue with this method because as the lldb-server is compile to run 
> on a x86, some part of the code think that it is managing x86 process.

> 
> Maybe I am going in the wrong direction to add such new architecture to LLDB, 
> I would be happy to try any other suggestions.

lldb-server is currently meant to build a native debugging GDB server that can 
be used with lldb. If you want to always build a cross build lldb-server for 
your architecture, you will want to add a new tool that gets built in the 
CMakeList.txt in the tools/lldb-server directory. You will need to build it 
into a different binary like "lldb-server-dpu". I am not sure how much trouble 
you will run into doing this though as much of the lldb-server build assumes 
things match the current host.

> 
> If you are interested, you can have a look at my branch "dev/rjodin/lldb_dpu" 
> in our forked repo of LLDB "https://github.com/upmem/lldb 
> ". The branch is not clean, but it can help 
> you understand what I did.
> 
> Thanks,
> -- 
> Romaric JODIN
> UPMEM
> Software Engineer
> 
> 
> ___
> 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] Signal stack unwinding and __kernel_rt_sigreturn

[Greg Clayton via lldb-dev]

> On Jun 21, 2019, at 1:24 PM, Joseph Tremoulet via lldb-dev 
>  wrote:
> 
> Hi,
>  
> I'm trying to use lldb in a project where I need to report stack traces from 
> signal handlers, and need to do so on aarch64 Linux.  Even for "synchronous" 
> signal handling, I'm hitting a couple issues preventing this from working 
> "out of the box":
> 1 - The platform signal handler trampoline function on the stack is 
> __kernel_rt_sigreturn, not sigtramp.  I'm wondering if it's ok to just add 
> __kernel_rt_sigreturn to the list of trap handler symbol names in 
> PlatformLinux, or if I need to include it in 
> "UserSpecifiedTrapHandlerFunctionNames", or something else

If this is a linux kernel issue where the function can be either or both 
"sigtramp" or "__kernel_rt_sigreturn" and everything else behaves correctly 
this is fine.

> 2 - When the user handler is invoked, its return address is set to the very 
> first byte of __kernel_rt_sigreturn, which throws off unwinding because we 
> assume that frame must really be at a call in the preceding function.  I 
> asked about this on IRC, where Jan Kratochvil mentioned that the decrement 
> shouldn't happen for frames with S in the eh_frame's augmentation.  I've 
> verified that __kernel_rt_sigreturn indeed has the S.  I'm not sure where I'd 
> find official documentation about that, but the DWARF Standards Committee's 
> wiki[1] does link to Ian Lance Taylor's blog[2] which says "The character ‘S’ 
> in the augmentation string means that this CIE represents a stack frame for 
> the invocation of a signal handler. When unwinding the stack, signal stack 
> frames are handled slightly differently: the instruction pointer is assumed 
> to be before the next instruction to execute rather than after it."  So I'm 
> interested in encoding that knowledge in LLDB, but not sure architecturally 
> whether it would be more appropriate to dig into the eh_frame record earlier, 
> or to just have this be a property of symbols flagged as trap handlers, or 
> something else.

If we have hints that unwinding should not backup the PC, then this is fine to 
use. We need the ability to indicate that a lldb_private::StackFrame frame 
behaves like frame zero even when it is in the middle. I believe the code for 
sigtramp already does this somehow. I CC'ed Jason Molenda so he can chime in.


> I'd very much appreciate any feedback on this.  I've put up a patch[3] on 
> Phab with a testcase that demonstrates the issue (on aarch64 linux) and an 
> implementation of the low-churn "communicate this in the trap handler symbol 
> list" approach.
>  
> Thanks,
> -Joseph
>  
> [1] - http://wiki.dwarfstd.org/index.php?title=Exception_Handling 
> 
> [2] - https://www.airs.com/blog/archives/460 
> 
> [3] - https://reviews.llvm.org/D63667 
>  
> ___
> 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] "error: summary string parsing error" on Fedora 30

[Greg Clayton via lldb-dev]

We have a summary provider for std::string that is built into LLDB that must 
not be working with the C++ runtime you are using. The current summary string 
that is used is in source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp in 
LoadLibStdcppFormatters:

  lldb::TypeSummaryImplSP std_string_summary_sp(
  new StringSummaryFormat(stl_summary_flags, "${var._M_dataplus._M_p}"));

So do a "frame var --raw msg" and see what the members of your std::string look 
like. I am guessing you won't see "_M_dataplus" or "_M_p" in there. The "${var" 
means your std::string variable, and we are trying to access 
"msg._M_dataplus._M_p" to see what the string looks like.


> On Jun 24, 2019, at 10:26 PM, Bob Eastbrook via lldb-dev 
>  wrote:
> 
> With Clang 8.0.0 and libstd++ 9.1.1 on Fedora 30 x86_64, I get this
> error from LLDB when trying to see the value of a string:
> 
> "error: summary string parsing error"
> 
> The code is simply:
> 
> std::string msg{"foo bar baz"};
> 
> With libcxx 8.0.0, instead of the above error, I simply see "??" when
> inspecting the msg variable.
> 
> All of the above works fine for me in Ubuntu 19.04. I only have the
> problem with Fedora 30.  Tried in both CLion and VS Code.
> 
> How should I troubleshoot this?  Could I be missing a package?
> ___
> 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] [Release-testers] 8.0.1-rc4 release has been tagged.

[Dimitry Andric via lldb-dev]

On 11 Jul 2019, at 05:24, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged the 8.0.1-rc4 release, please begin testing.  This will 
> (hopefully)
> be the last release candidate.  If all goes well, I will tag the final release
> next Wednesday.

As with 8.0.1 rc3, I had to disable compiler-rt for this test run, as most of 
the sanitizers are totally broken. This is tracked in PR40761.

Main test results on amd64-freebsd11:

Expected Passes: 53262 (rc3: 53266)
Passes With Retry  : 1 (rc3: 0)
Expected Failures  :   213 (rc3:   213)
Unsupported Tests  :  1718 (rc3:  1718)
Unresolved Tests   : 8 (rc3: 8)
Unexpected Passes  : 3 (rc3: 3)
Unexpected Failures:62 (rc3:59)

Main test results on i386-freebsd11:

Expected Passes: 53114 (rc3: 53113)
Passes With Retry  : 1 (rc3: 0)
Expected Failures  :   229 (rc3:   229)
Unsupported Tests  :  1540 (rc3:  1540)
Unresolved Tests   : 8 (rc3: 7)
Unexpected Passes  : 5 (rc3: 5)
Unexpected Failures:   175 (rc3:   178)

Uploaded:

SHA256 (clang+llvm-8.0.1-rc4-amd64-unknown-freebsd11.tar.xz) = 
ffd4546aab6d7944b4063a8fd9f4022be8b4904760becc76ee2ea64d3fa50d7e
SHA256 (clang+llvm-8.0.1-rc4-i386-unknown-freebsd11.tar.xz) = 
52ab6fa940a4143c1ac2fc50f2aa0994b92a56fbf7d8b1146b74a7c5de743607

-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] Using LLDB C++ API for automated debugging sessions

[Greg Clayton via lldb-dev]

You need to call SBDebugger::Initialize() before calling SBDebugger::Create().

Also, please use the SBLaunchInfo method for launching if possible where you 
create a SBLaunchInfo, then call tgt.Launch() with the instance.

Other than that, as Jim said, you need to setup an event loop if you don't use 
synchronous mode where you wait for events and respond to events. 

Greg

> On Jun 26, 2019, at 4:58 AM, Jayvee Neumann via lldb-dev 
>  wrote:
> 
> Dear LLDB developers,
> 
> I am currently stuck while using the C++ API of LLDB. I am unable to 
> correctly launch a process.
> The code I have written looks as follows:
> 
> int main(int argc, char *argv[]){
> LLDBSentry senty;
> SBDebugger dbg(SBDebugger::Create());
> ...
> const char *exeFilePath = "./target";
> const char *arch = "x86_64";
> const char *platform = "";
> const char *dependentLibs = "";   
> SBError error;
> SBTarget tgt = dbg.CreateTarget(exeFilePath, arch, platform, dependentLibs, 
> error);
> ...
> SBListener listen;
> SBProcess proc = tgt.Launch(
> listen,
> nullptr,
> nullptr,
> nullptr,
> "targetout.txt",
> nullptr,
> "./",
> eLaunchFlagExec | eLaunchFlagDebug,
> false,
> error
> );
> ...
> SBThread thread = proc.GetSelectedThread(); // (1)
> ...
> }
> 
> The complete code (usr.cpp) is added as an attachment to this email.
> Its output is also added as a text file (stdout.txt) to this email.
> 
> The problem I have is, that thread.IsValid() returns null after line (1). 
> Furthermore, the process says, that its state is eStateStopped, when asked 
> via proc.IsStopped() it answers "false", however.
> The debugging target is a simple file that writes a hexadecimal number every 
> 10us to stdout. I can see that the target is running, because targetout.txt 
> is growing in size and its content is valid output from "target".
> Can you tell me what my mistake is?
> 
> Kind Regards
> Jayvee
> 
> ___
> 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] lldb-vscode VSCode extension hangs indefinitely on Windows

[Greg Clayton via lldb-dev]

You might want to take a look at what the lldb-vscode process is doing by 
attaching a debugger to it in case that will shed any light.

Other options are add a "initCommands" to your launch config:

"initCommands": ["log enable -f /tmp/log.txt lldb process"],

Then look at the log and see if any progress is being made. I am not sure how 
good the logging is in the ProcessWindow process plug-in within LLDB.

> On Jul 5, 2019, at 6:23 AM, Daan De Meyer via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I've been trying out the lldb-vscode extension bundled with LLVM. I managed 
> to get it working flawlessly on Linux but I'm having trouble getting it to 
> work on Windows. When starting the debugger with a simple hello world program 
> built with CMake, it hangs indefinitely without outputting any kind of error 
> or log (as far as I can see). The Windows debugger bundled with the official 
> Microsoft VSCode C++ extension does not have this problem.
> 
> I installed the extension by creating the llvm-org.lldb-vscode-0.1.0 folder 
> in the vscode extensions folder in my home directory (as detailed in the 
> lldb-vscode readme). I then copied the following files into this directory:
> 
> - lldb-vscode/package.json -> package.json
> - llvm/bin/liblldb.dll -> bin/liblldb.dll
> - llvm/bin/lldb-vscode.exe -> bin/lldb-vscode.exe
> 
> I confirmed the lldb-vscode.exe executable inside the extension folder starts 
> correctly from within a Windows cmd console. I then created a VSCode 
> launch.json file with the following contents:
> 
> {
>   "version": "0.2.0",
>   "configurations": [
> {
>   "type": "lldb-vscode",
>   "request": "launch",
>   "name": "Launch",
>   "program": "${workspaceRoot}/build/main.exe",
>   "args": [],
>   "env": [],
>   "cwd": "${workspaceRoot}"
> }
>   ]
> }
> 
> When starting the debugger, it hangs indefinitely instead of running and 
> printing "Hello, World!" as expected. I also confirmed the lldb-vscode.exe 
> was actually started by VSCode by checking the Windows Task Manager.
> 
> I'm hoping to fix this but I'm not sure how to proceed. I have two questions:
> 
> 1. Is this problem specific to my Windows installation or a general problem 
> with lldb-vscode? If someone could try to reproduce the problem it would be 
> much appreciated.
> 2. How do I go about debugging this issue? I could not find any debugger logs 
> even after setting VSCode's log level to trace. Any pointers on getting 
> started with this would also be appreciated.
> 
> Regards,
> 
> Daan De Meyer
> 
> ___
> 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] Reminder: SVN will be retired on Oct 21, 2019 -- Please migrate your workflows to github ASAP.

[Tom Stellard via lldb-dev]

On 07/12/2019 10:29 AM, paul.robin...@sony.com wrote:
> Hi Tom,
> 
> Thanks for driving this!  It's a big project and it's great to see
> the progress being made on it. My org's adaptation to the monorepo
> is in progress as we speak.
> 
> I had two hopefully easy questions.
> 1) Can we get a link to the status page from the llvm.org front page?
>That will make it a lot easier to find in the future.

Sure, I just added a link.

> 2) I assume everyone will need to have a GitHub account; is there any
>story needing to be told about correlating a GitHub account with
>our current SVN IDs?  I don't even have a GH account at this point,
>don't know what's involved in signing up.

We are still working on a process for mapping SVN accounts to GitHub accounts.
I will provide an update once we have something finalized.

-Tom

> 
> Thanks,
> --paulr
> 

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

Re: [lldb-dev] issue with StackFrame::GetSymbolContext

[Jim Ingham via lldb-dev]

A "raw image" is one that loads all the code at some address and doesn't have a 
dynamic loading mechanism.  So it really just means "a binary that doesn't use 
a dynamic loader."  I'm not sure why it was called "Strata"...

But the Strata is used to disambiguate cases where the object file format gets 
used both for user processes that have a dynamic linker, and for embedded uses 
that don't.  See for instance ObjectFile::Strata 
ObjectFileMachO::CalculateStrata which figures out from data in the object file 
whether it runs with the dynamic linker or not...

Jim

> On Jul 12, 2019, at 3:58 AM, Romaric Jodin  wrote:
> 
> Thanks Jim, it helped a lot. But it bings other questions.
> I managed to get the symbol by forcing the use of the DynamicLoaderStatic, 
> which is use only if the Strata is set to "eStrataRawImage".
> What is "Strata" ?
> Why is the Static DynamicLoader only use with the eStrataRawImage?
> 
> Right now, I don't feel the need to implement a DynamicLoader specific for my 
> backend as the static seems to be doing the job just fine. But maybe I'll 
> have to at some point.
> Anyway, Thanks again, it helps me going forward with the implementation.
> 
> Romaric
> 
> On Tue, Jul 9, 2019 at 7:53 PM Jim Ingham  wrote:
> It looks like you don't have a DynamicLoader plugin that tells lldb where 
> your binaries ended up in memory when the process ran.  The [ADDRESS] means 
> we are reading instructions from memory not from the on-disk binary.
> 
> Jim
> 
> 
> > On Jul 9, 2019, at 2:14 AM, Romaric Jodin via lldb-dev 
> >  wrote:
> > 
> > HI everyone,
> > 
> > I'm adding my architecture into lldb.
> > I'm having some trouble with the debug information on the stack frame.
> > LLDB is never displaying any source code. It seems that we I get in 
> > "StackFrame::GetSymbolContext" "m_flags" is always set to "0x" but 
> > my "m_sc" does not contains the information needed about the module 
> > ("module_sp=0x0").
> > But LLDB can read the elf file and find information like here:
> > 
> > Process 21312 stopped
> > * thread #1, name = 'DPUthread0', stop reason = suspended
> > frame #0: 0x8018
> > test`__bootstrap:
> > test[0x8018] <+24>: subr0, r0, 0x1, pl, 0x8010
> > test[0x8020] <+32>: jgeu   id, 0x3, 0x8058
> > test[0x8028] <+40>: jeqid, 0x2, 0x8038
> > test[0x8030] <+48>: boot   id, 0x1
> > 
> > or here:
> > 
> > (lldb) b main
> > Breakpoint 1: where = test`main + 32 at test.c:29, address = 0x8080
> > 
> > Do someone get what I'm missing?
> > 
> > Thanks,
> > -- 
> > Romaric JODIN
> > UPMEM
> > Software Engineer
> > 
> > 
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> 
> 
> -- 
> Romaric JODIN
> UPMEM
> Software Engineer
> 
> 

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

Re: [lldb-dev] Reminder: SVN will be retired on Oct 21, 2019 -- Please migrate your workflows to github ASAP.

[via lldb-dev]

Hi Tom,

Thanks for driving this!  It's a big project and it's great to see
the progress being made on it. My org's adaptation to the monorepo
is in progress as we speak.

I had two hopefully easy questions.
1) Can we get a link to the status page from the llvm.org front page?
   That will make it a lot easier to find in the future.
2) I assume everyone will need to have a GitHub account; is there any
   story needing to be told about correlating a GitHub account with
   our current SVN IDs?  I don't even have a GH account at this point,
   don't know what's involved in signing up.

Thanks,
--paulr

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

Re: [lldb-dev] [llvm-dev] Reminder: SVN will be retired on Oct 21, 2019 -- Please migrate your workflows to github ASAP.

[James Y Knight via lldb-dev]

On Fri, Jul 12, 2019 at 10:35 AM Sam Elliott via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> Tom
>
> I attempted to use `git llvm push` with the test-suite repository (which
> isn’t moving to the monorepo) and it didn’t work. I presume this was
> expected


Sorry about that -- it should work now, as of
https://github.com/llvm/llvm-project/commit/541faedd6675d8e312cb11b045d2f802e289d610


> It is slightly infuriating that most of the documentation as to how to use
> the SVN repositories has vanished (which is still relevant to contributing
> to test-suite and lnt), and it seems there is little guidance about what
> these repos will do when the monorepo moves to git and GitHub.
>

The plan is for these repos to live on github as well, the same way they
are laid out currently in the github project. E.g. test-suite lives in
https://github.com/llvm/llvm-test-suite).
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] issue with StackFrame::GetSymbolContext

[Romaric Jodin via lldb-dev]

Thanks Jim, it helped a lot. But it bings other questions.
I managed to get the symbol by forcing the use of the DynamicLoaderStatic,
which is use only if the Strata is set to "eStrataRawImage".
What is "Strata" ?
Why is the Static DynamicLoader only use with the eStrataRawImage?

Right now, I don't feel the need to implement a DynamicLoader specific for
my backend as the static seems to be doing the job just fine. But maybe
I'll have to at some point.
Anyway, Thanks again, it helps me going forward with the implementation.

Romaric

On Tue, Jul 9, 2019 at 7:53 PM Jim Ingham  wrote:

> It looks like you don't have a DynamicLoader plugin that tells lldb where
> your binaries ended up in memory when the process ran.  The [ADDRESS] means
> we are reading instructions from memory not from the on-disk binary.
>
> Jim
>
>
> > On Jul 9, 2019, at 2:14 AM, Romaric Jodin via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > HI everyone,
> >
> > I'm adding my architecture into lldb.
> > I'm having some trouble with the debug information on the stack frame.
> > LLDB is never displaying any source code. It seems that we I get in
> "StackFrame::GetSymbolContext" "m_flags" is always set to "0x" but
> my "m_sc" does not contains the information needed about the module
> ("module_sp=0x0").
> > But LLDB can read the elf file and find information like here:
> >
> > Process 21312 stopped
> > * thread #1, name = 'DPUthread0', stop reason = suspended
> > frame #0: 0x8018
> > test`__bootstrap:
> > test[0x8018] <+24>: subr0, r0, 0x1, pl, 0x8010
> > test[0x8020] <+32>: jgeu   id, 0x3, 0x8058
> > test[0x8028] <+40>: jeqid, 0x2, 0x8038
> > test[0x8030] <+48>: boot   id, 0x1
> >
> > or here:
> >
> > (lldb) b main
> > Breakpoint 1: where = test`main + 32 at test.c:29, address = 0x8080
> >
> > Do someone get what I'm missing?
> >
> > Thanks,
> > --
> > Romaric JODIN
> > UPMEM
> > Software Engineer
> >
> > 
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>

-- 
*Romaric JODIN*
UPMEM
*Software Engineer*
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Evaluating the same expression at the same breakpoint gets slower after a certain number of steps

[Gábor Márton via lldb-dev]

Guilherme,

Could you please check if you have any structural differences between the
ASTs you see when
1) you first evaluate your expression at breakpoint A
2) you evaluate your expression the second time at breakpoint A ?
The AST of the expression evaluator's context is dumped once a TagDecl is
completed, but you need to enable a specific logging: (log enable lldb ast).

I have a theory about the root cause of the slowness you experience, but it
requires proof from your test scenario.
There are known problems with the lookup we use in LLDB [1].
If the lookup mechanism cannot find a symbol then clang::ASTImporter will
create a new AST node.
Thus I am expecting a growing AST in your case at 2) with duplicated and
redundant AST nodes.
Why would the grown AST results in any slowness?
Because the lookup we use is in `clang::DeclContext::localUncachedLookup()`
and it has a fallback branch which I assume is executed in your case:
```
  // Slow case: grovel through the declarations in our chain looking for
  // matches.
  // FIXME: If we have lazy external declarations, this will not find them!
  // FIXME: Should we CollectAllContexts and walk them all here?
  for (Decl *D = FirstDecl; D; D = D->getNextDeclInContext()) {
if (auto *ND = dyn_cast(D))
  if (ND->getDeclName() == Name)
Results.push_back(ND);
  }
```
This for loop does a linear search on the list of the decls of a decl
context, which explains the slowing factor as the AST grows.
I wounder if you could help proving this theorem by first checking if the
AST grows and if yes then checking if this linear search is executed or not.

[1] If a symbol is in an `extern "C"` block then the existing lookup fails
to find it. I try to fix it in https://reviews.llvm.org/D61333

Thanks,
Gabor

On Thu, Jul 11, 2019 at 8:24 PM Jim Ingham via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> lldb realizes types from DWARF lazily.  So for instance, if an expression
> refers to a pointer to type Foo, we won't necessarily realize the full type
> of Foo from DWARF to parse that expression.  Then if you write a second
> expression that accesses a member of an object of type Foo, we will realize
> the full type for Foo.  Then if you run the first expression again, the
> pointer to Foo type in the lldb type system will now point to a realized
> type of Foo.  That should not make any difference, since if we were right
> the first time that we didn't need to know anything about Foo, it shouldn't
> matter whether the full type is realized or not.
>
> Similarly, the "expression with no side effects" could have also caused
> lldb to realize any number of other types.  We find names from type
> information in two ways: looking in the realized types, and looking in the
> name indexes we read from DWARF or (on systems without accelerator tables)
> from indexing the DWARF manually.  So the expression with no side effects
> will change the types in the realized types pool.  That also "should not
> matter" because if the expression X was looking up by name, the lookup
> through the name indexes when the type wasn't realized yet should be
> equivalent to the lookup in the realized types.
>
> We really have no choice but to realize types lazily in this way, the
> debugger would just run way too slowly on big projects if we didn't.  So
> the fact that one expression can change the state of the type system for a
> subsequent expression is a fact of life for lldb.  But if the lookup
> mechanism is working properly, then these changes shouldn't matter.  OTOH
> shouldn't and don't are not quite the same...
>
> Jim
>
>
> > On Jul 11, 2019, at 9:53 AM, Guilherme Andrade 
> wrote:
> >
> > Speaking more generally, can evaluating an expression with no side
> effects affect the outcome of subsequent evaluations? I.e, is it possible
> for the expression evaluation X to produce different results in the
> following scenarios?
> >
> > Scenario 1:   effects>  
> > Scenario 2:evaluation X>
> >
> > Thanks!
> >
> > On Tue, Jul 9, 2019 at 2:52 PM Guilherme Andrade 
> wrote:
> > Thanks for looking into this, Jason. I ended up realizing that it isn't
> about the number of evaluations; it is the exact location of the
> breakpoints that matters.
> >
> > I'm being able to consistently reproduce this by having two breakpoints
> (A and B) inside the same function, but B being inside the scope of a for
> loop that defines a couple extra variables. The first evaluation of
> 'undefinedVariable' at breakpoint A generates the following
> FindExternalLexicalDecls calls:
> >
> > FindExternalLexicalDecls[5] on (ASTContext*)01566104F030 in 'Type0'
> (CXXRecordDecl*)015668964438
> > FindExternalLexicalDecls[6] on (ASTContext*)01566104F030 in 'Type6'
> (CXXRecordDecl*)015668961BA8
> > FindExternalLexicalDecls[7] on (ASTContext*)01566104F030 in 'Type7'
> (CXXRecordDecl*)015668961A68
> > FindExternalLexicalDecls[8] on (ASTContext*)01566104F030 in 'Type8'
> (CXXRecordDecl*)015674F5