[lldb-dev] problem resolving symbolic breakpoint on a remote target

[Adrian Harris via lldb-dev]

Thanks Jim - that makes sense for the types of targets that lldb interacts with mostly.

In my particular case, nothing is getting 'launched' - rather I'm attaching to an already running target. The elf that I'm pointing to is an exact executable image as the target has no OS to speak of and is very primitive.

Would it make sense to write a simple process plugin for my target? I'm a little fuzzy on exactly how the 'process' interacts with the gdb-remote target in lldb however.

More generally, how does lldb figure out where symbols are in an arbitrary target when the use mode is attach, as opposed to launching the process (therefore learning the layout).

Adrian



> On Nov 8, 2018, at 11:36 AM, Jim Ingham <jingham at apple.com> wrote:
> 
> lldb finds the symbol you asked for in the elf file's symbols, and makes a "location" for that address in that binary (as a section-relative address).  But that won't help it actually SET the breakpoint, since that doesn't tell us where that section will end up in the executable image when it runs.  It is the job of the DynamicLoader plugin for whatever platform you are debugging to observe a process as it is getting launched and register where all the sections land memory.  The section load map is the storage for this information.  If that isn't getting filled in then we won't be able to actually set the breakpoint in the target.  It sounds like the Dynamic Loader step is missing.
> 
> Jim
> 
> 
>> On Nov 8, 2018, at 10:20 AM, Adrian Harris via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>> 
>> (lldb) file tile.elf
>> Current executable set to 'tile.elf' (cs).
>> (lldb) b main
>> lldb             Target::AddBreakpoint (internal = no) => break_id = 1: name = 'main'
>> 
>> 
>> lldb             Added location: 1.1: 
>> module = tile.elf
>> compile unit = token_pass.c
>> function = main
>> location = token_pass.c:74
>> address = tile.elf[0x0410]
>> resolved = false
>> hit count = 0   
>> 
>> 
>> Breakpoint 1: where = tile.elf`main + 16 at token_pass.c:74, address = 0x0410
>> (lldb) gdb-remote server4:33722
>> Process 1 stopped
>> * thread #1, stop reason = signal SIGTRAP
>>   frame #0: 0x0422
>> tile.elf`main:
>>   tile.elf[0x422] <+34>: eq16   r5, 0
>>   tile.elf[0x424] <+36>: addc16 r0 = r7, 0
>>   tile.elf[0x428] <+40>: eq16   r0, r7
>>   tile.elf[0x42a] <+42>: jc     0xb
>> (lldb) break list
>> Current breakpoints:
>> 1: name = 'main', locations = 1
>> 1.1: where = tile.elf`main + 16 at token_pass.c:74, address = tile.elf[0x0410], unresolved, hit count = 0 
>> 
>> So it is still not resolved.
>> 
>> Adrian
>> 
>> 
>>> On Nov 8, 2018, at 11:06 AM, ted.woodward at codeaurora.org wrote:
>>> 
>>> What happens if you do this:
>>> 
>>> (lldb) file tile.elf
>>> (lldb) b main
>>> (lldb) gdb-remote <address>
>>> 
>>> ?
>>> 
>>> --
>>> Ted Woodward
>>> Qualcomm Innovation Center, Inc.
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>>> 
>>> -----Original Message-----
>>> From: lldb-dev <lldb-dev-bounces at lists.llvm.org> On Behalf Of Adrian Harris via lldb-dev
>>> Sent: Thursday, November 8, 2018 11:09 AM
>>> To: via lldb-dev <lldb-dev at lists.llvm.org>
>>> Subject: [lldb-dev] problem resolving symbolic breakpoint on a remote target
>>> 
>>> Hi Everyone,
>>> 
>>> I'm unable to resolve *symbolic* breakpoints on a gdb-remote target. Address breakpoints work fine. I suspect this is probably some form of user-error, but I've had no luck figuring it out on my own.
>>> 
>>> My target has llvm support and lldb has been patched to add a new target as well.
>>> 
>>> Debug information is correct in the image.
>>> 
>>> My steps are as follows:
>>> 
>>> (lldb) gdb-remote <address>
>>> ... connection happens
>>> (lldb) image add tile.elf
>>> (lldb) target modules list
>>> [  0] 89569B3D-0000-0000-0000-000000000000        tile.elf 
>>> (lldb) break main
>>> lldb             Target::AddBreakpoint (internal = no) => break_id = 1: name = 'main'
>>> 
>>> 
>>> lldb             warning: Tried to add breakpoint site at 0xffffffffffffffff but it was already present.
>>> 
>>> lldb             Added location: 1.1: 
>>> module = tile.elf
>>> compile unit = token_pass.c
>>> function = main
>>> location = token_pass.c:74
>>> address = tile.elf[0x0410]
>>> resolved = false
>>> hit count = 0   
>>> 
>>> 
>>> Breakpoint 1: where = tile.elf`main + 16 at token_pass.c:74, address = 0x0410
>>> 
>>> I traced the breakpoint resolving path in lldb and it ultimately fails in this function:
>>> addr_t
>>> SectionLoadList::GetSectionLoadAddress(const lldb::SectionSP &section) const {  // TODO: add support for the same section having multiple load addresses  addr_t section_load_addr = LLDB_INVALID_ADDRESS;  if (section) {
>>> std::lock_guard<std::recursive_mutex> guard(m_mutex);
>>> sect_to_addr_collection::const_iterator pos =
>>>     m_sect_to_addr.find(section.get());
>>> 
>>> if (pos != m_sect_to_addr.end())
>>>   section_load_addr = pos->second;
>>> }
>>> return section_load_addr;
>>> }
>>> 
>>> ... because the m_sect_to_addr map is not populated. I think that should happen in 
>>> 
>>> bool SectionLoadList::SetSectionLoadAddress(const lldb::SectionSP &section,
>>>                                         addr_t load_addr,
>>>                                         bool warn_multiple) {
>>> 
>>> .. but it is never called. This is what makes me think I'm leaving out a critical step.
>>> 
>>> Thanks for any help,
>>> Adrian
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>> 
>> 
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>