(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.woodw...@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-boun...@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@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 §ion) 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 §ion,
> 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@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
