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

[Adrian Harris via lldb-dev]

(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
>