Re: [lldb-dev] LLDB for bare-iron targets lacking support for qC /qfThreadInfo packet

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 jaydeep.pa...@imgtec.com wrote: Hi Greg, The '?' packet always returns 'S05'. There is no thread information available

Re: [lldb-dev] [BUG?] Confusion between translation units?

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

Re: [lldb-dev] llvm assertion while evaluating expressions for MIPS on Linux

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 and work around this issue. We need to make sure that any functions we > generate and JI

Re: [lldb-dev] lldb tests and tear down hooks

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

Re: [lldb-dev] Inquiry for performance monitors

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,

Re: [lldb-dev] Using DYLD_LIBRARY_PATH and lldb

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

Re: [lldb-dev] llvm assertion while evaluating expressions for MIPS on Linux

emporary symbol prefix, ELF tends to use '.'. 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 pre

Re: [lldb-dev] Moving pexpect and unittest2 to lldb/third_party

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

Re: [lldb-dev] Refactoring dotest as a Python package

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,

Re: [lldb-dev] How to disassemble a section (python api)?

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

Re: [lldb-dev] No machine instructions loaded for symbols or target (python api)

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

Re: [lldb-dev] Link warnings about lldb::endian::InlHostByteOrder()

> 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 >

Re: [lldb-dev] Attaching to a stopped (cored) process hangs lldb-server

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:

Re: [lldb-dev] Attaching to a stopped (cored) process hangs lldb-server

> 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

Re: [lldb-dev] Attaching to a stopped (cored) process hangs lldb-server

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

Re: [lldb-dev] incorrect shared library addresses

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

Re: [lldb-dev] LLDB: Unwinding based on Assembly Instruction Profiling

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

Re: [lldb-dev] How to set source line breakpoint using BreakpointCreateByLocation?

> 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.

Re: [lldb-dev] [BUG?] Confusion between translation units?

> 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

Re: [lldb-dev] [BUG?] Confusion between translation units?

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

Re: [lldb-dev] Can Process hold a TargetSP instead of a Target&?

> 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

Re: [lldb-dev] How does attach work on non-Windows?

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

Re: [lldb-dev] How does attach work on non-Windows?

with the process we are attaching to? > On Aug 31, 2015, at 3:16 PM, Greg Clayton via lldb-dev > <lldb-dev@lists.llvm.org> 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 __dy

Re: [lldb-dev] type completion

t;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 >> &

Re: [lldb-dev] type completion

> 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

Re: [lldb-dev] Breakpoints on inlined functions described by DW_AT_ranges

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

Re: [lldb-dev] Compiler types and renamings

> 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

Re: [lldb-dev] Compiler types and renamings

> On Sep 17, 2015, at 10:14 AM, Ryan Brown <rib...@google.com> wrote: > > > > On Thu, Sep 17, 2015 at 10:06 AM Greg Clayton via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > > On Sep 17, 2015, at 3:08 AM, Bruce Mitchener <bruce.mitche...@gmail

Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs

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 =

Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs

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

Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs

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

Re: [lldb-dev] Dealing with executable libraries

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

Re: [lldb-dev] Preliminary support for NetBSD

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

Re: [lldb-dev] lldb::SBDebugger::Terminate() hangs in deadlock

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

Re: [lldb-dev] [BUG] Many lookup failures

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 > <lldb-dev@lists.llvm.org> wrot

Re: [lldb-dev] [BUG] Many lookup failures

> 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

Re: [lldb-dev] [BUG] Many lookup failures

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

Re: [lldb-dev] LLDB using Valgrind's embedded gdbserver

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

Re: [lldb-dev] lldb doesn't work on centos7

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

Re: [lldb-dev] Passing as argument an array in a function call

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] =

Re: [lldb-dev] Passing as argument an array in a function call

> 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;

Re: [lldb-dev] lldb 340.4.119 unable to attach (El Capitan)

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

Re: [lldb-dev] lldb 340.4.119 unable to attach (El Capitan)

