> On Oct 30, 2015, at 3:35 AM, Stefan Kratochwil via lldb-dev
> wrote:
>
> Hi Greg,
>
> thanks for your reply.
>
> I am developing a dynamic software updating tool for dynamically linked C
> libraries (in short: I want to patch dynamic libraries in-memory).
>
> My goal is to achieve that wi
> On Nov 3, 2015, at 12:07 PM, Ramkumar Ramachandra wrote:
>
> Greg Clayton wrote:
>> Not really. If you can send me a concrete example of something that isn't
>> working, it might help.
>
> Reporting progress.
>
> 1. `im loo -t` only ever finds one "best match", and the plist seems
> to have
> On Nov 3, 2015, at 1:12 PM, Ramkumar Ramachandra wrote:
>
> Greg Clayton wrote:
>> Be sure to use "frame variable" more as it will never run into these type
>> importation problems when you need to view a variable or members of a
>> variable.
>>
>> It would be interesting to see the output
One different approach is to have your tool write all STDIN to a file (the core
file comes into the tool as STDIN bytes) and then hand LLDB the core file and
do any needed backtracing and data gathering from the core file instead of
actually attaching to the process for real. All executable and
(core_path);
if (process.IsValid())
{
// Do any symbolication you need to on your process core file
// as it will behave just like a real process, you just can't run it
}
> On Nov 3, 2015, at 4:34 PM, Greg Clayton via lldb-dev
> wrote:
>
> One different approach is to hav
Makes sense about not writing the core file to disk.
Is there a way you can detect this "core" mode where we don't have to waitpid?
Seems like that www.sourceware.org message had ideas on how to detect this case?
Greg
> On Nov 3, 2015, at 4:36 PM, Mark Chandler wrote:
>
> Not able to do that
Can someone with linux experience chime in here? It shouldn't be too hard to
figure out which flag 'S' is in. On MacOS we can get a process info structure
from a pid and that will have bits set that indicate 'S'...
If you want to checkin this tool into the LLDB source tree at
trunk/tools/core_t
> On Nov 4, 2015, at 9:47 AM, Todd Fiala wrote:
>
> Although doing any kind of waitpid() in the case of a core file doesn't make
> sense.
The process is still around. The process is being handed the core file via
STDIN, but the process is still around and this tool is attaching to that
proce
So the entire core file is in memory somehow and when it is read from STDIN
will be then be freed? Seems like a really lame way to pass the core file
around as it requires up to 2x the size of the core in memory. We could add a
new version of SBTarget::LoadCore() like:
SBProcess
SBTarget::LoadC
I will need to pass this to Sean Callanan to see if he can tell anything. It
might be a few days before he can get to it.
I'll let you know when I know more.
> On Nov 4, 2015, at 12:10 PM, Ramkumar Ramachandra wrote:
>
> Greg Clayton wrote:
>> Follow my previous suggestions: enable lldb expr
> On Nov 5, 2015, at 1:21 AM, Bruce Mitchener via lldb-dev
> wrote:
>
> Greg et al:
>
> When linking (cmake on OS X), I get a lot of warnings like this:
>
> ld: warning: cannot export hidden symbol lldb::endian::InlHostByteOrder()
> from
> lib/liblldbPluginProcessUtility.a(RegisterCo
> On Nov 5, 2015, at 9:43 AM, Aidan Dodds via lldb-dev
> wrote:
>
> I believe I have tracked down an interesting bug which related to LLDBs
> expression parser.
>
> In my target program I have a math library, a shared object which makes use
> of clangs __attribute__((overloadable)) extension
Currently you can't disassemble a section, nor would you probably want to since
there are padding bytes in between functions.
The easiest way is to get all SBSymbol objects and ask each one for the
instructions if they are code:
(lldb) script
Python Interactive Interpreter. To exit, type 'quit(
It sounds like the symbols in the symbol table don't have valid sizes when they
really should. What kind of executable are you debugging? A PECOFF file? If so,
you should take a look at and fix the code in:
Symtab *
ObjectFilePECOFF::GetSymtab()
What we do for mach-o is to parse the symbol tabl
I fixed this:
% svn commit
Sendinginclude/lldb/Symbol/TypeMap.h
Sendingsource/Symbol/SymbolContext.cpp
Sendingsource/Symbol/TypeMap.cpp
Transmitting file data ...
Committed revision 253618.
> On Nov 18, 2015, at 12:54 AM, Ravitheja Addepally via lldb-dev
> wrote:
>
> H
Zach, I would also like to get rid of all global variables in the process of
this change. The history goes like this: a long time ago someone wrote the
initial dotest.py and parsed the options manually and stored results in global
variables. Later, someone converted the options over to use a pyt
You can else set environment variables when you launch manually:
(lldb) process launch -v DYLD_FRAMEWORK_PATH=/tmp -- arg1 arg2
"env" is nice because it sets it permanently for your target and you don't have
to specify it over and over. But it you ever want to _sometimes_ launch with a
differen
Most compilers emit the same thing for EH frame and for .debug_frame. If this
does indeed differ, then LLDB should parse both, but any such changes should
really do so in a way that prefers .debug_frame over .eh_frame since
.debug_frame should be complete unwind info even though it is just he sa
"thread list" should just list the threads and their stop reasons (no
backtraces). If you want backtraces just do "thread backtrace all".
On Nov 24, 2015, at 1:09 PM, Ted Woodward via lldb-dev
wrote:
>
> I’ve been working on an old rev that we’d released on; now I’m much closer to
> ToT as w
So be sure to enable -fno-limit-debug-info to make sure the compiler isn't
emitting lame debug info.
If things are still failing, check to see what we think "CG::Node" contains by
dumping the type info for it:
(lldb) image lookup -t CG::Node
This will print out the complete class definition t
n up front even though it might be duplicated elsewhere. There
are many valid reasons for reducing the size of debug info: compile times and
link timers are shorter, debug info size is smaller, and more.
Greg
> On Nov 30, 2015, at 9:41 AM, Greg Clayton via lldb-dev
> wrote:
>
>
> On Nov 30, 2015, at 1:57 PM, Eric Christopher wrote:
>
>
>
> On Mon, Nov 30, 2015 at 9:41 AM Greg Clayton via lldb-dev
> wrote:
> So be sure to enable -fno-limit-debug-info to make sure the compiler isn't
> emitting lame debug info.
>
>
> Greg can
>
> This will print out the complete class definition that we have for "CG::Node"
> including ivars and methods. You should be able to see the inheritance
> structure and you might need to also dump the type info for each inherited
> class.
>
> Compilers have been trying to not output a bunch
> On Nov 30, 2015, at 2:54 PM, David Blaikie wrote:
>
>
>
> On Mon, Nov 30, 2015 at 2:42 PM, Greg Clayton wrote:
> >
> > This will print out the complete class definition that we have for
> > "CG::Node" including ivars and methods. You should be able to see the
> > inheritance structure and
> On Nov 30, 2015, at 6:04 PM, Ramkumar Ramachandra wrote:
>
> On Mon, Nov 30, 2015 at 5:42 PM, Greg Clayton wrote:
>> When we debug "a.out" again, we might have recompiled "liba.so", but not
>> "libb.so" and when we debug again, we don't need to reload the debug info
>> for "libb.so" if it h
So one other issue with removing debug info from the current binary for base
classes that are virtual: if the definition for the base class changes in
libb.so, but liba.so was linked against an older version of class B from
libb.so, like for example:
class A : public B
{
int m_a;
};
If A w
Each expression has a language so we should be able to get the Language* for
renderscript:
lldb_private::Language* language = lldb_private::Language::FindPlugin
(m_expr.GetLanguage());
Then you can add a new virtual class on lldb_private::Language that can get any
additional compiler flag
The issue is LLDB wants to know information in the registers in the register
context regarding how they map to "generic" registers. For x86_64 this means:
LLDB_REGNUM_GENERIC_PC -> rip
LLDB_REGNUM_GENERIC_SP -> rsp
LLDB_REGNUM_GENERIC_FP -> rbp
LLDB_REGNUM_GENERIC_RA
Yes the debug info does get bigger. But this is better than having the compiler
omit the "std::string" definition so that you can't view stuff from the STL.
Greg
> On Nov 24, 2015, at 7:22 PM, 陶征霖 via lldb-dev wrote:
>
> Also I found that the size of my program binary increases from 140M to 18
Do we not want to have an "options" global variable in this module that
contains everything instead of having separate global variables in this file?
The idea would be that you could assign directly when parsing arguments:
(configuration.options, args) = parser.parse_args(sys.argv[1:])
Its OK i
Sounds good, looks good then.
> On Dec 8, 2015, at 11:09 AM, Zachary Turner wrote:
>
> One advantage of this approach is that it makes the options available to the
> entire test suite. Even if we have no transferring going on, and we get
> argparse to return us a perfectly organized structure
Looks like this is a MIPS specific bug, probably something we aren't handling
(relocation type maybe?) in the JITed code we produce:
This works fine on the MacOSX lldb:
(lldb) expr -- uint32_t data[6] = {}; test1(data); data
(uint32_t [6]) $0 = ([0] = 0x002a, [1] = 0x002b, [2] = 0x0
> On Dec 16, 2015, at 6:06 AM, Dean De Leo via lldb-dev
> wrote:
>
> Hi,
>
> assume we wish to use the expression evaluator to invoke a function from
> lldb, setting the result into an array passed as parameter, e.g:
>
> void test1(uint32_t* d) {
>for(int i = 0; i < 6; i++){
>d[i
Something is probably NULL, like maybe the register context from frame 1 or
frame 2. Make this crash again and then switch to each frame and dump all of
the local variables.
> On Dec 20, 2015, at 9:30 PM, 陶征霖 via lldb-dev wrote:
>
> Hi,
>
> I build llvm+clang+lldb 3.7 successfully on centos7,
If you ssh in you must enable developer mode one time per boot:
sudo /usr/sbin/DevToolsSecurity --enable
Then you should be able to debug. If you don't, it will popup a dialog box on
the remote system that attempts to get authorization, but you will never see
that in your SSH window...
Let me
Please do cast to 64 bit and user PRI*64 macros. %z isn't supported on all
platforms and we need to get away from using it.
> On Dec 28, 2015, at 10:32 AM, William Dillon via lldb-dev
> wrote:
>
> Hi Todd,
>
> The example I put in my last email is one of a few (maybe one more) instances
> wh
> On Jan 5, 2016, at 1:11 AM, Andre Vergison
> wrote:
>
> Greg, I owe you a Bud (or fruit juice if you prefer) !!
>
> That's all I had to do... Now it works like a charm!
>
> tst$ sudo /usr/sbin/DevToolsSecurity --enable
> Developer mode is now enabled.
> tst$ lldb testabc
> (lldb) target cre
Try this:
% lldb
(lldb) platform select --sysroot /path/to/remote/shared/libraries remote-linux
(lldb)
If this works, there are SBPlatform class calls in the API you can use the
select the platform as done above if you need to not do this from the command
line.
The other option is to chroot i
So this should work:
(lldb) platform select --sysroot /path/to/remote/shared/libraries remote-linux
(lldb)
So you need to make sure that your sysroot ("/path/to/remote/shared/libraries")
contains files as they would appear on the remote system with the right paths
("/usr/lib/libc.so" should b
> On Jan 6, 2016, at 3:39 PM, Eugene Birukov wrote:
>
> OK, I'll try to see what happens with the platform. The truth is that shipped
> lldb-3.7.0 does not load core on Linux at all and I am using custom version
> that has been patched (by restoring some 3.6.0 code). So, there might be a
> pr
> On Jan 6, 2016, at 4:34 PM, Eugene Birukov wrote:
>
> Correction: platform trick almost works. For some reason two libraries are
> not affected, but the rest are OK.
> Hmm... image list does not have load addresses.
Does something show when you just debug something on linux like /bin/ls? Tr
> On Jan 7, 2016, at 9:02 AM, Eugene Birukov wrote:
>
> Forking the thread since image list looks like an independent issue.
>
> • There is no image base addresses on Linux. Is this a known issue?
It is now!
> • I did not find any C++ API to get it in my program. Did I miss it?
> On Jan 7, 2016, at 9:48 AM, Eugene Birukov wrote:
>
> > It is now!
>
> Good :). Any plans to fix it? I guess I should just file a bug, right?
>
Please file a bug. Someone probably will from the linux community, possibly
even you?
> > The main question is what do you consider to be your "i
So anything that is missing can be added to your ~/.editrc file since LLDB uses
the editline library and that reads .editrc file.
Examples of what you can add to your .editrc file:
lldb:bind '^[[5C' vi-next-word
lldb:bind '^[[5D' vi-prev-word
lldb:bind '^D' ed-delete-next-char
lldb:bind '^B' ed-
That being said, feel free to add something the SB API and propose a patch.
Greg
> On Jan 14, 2016, at 3:13 PM, Jim Ingham via lldb-dev
> wrote:
>
> There is currently no API to access the settings. You have to cons up
> commands and use SBCommandInterpreter::HandleCommand to execute them.
>
> On Jan 19, 2016, at 10:58 AM, Jim Ingham wrote:
>
> If you mean "Add an API that sets the source-map for a target" say to
> SBTarget, then that sounds great.
Indeed this is what I meant to say. Add an API to SBTarget that allows you to
modify the source map.
>
> But if we're going to add
One thing to think about is you can actually just run an expression in the
program that is being debugged without needing to change anything in the GDB
remote server. So this can all be done via python commands and would require no
changes to anything. So you can run an expression to enable the
> On Feb 4, 2016, at 2:24 AM, Pavel Labath via lldb-dev
> wrote:
>
> On 4 February 2016 at 10:04, Ravitheja Addepally
> wrote:
>> Hello Pavel,
>>In the case of expression evaluation approach you mentioned
>> that:
>> 1. The data could be accessible only when the target is stopp
> On Feb 11, 2016, at 3:41 PM, Zachary Turner via lldb-dev
> wrote:
>
> Hi,
>
> I want to make a new symbol provider to teach LLDB to understand microsoft
> PDB files. I've been looking over the various symbol APIs, and I have a few
> questions.
>
> 1. Under what circumstances do I need
> On Feb 11, 2016, at 7:55 AM, Philippe Lavoie via lldb-dev
> wrote:
>
>
> We have a big-endian target that we debug from LLDB running on Windows
> through a custom process plugin and communication protocol.
>
> The target's default byte order is set to eByteOrderBig in
> 'g_core_definition
> On Feb 11, 2016, at 12:15 PM, Ted Woodward via lldb-dev
> wrote:
>
> I’m working on getting the tests running with Hexagon, and have a question
> about identifying the target architecture.
>
> Hexagon LLVM doesn’t use a couple architectures like “x86_64” or “i386”,
> instead we have many
> On Feb 11, 2016, at 6:56 PM, Zachary Turner wrote:
>
>
>
> On Thu, Feb 11, 2016 at 5:35 PM Greg Clayton wrote:
>
> > On Feb 11, 2016, at 3:41 PM, Zachary Turner via lldb-dev
> > wrote:
> >
> > Hi,
> >
> > I want to make a new symbol provider to teach LLDB to understand microsoft
> > PDB
This is a clear bug in LLDB. If you have a repro case, please file a bug and
attach the instructions on how to make this happen. Our API must be able to
handle things like this.
SBTarget has a shared pointer to a lldb_private::Target. If you have a
reference to a target, it should keep that tar
If you are going to set async to true, then you must consume the events by
waiting for events. See the following example:
svn cat
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
So you can rewrite your wait_for_process_stop to use the debugger to fetch the
events
ith process.Continue() or any
thread.StepXXX() calls, your process will stay stopped. But when you ask to
make it run, you must consume events to know what the process is actually
doing...
> On Feb 12, 2016, at 10:02 AM, Greg Clayton via lldb-dev
> wrote:
>
> If you are going to
> On Feb 18, 2016, at 4:16 PM, Ted Woodward via lldb-dev
> wrote:
>
> Quoted strings in target.run-args aren’t handled correctly.
>
> (lldb) settings set target.run-args "foo bar"
> (lldb) settings show target.run-args
> target.run-args (array of strings) =
> [0]: "foo bar"
>
> This looks
> On Feb 4, 2016, at 1:51 PM, Ted Woodward via lldb-dev
> wrote:
>
> I’d expect “-gdb-set solib-search-path” to call “target modules search-paths
> add”, and it does, but only when the –target-remote command is issued. It
> also doesn’t handle the multiple path case, :…
>
> I think it shoul
You have to consume the events from the debugger's listener (unless you specify
a different listener in your SBLaunchInfo or SBAttachInfo).
We have python code that can show you how to consume events:
svn cat
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
So eve
> On Jan 28, 2016, at 4:21 AM, Pavel Labath wrote:
>
> Hello all,
>
> we are running into limitations of the current module download/caching
> system. A simple android application can link to about 46 megabytes
> worth of modules, and downloading that with our current transfer rates
> takes abo
Ok, sounds like you first need to see if "-gdb-set solib-search-path" is hooked
up to "target modules search-paths add". If not, hook it up. Then we probably
need to add a function to Platform.cpp that can use a target's module search
paths to help find an executable. This can probably be a virt
27;s not there.
>
> If you already do all this, then disregard.
>
> On Mon, Feb 22, 2016 at 4:39 PM Greg Clayton via lldb-dev
> wrote:
>
> > On Jan 28, 2016, at 4:21 AM, Pavel Labath wrote:
> >
> > Hello all,
> >
> > we are running into limitatio
> On Feb 23, 2016, at 10:31 AM, Nico Weber wrote:
>
> On Tue, Feb 23, 2016 at 1:21 PM, Tamas Berghammer via lldb-dev
> wrote:
> Yes we already have a disk cache on the host. I agree with you that waiting
> 30s at the first startup shouldn't be an issue in general (Pavel isn't
> sharing my opi
I need to spend some time writing this up, but until then here is some info.
We created a python script that uses the LLDB public API to grab async events
so people can see how to do things:
svn cat
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
If you look in he
Here is the fixed code:
SBListener listener = debugger.GetListener();
SBLaunchInfo launch_info(args);
launch_info.SetEnvironmentEntries(env, true);
launch_info.SetWorkingDirectory("/home/dev/helloWorld");
SBProcess process = target.Launch(launch_info, error);
process.GetBroadcaster().AddListene
Not sure. First off, you don't need to do:
process.GetBroadcaster().AddListener(...)
The debugger's listener is already listening to all the events. If you don't
specify a listener during launch the process will use the debugger's listener
automatically. If you end up making your own process li
> On Feb 24, 2016, at 4:21 PM, Mike Gulick via lldb-dev
> wrote:
>
> Hi lldb-dev,
>
> I'm trying to write some tooling to help with debugging complex builds on
> Mac. The libraries all have debugging info separated into .dSYM/
> directories. Due to some complexities in our build system, th
> On Feb 26, 2016, at 3:06 PM, Mike Gulick wrote:
>
> On Thu, 25 Feb 2016 10:18:42 -0800
> Greg Clayton wrote:
>
>>
>> Yes: use the "target symbols add" to do thing manually:
>>
>> (lldb) target symbols add
>> --shlib-name /path/to/my/workspace/bin/maci64/libA.dylib
>> /archive/builds/1234/
> On Feb 28, 2016, at 2:17 PM, Paul Peet wrote:
>
> Hey,
>
> Just to let you know that I think I made some progress in determine the
> problem.
> I've basically setup an vm (archlinux, linux 4.4, lldb 3.7.1) and
> tried the code on it. To my surprise it gave me proper output without
> non-dete
In general where you see the event bits defined like SBTarget.h for your case,
the class that contains the event bit definitions:
class SBTarget
{
public:
//--
// Broadcaster bits.
//--
As Jim said there really isn't just one address per module. You will want to
display the address of each of the sections for a module under that module. So
something like:
a.out
|- .text @ 0x1
|- .data @ 0x2
\- .bss @ 0x3
> On Feb 29, 2016, at 2:02 PM, Jeffrey Tan wrote:
>
> On Feb 29, 2016, at 5:09 PM, Zachary Turner wrote:
>
> Suppose you've got two line sequences.
>
> First sequence:
> 4198512
> 4198544
> 4198547
> 4198562
>
> Second sequence:
> 4198528
> 4198531
> 4198537
> 4198552
>
> These two line sequences overlap, and will not be inserted correctly i
> On Feb 29, 2016, at 5:51 PM, Zachary Turner wrote:
>
>
>
> On Mon, Feb 29, 2016 at 5:49 PM Zachary Turner wrote:
> Those are addresses. Here's the situation I was encountering this on:
>
> // foo.h
> #include "bar.h"
> inline int f(int n)
> {
> return g(n) + 1;
> }
>
> // bar.h
> inl
> On Feb 29, 2016, at 11:02 PM, Jeffrey Tan wrote:
>
> My assumption is that different sections of the binary will be mapped
> continuously in memory; and the first section(which should be a header
> section for the binary) will stands for the base address of the whole module.
> Is this assum
> On Mar 1, 2016, at 11:30 AM, Zachary Turner wrote:
>
> We do know the last line of a function. In the review i posted, you can see
> the condition where i set is_epilogue to true. That is the last line of a
> function corresponding to the } (although the function may contain additional
> by
On Mar 1, 2016, at 11:45 AM, Zachary Turner wrote:
>
> Alright I think i get it. Basically terminal entry means "everything from
> this address onwards is not part of any function"
Yes
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llv
Each call into the lldb::SB* API will take a target lock and possible a process
read/write lock.
We do have a SBThreadCollection class that we can use. Feel free to add an API
like this to SBProcess:
class SBProcess
{
SBThreadCollection GetThreads();
};
class SBThreadCollection
{
SBT
> On Mar 4, 2016, at 8:08 AM, Paul Peet via lldb-dev
> wrote:
>
> Hi Pavel,
>
> First of all, thank you for looking into this. I really appreciate it.
> Secondly, the check with GetRestartedFromEvent did the trick.
> I am finally getting correct information. Thank You very much.
I would like
Not sure why we aren't treating this as a relative path. Probably because of
the 1000 '/' characters. Feel free to dig into lldb_private::FileSpec and play
around and see where things are going wrong.
You can probably fix LLDB, when it resolves paths, to clean this up, but we
typically don't re
> On Mar 7, 2016, at 3:07 PM, Zachary Turner via lldb-dev
> wrote:
>
> This discussion originally started on a code review thread, but I figured I
> would continue it here since the patch has landed and I want to do more work
> as a followup.
>
> So LLDB's LineTable data structures have the
.
};
Each instance is 64 bytes and quite a bit more expensive to copy around.
> On Mar 7, 2016, at 3:13 PM, Greg Clayton via lldb-dev
> wrote:
>
>
>> On Mar 7, 2016, at 3:07 PM, Zachary Turner via lldb-dev
>> wrote:
>>
>> This discussion originally star
> On Mar 7, 2016, at 3:21 PM, Zachary Turner wrote:
>
> Does DWARF not store this information? Because it seems like it could be
> efficiently stored in an interval tree, the question is just whether it is
> efficient to convert what DWARF stores into that format.
No it stores it just like w
> On Mar 7, 2016, at 4:08 PM, Jeffrey Tan wrote:
>
> Hi Greg,
>
> I am not sure if I understand the behavior here: the long relative file path
> from our build system does *not* exist on file system, do you mean lldb will
> always try to resolve this relative path to a *real* file on file sys
> On Mar 7, 2016, at 5:27 PM, Jeffrey Tan wrote:
>
> Thanks for the info, I will debug this.
> One more quick question related to this: in full path breakpoint case(IDE
> scenario), do we compare both file name and directory path exact match and
> bind breakpoint successfully? I ask this becau
If you are connected to a live process, you just need to look up the
lldb::SBAddress for a load address using the SBTarget
lldb::SBTarget target = ...;
lldb::addr_t load_addr = ...;
lldb::SBAddress addr = target.ResolveLoadAddress (load_addr);
if (addr.GetSection().IsValid())
{
// Load addre
Yep
> On Mar 8, 2016, at 12:56 PM, Zachary Turner wrote:
>
> Let's suppose I've got this function (ignore the operands to branch
> instructions, I disassembled a real function and just manually adjusted
> addresses on the left side only just to create a contrived example).
>
> infinite-dwarf
If the PDB line tables have sizes you could do:
PDBLineEntry curr = pdb->GetLineEntry(n);
PDBLineEntry next = pdb->GetLineEntry(n+1);
line_entries.insert(curr.addr, curr.line, curr.file, false /*is_terminal*/);
if (curr.addr + curr.size != next.addr)
{
// Insert terminal entry for end of cur
The SBDebugger::CreateTarget() call take an "SBError &error" as the last
argument. The error will contain any error message:
lldb::SBTarget
CreateTarget (const char *filename,
const char *target_triple,
const char *platform_name,
bool
Yep, this is legacy API that must stay in because we had it in our API waaa
back when and we never remove API once it has made it into a build and someone
uses it. We might mark it as deprecated, which we should do to
CreateTargetWithFileAndArch and the other function, but we never remove it
I would be happy to see these files go away if no one is using them...
> On Mar 9, 2016, at 2:32 PM, Adrian McCarthy via lldb-dev
> wrote:
>
> The test traces directory tends to accumulate thousands and thousands of
> TestStarted-XXX and TestFinished-XXX files. What purpose do they serve?
>
Did you follow the instructions and you have made your "lldb_codesign" code
signing certificate?:
svn cat http://llvm.org/svn/llvm-project/lldb/trunk/docs/code-signing.txt
If you don't do this, your debugserver won't have the ability to debug
anything. If you don't want to do this, you can remo
So we ran into a problem where we had anonymous structs in modules. They have
no name, so we had no way to say "module A, please give me a struct named...
nothing in the namespace 'foo'". Obviously this doesn't work, so we always try
to make sure a typedef doesn't come from a module first, by as
> On Mar 9, 2016, at 5:40 PM, Jeffrey Tan wrote:
>
> Hi Greg, I am using the lldb(/usr/bin/lldb) installed by Xcode not self-built
> one. For example, I can use lldb to attach to chrome without any problem. And
> I can see the debugserver it uses is from
> "/Applications/Xcode.app/Contents/Sh
> On Mar 10, 2016, at 4:34 AM, Bhushan Attarde via lldb-dev
> wrote:
>
> Hi All,
>
> I am working on adding support for MIPS coredump file in LLDB.
>
> I tried below command:
>
> (lldb) target create "app_mips.elf" --core "core_mips"
> error: Unable to find process plug-in for core file '
Thanks for the example, this is indeed a new regression. It used to work (Xcode
7.2), but now with top of tree it doesn't. Sean Callanan recently pulled out a
bunch of work around we used to have in the expression/JIT so that we can avoid
certain issues that were caused by said work arounds, and
Please file a bug for this and I will relate it to our internal apple bug that
tracks this issue.
> On Mar 10, 2016, at 2:03 PM, Greg Clayton via lldb-dev
> wrote:
>
> Thanks for the example, this is indeed a new regression. It used to work
> (Xcode 7.2), but now with top of
> On Mar 11, 2016, at 11:02 AM, Zachary Turner via lldb-dev
> wrote:
>
> I'm trying to implement this function for PDB. There are two overloads:
>
> uint32_t
> FindGlobalVariables (const ConstString &name, const CompilerDeclContext
> *parent_decl_ctx, bool append, uint32_t max_matches, Varia
>
> Also why does the lldb_private::Variable() class take a DWARFExpression to
> its constructor? Seems like this is wrong in the face of non-DWARF debug
> information.
They are powerful enough to handle any variable location. More powerful than
any other format I have seen. You have two choi
See my other email. You can abstract this, but it doesn't seem worth it unless
PDB has some really powerful way to express variable locations?
> On Mar 11, 2016, at 11:39 AM, Zachary Turner via lldb-dev
> wrote:
>
> Can we abstract this somehow? Converting all my debug info to DWARF seems
>
Feel free to abstract if you need to. The page you sent me to has _very_ simple
locations that would convert to DWARF expressions very easily. Probably less
that a hundred lines of code.
If you need to abstract, making a lldb_private::Location class that
DWARFExpression would implement the need
> On Mar 11, 2016, at 1:02 PM, Zachary Turner wrote:
>
> How large of a change do you think it would be to abstract out the location
> information for the variable? As far as I can tell, our uses of this
> DWARFExpression on Variables are very limited:
>
> 1. In ValueObjectVariable::UpdateVa
1 - 100 of 680 matches
Mail list logo
