Hi Abhishek,
> On Oct 30, 2015, at 6:56 AM, Abhishek Aggarwal wrote:
>
> When eh_frame has epilogue description as well, the Assembly profiler
> doesn't need to augment it. In this case, is eh_frame augmented unwind
> plan used as Non Call Site Unwind Plan or Assembly based Unwind Plan
> is use
Done in r252998.
I didn't see anything in the xcode project file about a gtest target.
J
> On Nov 12, 2015, at 5:39 PM, Zachary Turner via lldb-dev
> wrote:
>
> Hi all,
>
> I submitted r252993 and 252994. These changes will require a corresponding
> change in the Xcode workspace. Would an
Ah, my bad. It's the lldb-gtest target.
> On Nov 12, 2015, at 5:49 PM, Zachary Turner wrote:
>
> Hmm, can you ask Todd about it? He said he added one, but I'm not sure how
> it works.
>
> On Thu, Nov 12, 2015 at 5:46 PM Jason Molenda wrote:
> Done in r252998.
>
> I didn't see anything in
FWIW, nope, I've never messed with the benchmark tests.
> On Dec 9, 2015, at 1:22 PM, Todd Fiala wrote:
>
> Hey Jason,
>
> Are you the benchmark user?
>
> -Todd
>
> On Wed, Dec 9, 2015 at 12:32 PM, Zachary Turner via lldb-dev
> wrote:
> Is anyone using the benchmark tests? None of the comm
> On Dec 26, 2015, at 3:53 AM, Andre Vergison via lldb-dev
> wrote:
>
> I tried the above because in fact I had a process which a segmentation fault
> 11, here’s what lldb makes out of the core dump:
>
> txt$ lldb /cores/core.33158
> (lldb) target create "/cores/core.33158"
> warning: (x86_
o DevToolSecurity –enable <
>
> tst$ sudo find / -name DevToolSecurity
> find: /dev/fd/3: Not a directory
> find: /dev/fd/4: Not a directory
> find: /Volumes/VMware Shared Folders: Input/output error
> tst$
>
> I have a feeling that my install is not complete. What can
> On Jan 5, 2016, at 10:17 AM, Greg Clayton via lldb-dev
> wrote:
>
>
>> So how about:
>>
>> (lldb) run
>> error: developer mode not enabled
>
> We should be able to do this. The main issue is detecting that the user is in
> a remote scenario where they don't have access to the UI. A dialog
If you can pause the remote process while debugging, I would start by seeing if
lldb knows about any images being loaded:
(lldb) image list
I'd also try 'target list', 'platform status', and maybe 'log enable lldb dyld'
from the start.
If lldb can't figure out where the binaries are loaded in
> On May 31, 2016, at 11:31 AM, jing...@apple.com wrote:
>
>
>> On May 31, 2016, at 12:52 AM, Ravitheja Addepally via lldb-dev
>> wrote:
>>
>> Hello,
>> I posted this query a while ago, i still have no answers, I am
>> currently working on Bug 27687 (PrintStackTraces), so the reason for
It gets so tricky! It's hard for the unwinder to tell the difference between a
real valid stack unwind and random data giving lots of "frames".
It sounds like the problem that needs fixing is to figure out why the assembly
unwind is wrong for frame 0. What do you get for
disass -a
image sh
This has no eh_frame unwind instructions. Even if we were using eh_frame at
frame 0, you'd be out of luck.
I forget the exact order of fallbacks. I think for frame 0 we try to use the
assembly profile unwind ("async unwind plan") and if we can't do that we fall
back to the eh_frame unwind ("s
Hi, the KDK from Apple includes a README file (.txt or .html, I forget) which
describes how to set up kernel debugging. I'd start by looking at those notes.
There have also been WWDC sessions that talk about kernel debugging, e.g.
https://developer.apple.com/videos/play/wwdc2013/707/
(there a
Is your kext loaded in lldb when you're connected to the kernel? If you do
'image list' do you see your kext there? Does it show the dSYM, which has all
of the debug information, also loaded for your kext? If your kext with its
dSYM is on the local filesystem, you can add a line to your ~/.ll
Ah, I don't know how to do kernel debugging with macOS running under a VM. I
think this sounds more like a question for the apple devforums, I think it's
more of a "how do I do kext debugging with a VM", not so much an lldb question.
> On Jul 28, 2016, at 7:38 PM, hrishikesh chaudhari
> wrote
Hi Tamas & Pavel, I thought you might have some ideas so I wanted to show a
problem I'm looking at right now. The arm64 instruction unwinder forwards the
unwind state based on branch instructions within the function. So if one block
of code ends in an epilogue, the next instruction (which is p
Yeah I was thinking that maybe if we spot an epilogue instruction (ret, b
), and the next instruction doesn't have a reinstated
register context, we could backtrack to the initial register context of this
block of instructions (and if it's not the beginning of the function),
re-instate that reg
I like that idea. A bunch of other work just landed on my desk so it might be
a bit before I do it, but I'll see how that patch looks.
> On Nov 9, 2016, at 3:54 AM, Tamas Berghammer wrote:
>
> Based on your comments I have one more idea for a good heuristic. What if we
> detect a dynamic bran
Looks incorrect to me. It was introduced with this change. Adding Greg.
Author: Greg Clayton
Date: Fri Aug 27 21:47:54 2010 +
Made it so we update the current frames from the previous frames by doing
STL
swaps on the variable list, value object list, and disassembly. This avoid
For reference, the original code that Greg wrote in r112301 was
+if (!m_disassembly.GetString().empty())
+m_disassembly.GetString().swap (m_disassembly.GetString());
> On Nov 14, 2016, at 1:44 PM, Zachary Turner wrote:
>
> If the swap is correct, then wouldn't we also need to swa
Hi Pavel, sorry for not keeping up with the thread, I've been super busy all
this week. I'm not going to object to where this proposal has ended up. I
personally have a preference for the old system but not based on any
justifiable reasons.
> On Dec 15, 2016, at 7:13 AM, Pavel Labath wrote:
It's used in the swift lldb, https://github.com/apple/swift-lldb
The idea is to have any non-swift specific code in llvm.org; the github
repository for swift specific additions.
> On Mar 21, 2017, at 6:19 PM, Zachary Turner via lldb-dev
> wrote:
>
> AFAICT this is all dead code. Unless some
I don't follow REPL issues very closely but I think some people may have hopes
of doing a repl in a language other than swift in the future which is why it
was upstreamed to llvm.
J
> On Mar 21, 2017, at 6:34 PM, Zachary Turner wrote:
>
> Thanks, I had a suspicion it might be used in Swift.
I don't know exactly when the 3.9 / 4.0 branches were cut, and what was done
between those two points, but in general we don't expect/want to see
performance regressions like that. I'm more familiar with the perf
characteristics on macos, Linux is different in some important regards, so I
can
lldb doesn't know what register set exists - if you do 'register read' you'll
see that there are no registers. Maybe gdbserver doesn't implement the
target.xml request (it's their packet definition! c'mon!)
Download the x86_64 target def file from
http://llvm.org/svn/llvm-project/lldb/trunk
Was liblldb.so build with debug information? You're probably looking at lldb
scanning the DWARF to make up its symbol table. That would be re-used on
subsequent reruns so you're only seeing the cost that first time through. gdb
may be using the standard dwarf accelerator tables, or it may be
fwiw I had to prototype a new LC_NOTE load command a year ago in Mach-O core
files, to specify where the kernel binary was located. I wrote a utility to
add the data to an existing corefile - both load command and payload - and it
was only about five hundred lines of C++. I didn't link against
We maintain a few different branches of the lldb sources, e.g. to add swift
support, and the xcode project files have diverged over time from llvm.org to
our github repositories making git merging a real pain. The two biggest
sources of pain are the BuildFiles and FileReferences sections of the
> On Jun 26, 2018, at 2:00 PM, Jim Ingham via lldb-dev
> wrote:
>
>
>> * unwinding and backtrace generation
>
> Jason says this will be somewhat tricky to pull out of lldb. OTOH much of
> the complexity of unwind is reconstructing all the non-volatile registers,
> and if you don't care ab
Yeah, I wrote the script to accept stdin or a filename argument, and print its
results. I'll fix it to hardcode looking for lldb.xcodeproj/project.pbxproj or
project.pbxproj in cwd and update it in place.
> On Jul 23, 2018, at 3:37 PM, Raphael “Teemperor” Isemann
> wrote:
>
> That’s just ho
I'd argue against this approach because it's exactly why the lit tests don't
run against the lldb driver -- they're hardcoding the output of the lldb driver
command into the testsuite and these will eventually make it much more
difficult to change and improve the driver as we've accumulated this
It's more verbose, and it does mean test writers need to learn the public API,
but it's also much more stable and debuggable in the future. It's a higher up
front cost but we're paid back in being able to develop lldb more quickly in
the future, where our published API behaviors are being teste
s way, and the output is so simple that you never
> have to worry about it changing.
>
> That said, I think history has shown that limiting ourselves to sb api tests,
> despite all the theoretical benefits, leads to insufficient test coverage. So
> while it has benefits, it also has p
> On Aug 15, 2018, at 11:34 AM, Vedant Kumar wrote:
>
>
>
>> On Aug 14, 2018, at 6:19 PM, Jason Molenda wrote:
>>
>> It's more verbose, and it does mean test writers need to learn the public
>> API, but it's also much more stable and debuggable in the future.
>
> I'm not sure about this.
I think the confusing thing is when "unspecified" means "there is no OS" or
"there is no vendor" versus "vendor/OS is unspecified".
Imagine debugging a firmware environment where we have a cpu arch, and we may
have a vendor, but we specifically do not have an OS. Say armv7-apple-none (I
make u
hary Turner wrote:
>
> Is there some reason we can’t define vendors, environments, arches, and oses
> for all supported use cases? That way “there is no os” would not ever be a
> thing.
> On Thu, Dec 6, 2018 at 3:37 PM Jason Molenda via lldb-dev
> wrote:
> I think the conf
r wrote:
> >
> > Is there some reason we can’t define vendors, environments, arches, and
> > oses for all supported use cases? That way “there is no os” would not ever
> > be a thing.
> > On Thu, Dec 6, 2018 at 3:37 PM Jason Molenda via lldb-dev
> > w
Hi Pavel,
I'm open to this. I don't think there was any specific reason why UnwindTable
is in the ObjectFile over the Module - it was very likely not an intentional
choice when I put it there.
To recap, each "binary" in the system has an UnwindTable. The UnwindTable has a
list of functions it
Hi Tom, interesting problem you're working on there.
I'm not sure any of the DWARF expression operators would work here. You want
to have an expression that works for a given frame, saying "to find the
caller's pc value, look at the saved-pc stack, third entry from the bottom of
that stack."
Yeah, if you don't need to find a way to express this in DWARF, then adding a
type to RestoreType would be very simple. lldb maps all the different unwind
sources (debug_frame, eh_frame, arm index, compact unwind, assembly instruction
scanning) into its internal intermediate representation (Unw
Hm, that's interesting.
I tried running a debug lldb on /bin/ls. then I attached from another lldb. I
put a breakpoint on CommandObjectTargetModulesLookup::DoExecute and resumed
execution. In the debuggee lldb, I did
tar mod loo -a 0
and auto-repeated return so the same command would be ex
> On Jul 12, 2019, at 2:04 PM, Greg Clayton wrote:
>
>
>
>> On Jun 21, 2019, at 1:24 PM, Joseph Tremoulet via lldb-dev
>> wrote:
>>
>
>> 2 - When the user handler is invoked, its return address is set to the very
>> first byte of __kernel_rt_sigreturn, which throws off unwinding because
> On Aug 22, 2019, at 3:58 PM, Ismail Bennani via lldb-dev
> wrote:
>
> Hi Greg,
>
> Thanks for your suggestion!
>
>> On Aug 22, 2019, at 3:35 PM, Greg Clayton wrote:
>>
>> Another possibility is to have the IDE insert NOP opcodes for you when you
>> write a breakpoint with a condition an
Yeah, this is a bug in lldb's implementation of vFile:open. lldb talks to
lldb-server (in platform mode) so it will work with itself, but it will not
interoperate with any other implementations. That's the down side to having
the client and server literally built from the same sources. :)
I
I suspect your problem may be related to lldb not knowing how to walk the stack
on this target. Is mips-unknown-linux-gnu correct? What do you see if you
turn on unwind logging, 'log enable lldb unwind'. You can also have lldb show
you the unwind rules at the current pc value with 'image sho
Hi Alexander, sorry for the delay in replying.
The attached unwind log shows that lldb is using the architectural default
unwind plan for this target. You can see where this unwind plan in constructed
at
ABISysV_mips::CreateDefaultUnwindPlan
it says to find the caller's pc value at *($r29),
Hi Rui, you need to call SBDebugger::Terminate() before your program exits.
On 03/08/20 01:54 PM, Rui Liu via lldb-dev wrote:
>
>
> Hi LLDB devs,
>
> I'm trying to build a debugger integration that uses LLDB C++ API. Due to
> lack of documentation, I'm basically using the examples in the p
Hi David, thanks for the great writeup. I hadn't been following the gdb MTE
support.
This all looks reasonable to me. A few quick thoughts --
The initial idea of commands like "memory showptrtag", "memory showtag",
"memory checktag" - it might be better to put all of these under "memory tag
hentication
> patches. We may collaborate and upstream unwinder support.
>
> Thanks!
>
> On Tue, 11 Aug 2020 at 04:13, Jason Molenda via lldb-dev
> wrote:
> Hi David, thanks for the great writeup. I hadn't been following the gdb MTE
> support.
>
> This
estigating
>> unwinder support which means any further implementation from my side will be
>> an overlap with what you guys have done already. There can also be design
>> conflicts and I would really appreciate it if we can come on some common
>> ground regarding upstream
Good bug find!
It seems to me that DWARFCallFrameInfo should push the initial CIE register
setup instructions as being the state at offset 0 in the function (in fact I'd
say it's a bug if it's not). If that were done, then getting RowAtIndex(0)
should be synonymous with get-the-CIE-register-unw
> On Oct 8, 2020, at 9:17 PM, Greg Clayton wrote:
>
>
>
>> On Oct 8, 2020, at 8:55 PM, Jason Molenda wrote:
>>
>> Good bug find!
>>
>> It seems to me that DWARFCallFrameInfo should push the initial CIE register
>> setup instructions as being the state at offset 0 in the function (in fact
> On Oct 8, 2020, at 9:17 PM, Greg Clayton wrote:
>
>
>
>> On Oct 8, 2020, at 8:55 PM, Jason Molenda wrote:
>>
>> Good bug find!
>>
>> It seems to me that DWARFCallFrameInfo should push the initial CIE register
>> setup instructions as being the state at offset 0 in the function (in fact
> On Oct 8, 2020, at 10:06 PM, Jason Molenda wrote:
>
>
>
>> On Oct 8, 2020, at 9:17 PM, Greg Clayton wrote:
>>
>>
>>
>>> On Oct 8, 2020, at 8:55 PM, Jason Molenda wrote:
>>>
>>> Good bug find!
>>>
>>> It seems to me that DWARFCallFrameInfo should push the initial CIE register
>>> set
> On Oct 8, 2020, at 10:37 PM, Greg Clayton wrote:
>
>
>
>> On Oct 8, 2020, at 10:29 PM, Jason Molenda wrote:
>>
>>
>>
>>> On Oct 8, 2020, at 10:06 PM, Jason Molenda wrote:
>>>
>>>
>>>
On Oct 8, 2020, at 9:17 PM, Greg Clayton wrote:
> On Oct 8, 2020, at 8:5
Hi Greg, Pavel.
I think it's worth saying that this is very early in this project. We know
we're going to need the ability to track segments on addresses, but honestly a
lot of the finer details aren't clear yet. It's such a fundamental change that
we wanted to start a discussion, even though
Hi, I'm working with an Apple team that has a gdb RSP server for JTAG
debugging, and we're working to add the ability for it to tell lldb about the
UUID and possibly address of a no-dynamic-linker standalone binary, or firmware
binary. Discovery of these today is ad-hoc and each different proce
erver a bit more generic and releasing it open source for use with OpenOCD?
> They've got a stub for gdb, but it needs some work to behave better with lldb.
>
> Ted
>
>> -Original Message-----
>> From: lldb-dev On Behalf Of Jason
>> Molenda via lldb-dev
>&
> On Mar 23, 2021, at 1:36 PM, Greg Clayton wrote:
>
>
>
>> On Mar 22, 2021, at 11:01 PM, Jason Molenda wrote:
>>
>> Hi, I'm working with an Apple team that has a gdb RSP server for JTAG
>> debugging, and we're working to add the ability for it to tell lldb about
>> the UUID and possibly
> On Apr 20, 2021, at 11:39 PM, Pavel Labath via lldb-dev
> wrote:
>
> I am very happy to see this effort and I fully encourage it.
Completely agree. Thanks for Cc:'ing me Pavel, I hadn't seen Michał's thread.
>
> On 20/04/2021 09:13, Michał Górny via lldb-dev wrote:
>> On Mon, 2021-04-1
I was looking at lldb-platform and I noticed I implemented the A packet in it,
and I was worried I might have the same radix error as lldb in there, but this
code I wrote made me laugh:
const char *p = pkt.c_str() + 1; // skip the 'A'
std::vector packet_contents = get_fields_from_delim
> On Apr 27, 2021, at 4:56 AM, Pavel Labath wrote:
>
> I think that's fine, though possible changing the servers to just ignore the
> length fields, like you did above, might be even better, as then they will
> work fine regardless of which client they are talking to. They still should
> adv
Hi Tony. There are new security mechanisms in Mac OS X 10.11 El Capitan,
called System Integrity Protection, but I don't recognize this failure mode.
Try a stripped down example, like
$ echo 'int main () { }' > /tmp/a.c
$ xcrun clang /tmp/a.c -o /tmp/a.out
$ xcrun lldb /tmp/a.out
(lldb) br s -
The fact that it doesn't work as root makes it less likely it's an unsigned
debugserver / missigned debugserver issue. You can run an unsigned /
mis-signed lldb as root and it will still work on os x 10.11, as well as a
signed one run by a user account.
Is the binary you're running under the d
(resending my reply with a Cc to lldb-dev - System Integrity Protection in Mac
OS X 10.11 El Capitan has impact on lldb in several important ways, I think
others will be interested.)
Yes, System Integrity Protection in El Capitan includes the restriction that
nothing can be modified in directo
Hi all, sorry I missed this discussion last week, I was a little busy.
Greg's original statement isn't correct -- about a year ago Tong Shen changed
lldb to using eh_frame for the currently-executing frame. While it is true
that eh_frame is not guaranteed to describe the prologue/epilogue, in p
> On Oct 19, 2015, at 2:54 PM, Jason Molenda via lldb-dev
> wrote:
> Greg's original statement isn't correct -- about a year ago Tong Shen changed
> lldb to using eh_frame for the currently-executing frame. While it is true
> that eh_frame is not guaranteed to descr
If it's on Mac OS X 10.11, I saw this the other day. e.g.
sh-3.2$ cat a.c
#include
#include
int main()
{
printf("%s\n", getenv("DYLD_LIBRARY_PATH"));
}
sh-3.2$ clang a.c
sh-3.2$ lldb -x a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) pro lau -v DYLD_L
67 matches
Mail list logo
