ter, 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-d
ember 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
> 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
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
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 ru
(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
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