> 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. >

Re: [lldb-dev] How to load core on a different machine? - image base addresses

> 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

Re: [lldb-dev] How to load core on a different machine?

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

Re: [lldb-dev] How to load core on a different machine? - image base addresses

> 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

Re: [lldb-dev] How to load core on a different machine?

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

Re: [lldb-dev] Inquiry about .debug_frame

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

Re: [lldb-dev] Linux core dump doesn't show listing when loaded

"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

Re: [lldb-dev] [BUG] Many lookup failures

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

Re: [lldb-dev] [BUG] Many lookup failures

> > 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

Re: [lldb-dev] [BUG] Many lookup failures

> 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

Re: [lldb-dev] lldb with app using shared lib not working

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

Re: [lldb-dev] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback

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 >

Re: [lldb-dev] Catching async debugger output

No there is no way as this is async output that isn't tagged to any specific command. My suggestion is to not use command line stop hooks and catch the stops in your python and do the stuff that you were doing with stop hooks by using the python API. Greg > On Jun 6, 2016, at 7:05 PM, Vadim

Re: [lldb-dev] Release_38 cherry-picks

All of those look simple enough. Two are for testing only and the last one is a simple fix needed for PIE exe debugging. Greg Clayton > On Jun 6, 2016, at 4:22 PM, Francis Ricci via lldb-dev > wrote: > > Hi all, > > I'd like to merge a few more small bugfixes onto

Re: [lldb-dev] Structure variable names

> On Jun 7, 2016, at 9:56 AM, Jiten Thakkar via lldb-dev > wrote: > > Hi All, > I am working on a project as part of my graduate study which uses LLVM. > I am new to LLVM and lldb to be particular. > My goal is to get names of the parameters to functions. If the

Re: [lldb-dev] Discrete code and data memories

I believe that some of the DSPs we have support for (Hexagon?) has this kind of issue. I would speak to Ted Woodward and see if they do anything special for this. Greg Clayton > On May 25, 2016, at 2:16 AM, Tyro Software via lldb-dev > wrote: > > I'm trying to

Re: [lldb-dev] win64 "patch"

Looks good. > On Jun 2, 2016, at 1:40 AM, Carlo Kok via lldb-dev > wrote: > > Seems win64 almost works fine out of the box. 1 minor thing is needed: > > > diff --git > a/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp >

Re: [lldb-dev] GetSymbolContext(lldb.eSymbolContextEverything)

We currently don't expose this information through the API, though we could. You could add a new method to SBValue: namespace lldb { class SBValue { SBData GetDWARFLocation(); } }; This could return the DWARF location as a SBData object. Then you could consume the data by parsing the

Re: [lldb-dev] Variable shadowing

int) v = 2 is shadowed by: Block: {id: 46} [0x10f70-0x10f8d) (int) v = 1 > On Jun 22, 2016, at 1:57 PM, Greg Clayton via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > You can currently do this by checking for other variables to see if any names > match. &

Re: [lldb-dev] Variable shadowing

You can currently do this by checking for other variables to see if any names match. In python when stopped in the function below you can do use the API: (lldb) script Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D. >>> frame_vars = lldb.frame.GetVariables(True,

Re: [lldb-dev] Symbolicate user processes when kernel debugging

> On Jun 22, 2016, at 3:38 AM, John Otter wrote: > >> "I want a GDB server port for user space process 123" > > How would I start this gdb server? Do you mean a gdb-server running in > the target userspace? Wouldn't that make impossible to use it when the > kernel is

Re: [lldb-dev] Using control+left/right arrow to jump between words in the prompt

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'

Re: [lldb-dev] Get source-map from python API?

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

Re: [lldb-dev] Race condition crashes during launching LLDB

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 > <lldb-dev@lists.llvm.org> wrote: &g

Re: [lldb-dev] Prefered way to identify target device in tests?

> 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

Re: [lldb-dev] Making a new symbol provider

> 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

Re: [lldb-dev] Making a new symbol provider

> 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

Re: [lldb-dev] target and host with different endianness

> 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

Re: [lldb-dev] How to use the C++ API? No useful documentation?

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

Re: [lldb-dev] How to use the C++ API? No useful documentation?

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);

