The other idea would be to allow the Platform subclasses to be able to fill in
some fixed variable names when asked.
So if the user typed either:
(lldb) frame variable $platform.siginfo
(lldb) expression $platform.siginfo
We would have the name lookup mechanism check with the current platform i
We just need to specify that the addresses for these emulated instruction
address ranges have symbols and the type of these symbols are set to
"eSymbolTypeTrampoline". We run into a similar case when you are stepping
through the PLT entries for external functions. If your main binary has a
"pri
I am fine with a new plug-in to handle this, but I want to verify a few things
first:
Can this core dump file format basically allow debugging of multiple targets?
For example could you for example want to examine the kernel itself as is, but
also provide a view into any of the user space proce
I have had to add the following to my cmake command line:
-DPython3_EXECUTABLE=/usr/bin/python3
> On Dec 5, 2021, at 12:02 PM, Pi Pony via lldb-dev
> wrote:
>
> Hello,
>
> I build lldb for macOS and tried to get into script but I get this error
> message: there is no embedded script in
> On Oct 28, 2021, at 6:33 AM, Pavel Labath via lldb-dev
> wrote:
>
> Hello everyone,
>
> I'd like to propose a new plugin for better lldb+qemu integration.
>
> As you're probably aware qemu has an integrated gdb stub. Lldb is able
> to communicate with it, but currently this process is some
You can set breakpoints at addresses prior to running a process. ASLR will
shift shared libraries around each time you run, so it really isn't safe to set
these. If you do disable ASLR, and are able to debug, just reverse your
statement and do the "process launch" first:
process launch --stop-a
> On Oct 22, 2021, at 6:12 AM, Pavel Labath via lldb-dev
> wrote:
>
> Hello Jim, everyone,
>
> I recently got a question/bug report about python pretty printers (synthetic
> child providers) that I couldn't answer.
>
> The actual script is of course more complicated, but the essence boils d
Someone will need to implement the core file saving in the ObjectFileELF.cpp if
you want to do this. It currently isn't implemented.
Greg
> On Aug 7, 2015, at 1:49 PM, Eugene Birukov via lldb-dev
> wrote:
>
> Hi,
>
> Is there a way to create process dump on Linux using LLDB? I am using Ubun
Anyone know what is up? It runs all tests in 30 seconds and says they all
passed, but nothing is actually being run...
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
up and caching of dSYMs before running the test suite!
Exiting...
The detest.py needs to return an error for this case and it needs to be caught
by dosep.py...
> On Aug 11, 2015, at 2:03 PM, Greg Clayton via lldb-dev
> wrote:
>
> Anyone know what is up? It runs all tests in 30 secon
Yep, removing it seems like a good solution. And please do feel free to add any
newlines and any files that are missing them without need for reviews.
> On Aug 11, 2015, at 9:21 PM, Bruce Mitchener via lldb-dev
> wrote:
>
> Hello!
>
> This is probably for the Apple People since it relates to
All registers are placed into one large buffer that contains everything. All
offsets should be the global offset in the register context's data. Typically
we should see:
GPR
rax offset 0
rbx offset 8
FPR
mm0 offset 128
mm1 offset 160
...
EXC
fpsr offset 256
...
So
There are also a few competing log implementations. There are ones like in
"source/Core/Logging.cpp" which are hard coded, and then there is a plugin
version as you can see in LogChannelDWARF.cpp. The latter is the newer way to
implement custom log channels without hand coding a copy of
"source
> On Aug 13, 2015, at 6:43 PM, Bruce Mitchener via lldb-dev
> wrote:
>
> Hello,
>
> On Mac OS X, when using the xcode projects, there is some machinery to manage
> what symbols are exported from various things:
>
> • liblldb only exports the public API.
It currently exports:
_ZN4lldb
> On Aug 14, 2015, at 12:25 AM, Abhishek Aggarwal
> wrote:
>
> Hi
>
> As per my understanding (please correct if I am wrong):
>
> 1. There exists a file for each platform (Architecture+OS) that calculates
> the offsets for that platform. e.g. RegisterContextLinux_x86_64.cpp for
> x86_64 arc
> On Aug 14, 2015, at 11:04 AM, Bruce Mitchener
> wrote:
>
> I was doing some more digging into this and experimentation and found that
> the Windows build appears to handle this already, but that's because symbol
> visibility is different over there.
>
> It looks like on non-Windows, we sho
> On Aug 17, 2015, at 8:06 AM, Abhishek Aggarwal wrote:
>
> Hi Greg
>
> Thanks for your reply. My next queries are based on the Bug 24457 that I
> filed 2-3 days ago.
>
> I analyzed and found the reason of this bug for x86_64-Linux platform.
>
> A solution to fix this bug requires change in
One option is to send a ? packet to get a stop reply packet back. The stop
reply should contain a "thread:;" key/value pair and you could just make
the pid == tid == . We currently try these in the order below:
1 - qProcessInfo
2 - qC
3 - qfThreadInfo
Now we could add a fourth:
4 - ?
I guess we can just make pid == 1 and tid == 1 in this case. As long as a stop
reply is responding we should be able to debug.
> On Aug 23, 2015, at 11:51 PM, Jaydeep Patil wrote:
>
> Hi Greg,
>
> The '?' packet always returns 'S05'. There is no thread information available
> in any of the pa
The type name for "Ty" might have a newline in it. Try this:
res = frame.EvaluateExpression("%s->dump()" % command)
print >>result, 'typename = "%s"' % (res.GetType().GetName())
print >>result, res
See if the double quote is on the next line.
> On Aug 22, 2015, at 11:58 AM, Ramkumar Ra
That doesn't seem to be right, you had a typename before:
(lldb) pp Ty
Fn(Void -> Int)*
=
Make sure everything is setup and is where you were stopped before and that you
use the same "Ty" variable you did before. I have seen function types have
newlines in them in the past.
> On Aug 24, 2015,
We should have a decorator like:
@skipLinuxUnlessInstalled("/usr/lib/libc++.so")
or something that tells us to install this library and fails the test suite
before you run anything.
> On Aug 24, 2015, at 4:01 PM, Chaoren Lin via lldb-dev
> wrote:
>
> The TestDataFormatterLibcc* tests require
It is just defined to be where all of the prologue instructions are done
setting up the stack frame for the current function. There is no right answer
in terms of source lines, the compiler can say anything it wants to.
Greg
> On Aug 31, 2015, at 4:22 AM, Aidan Dodds via lldb-dev
> wrote:
>
A std::weak_ptr is necessary because Target contains a shared pointer to the
process and if you have the process have a shared pointer to the target then
neither will ever destruct.
I have no problem doing this. The main question is who actually has this strong
reference to the process? This s
> On Aug 31, 2015, at 1:34 PM, Zachary Turner wrote:
>
> Windows plugin holds a strong reference to itself. It calls
> shared_from_this() when the process is launched, and it releases this strong
> reference after a process exits. It does this because the debug loop happens
> in a different
So a few things:
1 - on MacOSX we can reliably launch a process via posix_spawn() with a flag
set that sets the process to stop at __dyld_start which is the first
instruction in the program. So our launch then attach always works reliably
because when we launch the process set set this posix_sp
process we are
attaching to?
> On Aug 31, 2015, at 3:16 PM, Greg Clayton via lldb-dev
> wrote:
>
> So a few things:
>
> 1 - on MacOSX we can reliably launch a process via posix_spawn() with a flag
> set that sets the process to stop at __dyld_start which is the first
> On Aug 31, 2015, at 4:28 PM, Zachary Turner wrote:
>
> Sounds good. I already have that working in a local patch, but I will wait
> for the fix you described earlier to go in first, and handle the merge and
> check in the weak_ptr change.
>
This was in yesterday:
Author: gclayton
Date: M
One idea is add the ability to discover which of any of the current threads are
or are not user created. This might help us.
On MacOSX, the main thread would always be considered user created, and any
other thread, it is quite easy to tell. User created threads could be ones
whose bottom stack
> On Sep 2, 2015, at 3:15 PM, Ryan Brown via lldb-dev
> wrote:
>
> I'm trying to implement a DWARFASTParser for go, and have hit an issue with
> fields for structs.
> As I understand it, DWARFASTParserClang loads minimal type info for structs
> at first, and registers the type in SymbolFileDW
langASTContext *)baton;
SymbolFile *sym_file = ast->GetSymbolFile();
if (sym_file)
{
CompilerType clang_type = GetTypeForDecl (decl);
if (clang_type)
sym_file->CompleteType (clang_type);
}
}
> On Sep 2, 2015, at 3:48 PM, Greg Clayton via lldb-dev
>
);
>if (sym_file)
>{
>CompilerType clang_type = GetTypeForDecl (decl);
>if (clang_type)
>sym_file->CompleteType (clang_type);
>}
> }
>
>
>> On Sep 2, 2015, at 3:48 PM, Greg Clayton via lldb-dev
>> wrote:
>>
Yes, Scalar used to support the smaller sizes correctly. Revision 245547
changed Scalar over to use llvm::APInt and llvm::APFloat and it might have
messed up char/short support. Please do fix Scalar so it can support it. I
believe llvm::APInt should be able to correctly support this. I will watc
If llvm-dsymutil is dropping the name, then send me your example and I will
file a bug on them to get this fixed.
Greg Clayton
> On Sep 8, 2015, at 10:06 AM, Jim Ingham via lldb-dev
> wrote:
>
> Ah, okay. For a while the llvm-dsymutil folks were trying to make the output
> of dsymutil & llv
> On Sep 13, 2015, at 4:26 PM, carr27 via lldb-dev
> wrote:
>
> Hello,
>
> I'm working on an LLVM pass that I'm trying to debug it with LLDB, but I'm
> running into a few problems. I'm generally following this turtorial [1] but
> I run my pass with opt instead from inside clang. So I run:
>
A few questions:
Which process plug-in does your debugging target use?
Is it a GDB Remote based debug session?
If so is it using lldb-server?
a custom GDB server?
In general, we expect to receive a eStateStopped process event if the attach is
successful and this is what we are waiting f
Here is the output of attaching to a process with ProcessGDBRemote:
(lldb) log enable lldb state
(lldb) attach 12406
Process::SetPublicState (state = attaching, restarted = 0)
Process::SetPrivateState (stopped)
Process::SetPrivateState (stopped) stop_id = 1
Process::SetPublicState (state = stopped
> On Sep 17, 2015, at 3:08 AM, Bruce Mitchener
> wrote:
>
> Howdy!
>
> I was looking at some of the CompilerType changes and had some questions
> related to the recent cleanups and renamings.
>
> • clang_type_t is a typedef for void* and is used for the opaque qual
> type code among o
This sounds like you don't have a private state thread running. The private
state thread watches for private state changes in Process and promotes them
into public state changes as needed. Can you check if
Process::PrivateStateThread() is running? This should be triggered by a call to
StartPriv
> On Sep 17, 2015, at 10:14 AM, Ryan Brown wrote:
>
>
>
> On Thu, Sep 17, 2015 at 10:06 AM Greg Clayton via lldb-dev
> wrote:
>
> > On Sep 17, 2015, at 3:08 AM, Bruce Mitchener
> > wrote:
> >
> > Howdy!
> >
> > I was looking a
Yep, that'll do it!
Are you up and running now?
> On Sep 17, 2015, at 11:05 AM, Philippe Lavoie
> wrote:
>
>
> Ah! The issue was in my custom Platform's Attach. It is based on PlatformGDB,
> but it seems I bulldozed through a little too fast.
>
> I was missing a call to Process::HijackProce
We currently coalesce breakpoints to avoid the user stopping multiple times on
the same source line. This might have been done to avoid stepping issues we
might have had in the past, but we have made many modifications to stepping
such that the step thread plans now know how to step through two
> On Sep 23, 2015, at 6:39 PM, d...@burble.org wrote:
>
> On Wed, Sep 23, 2015 at 11:44:41AM -0700, Greg Clayton wrote:
>> We currently coalesce breakpoints to avoid the user stopping multiple times
>> on the same source line. This might have been done to avoid stepping issues
>> we might have
I am fine with case "a".
Greg
> On Sep 28, 2015, at 2:48 AM, Pavel Labath wrote:
>
> Hello all,
>
> The following question came up while fixing up handling of process detach.
>
> when detaching from a running process, on some platforms LLDB needs to
> stop it first. Is this stop something tha
You are missing a call to the initialize function:
lldb::SBDebugger::Initialize();
> On Sep 28, 2015, at 1:12 AM, Stefan Kratochwil via lldb-dev
> wrote:
>
> Hi,
>
> I've got a problem with lldb deadlocking upon a call to
> lldb::SBDebugger::Terminate().
>
> I am currently using svn revisi
It would be ok to relax the test for eTypeExecutable to also allow
eTypeSharedLibrary if, on many systems, it is possible to run a binary of type
shared library as an executable. If it changes from system to system, then we
could ask the platform (PlatformLinux if your case?) to verify if a bina
That is just fine, you will need to submit patches prior to checking stuff in
so the other FreeBSD and Linux folks can try things out to make sure things
don't break on other platforms. If things diverge a lot, we might have a base
pthread debugging class that can be subclassed so that FreeBSD c
> On Oct 7, 2015, at 10:05 AM, Zachary Turner via lldb-dev
> wrote:
>
> Jim, Greg,
>
> Can I get some feedback on this? I would like to start enforcing this moving
> forward. I want to make sure we're in agreement.
>
> On Mon, Oct 5, 2015 at 12:30 PM Todd Fiala wrote:
> IMHO that all sou
Most calls for lldb-server should use an instance variable
GDBRemoteCommunication::m_packet_timeout which you could then modify. But this
timeout you are talking about is the time that the expression can take when
running. I would just bump these up temporarily while you are debugging to
avoid
>
> So in summary, it sounds like we agree on the following guidelines:
>
> 1) If you're committing a CL and it is possible to test it through the SB
> API, you should only submit an SB API test, and not a HandleCommand test.
agreed
> 2) If you're committing a CL and it's not possible to test
We set this manually in the Xcode project for "Debug" and "DebugClang" build
variants. The cmake should be able to do the same, but I am not sure if it is.
Feel free to make it do so. I am not very good with cmake, so I won't be much
help.
Greg
> On Oct 7, 2015, at 11:09 AM, Eugene Birukov wr
> On Oct 7, 2015, at 8:31 PM, Jeffrey Tan via lldb-dev
> wrote:
>
> Hi,
>
> I am writing a python script to set source line breakpoint in ObjC on Mac
> OSX. But
> self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m",
> line) always fail. Any ideas?
As long as yo
> On Oct 13, 2015, at 2:42 AM, Stefan Kratochwil via lldb-dev
> wrote:
>
> Hi altogether,
>
> I currently am developing an application where I need to access the DWARF
> debugging information of my target process and its loaded .so files.
>
> In more detail, I need to match type information
In LLDB we create clang::ASTContext objects for the modules (executable and
shared libraries), one for the target to contain the expression results, and
one for each expression.
When we evaluate an expression we might do something like:
(lldb) expr a + b
where "a" is from liba.so and "b" is fr
EH frame can't be used to unwind when we are in the first frame because it is
only valid at call sites. It also can't be used in frames that are
asynchronously interrupted like signal handler frames. So at frame zero, we
typically just fall back to the default unwind plan for the current
archit
I am guessing that your binary is missing a LC_VERSION_MIN_XXX load command and
so it is being loaded with "-unknown-unknown" as the architecture. This
is probably causing LLDB to load the DynamicLoaderStatic as the dynamic loader
which just loads all shared libraries as the address that is cont
> On Oct 14, 2015, at 1:02 PM, Joerg Sonnenberger via lldb-dev
> wrote:
>
> On Wed, Oct 14, 2015 at 11:42:06AM -0700, Greg Clayton via lldb-dev wrote:
>> EH frame can't be used to unwind when we are in the first frame because
>> it is only valid at call sites. It
Glad we identified your problem. Can you guys always use the system linker? Any
reason to use another linker? If you continue to a custom linker you will want
to modify it to set these. If you compile Go programs that run on iOS simulator
or iOS you will want to emit a LC_MIN_VERSION_IOS.
Greg
> On Oct 14, 2015, at 4:04 PM, Ryan Brown wrote:
>
> Well the go linker is actually what generates code from the IR, so it's
> always required. And as it stands now you can cross compile from another
> platform as long as you don't link with c code. I don't know if they'd want
> to change tha
> On Oct 15, 2015, at 8:50 AM, Adrian McCarthy via lldb-dev
> wrote:
>
> I've tracked down a source of flakiness in tests on Windows to Python object
> lifetimes and the SB interface, and I'm wondering how best to handle it.
>
> Consider this portion of a test from TestTargetAPI:
>
> def fi
> On Oct 16, 2015, at 3:01 PM, Ramkumar Ramachandra wrote:
>
> Alright, let's try to fix the bug.
>
> Let's work backward from the leaves: clang's ASTImporter.cpp:2979 and
> AstImporter.cpp:3044. In the backtrace, what seems to be most relevant
> is a call inside layoutRecordType, namely ClangA
What is this not happening on any other architecture? Is the "$" special for
MIPS and not for other architectures? We really don't want to remove the '$' as
we want the symbol to be unique. The '$' symbol is fine for all x86/x86_64/arm
and arm64 variants...
Greg
> On Oct 19, 2015, at 11:30 PM
eed to make sure that any functions we generate and JIT up and
insert into the program do not conflict with _any_ symbol that could be in any
system libraries or user binaries. This is why we used '$' in the first place.
Greg
> On Oct 20, 2015, at 11:11 AM, Greg Clayton via lldb-d
> On Oct 20, 2015, at 9:57 AM, Ramkumar Ramachandra wrote:
>
> Greg Clayton wrote:
>> Yes I have seen a bunch of problems like this on linux due to types being
>> incomplete in the debug info (my guess). But I would like to verify that the
>> manual DWARF indexing isn't to blame for this. We h
>>
>> Are you pulling in data from two different copies of LLVM in your project?
>> Or is something in here symlink to the other somewhere?
>
> Excellent find. Yes, 3p_mirror is a symlink to the 3p-tmw-osx location.
>
>> So to sum up: LLDB uniques types by decl file + decl line + byte size +
>
>>
>> The other bad thing is even after you normalize the paths you are comparing:
>>
>> /mathworks/devel/sbs/34/rramacha.idivide-final-lap/3p_mirror/maci64/LLVM/include/llvm/ADT/ilist.h
>> /mathworks/devel/sandbox/rramacha/3p-tmw-osx/3p/derived/maci64/LLVM/llvm/include/llvm/ADT/ilist.h
>>
>> A
> On Oct 21, 2015, at 8:45 AM, Ramkumar Ramachandra wrote:
>
> So first, an addendum: I found a way to make the project build without
> using a symlink, and use a direct reference instead. The problem still
> persists. It may be that symlink is one of the problems, but it is
> certainly not the
I think it was mostly done to provide an exception safe way to cleanup stuff
without having to override TestBase.tearDown(). I am guessing this cleanup
happens on TestCase.tearDown() and not after the current test case right?
I could see it being used to cleanup after a single test case in case
IMHO the best way to provide this information is to implement reverse debugging
packets in a GDB server (lldb-server). If you enable this feature via some
packet to lldb-server, and that enables the gathering of data that keeps the
last N instructions run by all threads in some buffer that gets
one main benefit to doing this externally is allow this to be done remotely
over any debugger connection. If you can run expressions to
enable/disable/setup the memory buffer/access the buffer contents, then you
don't need to add code into the debugger to actually do this.
Greg
> On Oct 21, 20
I believe it would import lldb correctly. I don't tend to run the tests
individually, but if it did work, I would use it more.
> On Oct 22, 2015, at 9:26 AM, Zachary Turner via lldb-dev
> wrote:
>
> Todd, Greg, can you guys confirm this is true? The import lldb would
> succeed if someone ha
just built into the assemblers
> directly for each arch... If you can find out where this can be detected
> within LLVM, we can make sure we don't use any temporary prefixes in symbol
> names and work around this issue. We need to make sure that any functions we
> generate
I guess LLDB was just helping your resolve build issues and make your product
better... :-)
Let us know how things go once you get your build fixed.
Greg
> On Oct 23, 2015, at 9:45 AM, Ramkumar Ramachandra wrote:
>
> Hi,
>
> On Wed, Oct 21, 2015 at 2:27 PM, Greg Clayton wrote:
>>
>
>
I am surprised that this doesn't work as we make an effort to pass the current
environment down to any processes that you spawn by default (at least on MacOSX
we do), but the solution is easy: use the --environment variable with the
"process launch" command:
(lldb) process launch --environment
#x27;. Not sure where
>> this would be abstracted in LLVM or if it is just built into the assemblers
>> directly for each arch... If you can find out where this can be detected
>> within LLVM, we can make sure we don't use any temporary prefixes in symbol
>> names
So when LLDB parses the DW_AT_decl_file attributes, it uses the files from the
line table for the current compile unit. Each of those files is passed through
the module source remapping function:
bool
Module::RemapSourceFile (const char *path, std::string &new_path) const
{
Mutex::Locker loc
pty Declaration...
Can you try this solution out and see if it fixes our issues?
Greg
> On Oct 26, 2015, at 11:13 AM, Greg Clayton via lldb-dev
> wrote:
>
> So when LLDB parses the DW_AT_decl_file attributes, it uses the files from
> the line table for the current compi
> On Oct 26, 2015, at 12:45 PM, Ramkumar Ramachandra wrote:
>
> Greg,
>
> Greg Clayton wrote:
>> Note that for C++ we get the fully qualified name and we pass in an empty
>> Declaration() so they all will compare to the same thing. This would solve
>> our current issue. We would also need to
> On Oct 27, 2015, at 11:18 AM, Ramkumar Ramachandra via lldb-dev
> wrote:
>
> Hi,
>
> I'm using lldb to debug lldb, and I notice that I get this message in
> the inner lldb:
>
> (lldb) p F
> error: Process is running. Use 'process interrupt' to pause execution.
>
> If I 'process interrupt'
Zach: this no longer works:
% ./dotest.py -A x86_64 -C clang -v -t
/.../packages/Python/lldbsuite/test/functionalities/completion
fill "..." in with your path to your lldb root.
It is unable to find lldb because lldbtest_config.lldbExec isn't set
correctly...
> On Oct 28, 2015, at 12:21 PM,
601 - 680 of 680 matches
Mail list logo
