[lldb-dev] building only lldb with debug symbols
Hi Everyone, I'm writing a gdb-server for a new architecture and need to be able to debug lldb to track down issues. Unfortunately disk space is tight here and the llvm debug build consumes north of 40Gb with debug symbols. Is there any way to build *only* lldb with debug symbols (and no optimization)? Thanks! Adrian ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[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
... connection happens
(lldb) image add tile.elf
(lldb) target modules list
[ 0] 89569B3D----tile.elf
(lldb) break main
lldb Target::AddBreakpoint (internal = no) => break_id = 1: name =
'main'
lldb warning: Tried to add breakpoint site at 0x
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 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
Re: [lldb-dev] problem resolving symbolic breakpoint on a remote target
(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
>
> ?
>
> --
> 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 On Behalf Of Adrian Harris
> via lldb-dev
> Sent: Thursday, November 8, 2018 11:09 AM
> To: via lldb-dev
> 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
> ... connection happens
> (lldb) image add tile.elf
> (lldb) target modules list
> [ 0] 89569B3D----tile.elf
> (lldb) break main
> lldb Target::AddBreakpoint (internal = no) => break_id = 1: name
> = 'main'
>
>
> lldb warning: Tried to add breakpoint site at 0x
> 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 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
Re: [lldb-dev] problem resolving symbolic breakpoint on a remote target
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 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 >> 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 >>> >>> ? >>> >>> -- >>> 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 On Behalf Of Adrian Harris >>> via lldb-dev >>> Sent: Thursday, November 8, 2018 11:09 AM >>> To: via lldb-dev >>> 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 >>> ... connection happens >>> (lldb) image add tile.elf >>> (lldb) target modules list >>> [ 0] 89569B3D----tile.elf >>> (lldb) break main >>> lldb Target::AddBreakpoint (internal = no) => break_id = 1: >>> name = 'main' >>> >>> >>> lldb warning: Tried to add breakpoint site at >>> 0x but it was already present. >>> >>> lldb
Re: [lldb-dev] problem resolving symbolic breakpoint on a remote target
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 > Sent: Thursday, November 8, 2018 1:39 PM > To: Adrian Harris > Cc: ted.woodw...@codeaurora.org; LLDB > Subject: Re: [lldb-dev] problem resolving symbolic breakpoint on a remote > target > > > >> On Nov 8, 2018, at 11:18 AM, Adrian Harris 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 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 > 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_
[lldb-dev] New target; where to start with thread plans
Hi Everyone, I’ve added basic support for a new target (via gdb-remote) and now it is time to add ABI support to lldb to improve the debug experience. My understanding is that I need to add an ABI plugin (we have a very basic stub now) and thread-plan support. As a first step I’d like to be able to support the ‘thread step-out’ command. Some basic guidance would be very much appreciated. Thanks! Adrian ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
