Re: [lldb-dev] Multiple platforms with the same name

[Greg Clayton via lldb-dev]

Platforms can contain connection specific setting and data. You might want to 
create two different "remote-linux" platforms and connect each one to a 
different remote linux machine. Each target which uses this platform would each 
be able to fetch files, resolve symbol files, get OS version/build 
string/kernel info, get set working directory from the remote server they are 
attached. Since each platform tends to belong to a target and since you might 
want to create two different targets and have each one connected to a different 
remote machine, I believe it is fine to have multiple instances.

I would vote to almost always create a new instance unless it is the host 
platform. Though it should be possible to create to targets and possibly set 
the platform on one target using the platform from another that might already 
be connected. 

I am open to suggestions if anyone has any objections.

Greg

> On Jan 17, 2022, at 8:18 AM, Pavel Labath  wrote:
> 
> Hello all,
> 
> currently our code treats platform name more-or-less as a unique identifier  
> (e.g. Platform::Find returns at most one platform instance --the first one it 
> finds).
> 
> This is why I was surprised that the "platform select" CLI command always 
> creates a new instance of the given platform, even if the platform of a given 
> name already exists. This is because Platform::Create does not search the 
> existing platform list before creating a new one. This might sound reasonable 
> at first, but for example the Platform::Create overload which takes an 
> ArchSpec first tries to look for a compatible platforms among the existing 
> ones before creating a new one.
> 
> For this reason, I am tempted to call this a bug and fix the name-taking 
> Create overload. This change passes the test suite, except for a single test, 
> which now gets confused because some information gets leaked from one test to 
> another. (although our coverage of the Platform class in the tests is fairly 
> weak)
> 
> However, this test got me thinking. It happens to use the the SB way of 
> manipulating platforms, and "creates" a new instance as 
> lldb.SBPlatform("remote-linux"). For this kind of a command, it would be 
> reasonable/expected to create a new instance, were it not for the fact that 
> this platform would be very tricky to access from the command line, and even 
> through some APIs -- SBDebugger::CreateTarget takes a platform _name_.
> 
> So, which one is it? Should we always have at most one instance of each 
> platform, or are multiple instances ok?

> cheers,
> pl
> 
> PS: In case you're wondering about how I run into this, I was trying to 
> create a pre-configured platform instance in (e.g.) an lldbinit file, without 
> making it the default. That way it would get automatically selected when the 
> user opens an executable of the appropriate type. This actually works, 
> *except* for the case when the user selects the platform manually. That's 
> because in that case, we would create an empty/unpopulated platform, and it 
> would be the one being selected because it was the /current/ platform.

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

Re: [lldb-dev] Source-level stepping with emulated instructions

[Jim Ingham via lldb-dev]

> On Jan 16, 2022, at 11:23 PM, Pavel Labath  wrote:
> 
> Hi Kjell,
> 
> if you say these instructions are similar to function calls, then it sounds 
> to me like the best option would be to get lldb to treat them like function 
> calls. I think (Jim can correct me if I'm wrong) this consists of two things:
> - make sure lldb recognizes that these instructions can alter control flow 
> (Disassembler::GetIndexOfNextBranchInstruction). You may have done this 
> already.
> - make sure lldb can unwind out of these "functions" when it winds up inside 
> them. This will ensure the user does not stop in these functions when he does 
> a "step over". This means providing it the correct unwind info so it knows 
> where the functions will return. (As the functions know how to return to the 
> original instructions, this information has to be somewhere, and is hopefully 
> accessible to the debugger.) Probably the cleanest way to do that would be to 
> create a new Module object, which would contain the implementations of all 
> these functions, and all of their debug info. Then you could provide the 
> unwind info through the usual channels (e.g. .debug_frame), and it has the 
> advantage that you can also include any other information about these 
> functions (names, line numbers, whatever...)

Pavel is right, if these blobs look like function calls with no debug 
information, then lldb won’t stop in them by default.  Note, the “no debug 
info" part is not a strict requirement, since lldb also has controls for 
“shared libraries we never stop in when stepping” and “name regular expressions 
for functions we don’t stop in”.  At present, those controls are just for 
user-specification.  But if you find you need to do something more 
programmatic, you can easily add another “don’t stop in me” check specific to 
your architecture.  

All this will work pretty transparently if the unwinder is able to tell us how 
to get out of the function and back to it’s caller.  But even if that’s not the 
case, the “should stop here” mechanism in lldb works by at a lower level by 
having the agent saying we should NOT stop here return a ThreadPlan telling us 
how to get to the caller frame.  For a function call, you get the step out plan 
for free.  But that’s not a requirement, your emulated instruction region 
doesn’t strictly need to be a function call, provided you know how to produce a 
thread plan that will step out of it.
 
Jim
  

> 
> pl
> 
> On 15/01/2022 07:49, Kjell Winblad via lldb-dev wrote:
>> Hi!
>> I'm implementing LLDB support for a new processor architecture that
>> the company I'm working for has created. The processor architecture
>> has a few emulated instructions. An emulated instruction works by
>> jumping to a specific address that contains the start of a block of
>> instructions that emulates the emulated instructions. The emulated
>> instructions execute with interrupts turned off to be treated as
>> atomic by the programmer. So an emulated instruction is similar to a
>> function call. However, the address that the instruction jumps to is
>> implicit and not specified by the programmer.
>> I'm facing a problem with the emulated instructions when implementing
>> source-level stepping (the LLDB next and step commands) for C code in
>> LLDB. LLDB uses hardware stepping to step through the address range
>> that makes up a source-level statement. This algorithm works fine
>> until the PC jumps to the start of the block that implements an
>> emulated instruction. Then LLDB stops because the PC exited the
>> address range for the source-level statement. This behavior is not
>> what we want. Instead, LLDB should ideally step through the emulation
>> instructions and continue until the current source-level statement has
>> been completed.
>> My questions are:
>> 1. Is there currently any LLDB plugin functionality or special DWARF
>> debug information to handle the kind of emulated instructions that I
>> have described? All the code for the emulated instructions is within
>> the same address range that does not contain any other code.
>> 2. If the answer to question 1 is no, do you have suggestions for
>> extending LLVM to support this kind of emulated instructions?
>> Best regards,
>> Kjell Winblad
>> ___
>> 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