Re: [lldb-dev] Module Cache improvements - RFC

he first and only download if it'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 > <lldb-dev@lists.llvm.org> wrote: > > > On Jan 28, 2016, at 4:21 AM, Pavel Labath <lab...@google.com> wrote: >

Re: [lldb-dev] Module Cache improvements - RFC

> 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

Re: [lldb-dev] API for loading debug symbols

> 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

Re: [lldb-dev] How to use the C++ API? No useful documentation?

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

Re: [lldb-dev] Questions for module/symbol load/unload events

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.

Re: [lldb-dev] Questions for module/symbol load/unload events

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

Re: [lldb-dev] API for loading debug symbols

> 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

Re: [lldb-dev] lldb-mi and shared library path

> 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,

Re: [lldb-dev] Module Cache improvements - RFC

> 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

Re: [lldb-dev] Get source-map from python API?

> 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

Re: [lldb-dev] Questions for module/symbol load/unload events

> 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

Re: [lldb-dev] Making a new symbol provider

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

Re: [lldb-dev] Making a new symbol provider

> 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

Re: [lldb-dev] How to get the error message while creating an invalid target?

The SBDebugger::CreateTarget() call take an "SBError " 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

Re: [lldb-dev] Not able to find process plugin for core file

> 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

Re: [lldb-dev] Better error message for attaching to a process already being debugged

> 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 >

Re: [lldb-dev] DWARFASTParserClang and DW_TAG_typedef for anonymous structs

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 > <lldb-dev@lists.llvm.org> wrote: > > Thanks for the example, this is indeed a new regression. It used to work >

Re: [lldb-dev] DWARFASTParserClang and DW_TAG_typedef for anonymous structs

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,

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

> On Mar 18, 2016, at 4:37 PM, Ted Woodward wrote: > > I found why the load addresses are getting dropped. When I do "target modules > load", it calls SectionLoadList::SetSectionLoadAddress(), setting the new > load address for each section. Then when I attach, >

Re: [lldb-dev] Help needed regarding LLDB/MI

> On Mar 11, 2016, at 9:30 AM, RISHABH GUPTA via lldb-dev > wrote: > > Hello all, > > I have started using LLDB/MI but there are some commands that are not working > .I start the MI in terminal as "lldb-mi-3.6 --interpreter" and then launch > the application that I

Re: [lldb-dev] Weird stop stack while hitting breakpoint

You iterate over all the threads and ask each thread what its stop reason is. > On Mar 18, 2016, at 4:25 PM, Jeffrey Tan via lldb-dev > wrote: > > > Hmm, interesting, I got the stop reason from the >

Re: [lldb-dev] How to get the error message while creating an invalid target?

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

Re: [lldb-dev] What's the purpose of the TestStarted-XXX and TestFinished-XXX files?

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

Re: [lldb-dev] Better error message for attaching to a process already being debugged

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

Re: [lldb-dev] SymbolFile::FindGlobalVariables

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

Re: [lldb-dev] SymbolFile::FindGlobalVariables

> > 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

Re: [lldb-dev] Embedding lldb[server] in a CPU simulator

> On Mar 17, 2016, at 5:01 AM, Tyro Software via lldb-dev > wrote: > > I have a simulator for a custom ["toy"] CPU running on Linux, to which I want > to add at least basic debugging support (e.g. stepping instructions, > reading/writing registers and memory), then

Re: [lldb-dev] Missed breakpoint

The only similar case we ran into was a situation where our kernel was playing tricks and essentially re-loading a module at the same location. So what would happen is: 1 - kernel would load a.out's .text section at 0x1 2 - LLDB would notice via a module loaded notification and would set a

  1   2   3   4   5   6   >