Thanks guys! Adding the plugin did the trick.
Adrian
> On Nov 8, 2018, at 1:01 PM, ted.woodw...@codeaurora.org wrote:
>
> You're probably going to want to use the Static DYLD plugin.
>
> --
> 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: jing...@apple.com <jing...@apple.com>
> Sent: Thursday, November 8, 2018 1:39 PM
> To: Adrian Harris <adrian.har...@mac.com>
> Cc: ted.woodw...@codeaurora.org; LLDB <lldb-dev@lists.llvm.org>
> Subject: Re: [lldb-dev] problem resolving symbolic breakpoint on a remote
> target
>
>
>
>> On Nov 8, 2018, at 11:18 AM, Adrian Harris <adrian.har...@mac.com> wrote:
>>
>> 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.
>>
>
> What you need is a DynamicLoader for the OS you are targeting. The
> ProcessGDBRemote queries all the loaded DynamicLoader plugins for the one
> that matches the current process, and installs the one that matches. Then
> that plugin has the job of filling in the section load list. In your case,
> that would just be to copy all the section addresses directly to the section
> load map.
>
>> 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).
>
> That's handled the same way as launch. When you attach, lldb gets host info
> from the other side of the connection (you can also help this out by
> providing an appropriate triple when you create the target before
> attaching). It uses that to figure out which DynamicLoader plugin to use.
> And again, it's the DynamicLoader's job to look at the memory of the target
> process and figure out where the images got mapped. How it does that is
> magic specific to each plugin.
>
> JIm
>
>
>>
>> Adrian
>>
>>
>>
>>> On Nov 8, 2018, at 11:36 AM, Jim Ingham <jing...@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@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.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
>>>
>>
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
