Re: [lldb-dev] Watching reads/writes on optimized variables?

> On Aug 26, 2016, at 7:25 AM, Christian Convey via lldb-dev > wrote: > > Hi guys, > > I'm trying to use watchpoints to detect user-space reads/writes of an > arbitrary C/C++ program variable. > > For example: > void foo() { > int x; // <-- I'm interested in 'x' > x = 10; // <-

Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

It is ok for a core file to not pledge allegiance to an OS, it is ok for the OS to be set to "*" or any OS. Linux core files are useless without the main executable anyway so these two things should used together to do the right thing. When creating the core files you use: lldb::ProcessSP Proce

Re: [lldb-dev] Watching reads/writes on optimized variables?

Maybe the volatile keyword? volatile int x = 10; > On Aug 26, 2016, at 9:27 AM, Christian Convey > wrote: > > Hi Greg, > > >>> >>> Does anyone know of a way to minimize or eliminate this problem? >> >> Just take the address of your variable at some point in your code and it >> will force

Re: [lldb-dev] Passing std::atomics by value

> On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev > wrote: > > I recently updated to Visual Studio 2015 Update 3, which has improved its > diagnostics. As a result of this, LLDB is uncompilable due to a slew of > errors of the following nature: > > D:\src\llvm\tools\lldb\include\l

Re: [lldb-dev] Passing std::atomics by value

> On Aug 26, 2016, at 11:24 AM, Greg Clayton via lldb-dev > wrote: > >> >> On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev >> wrote: >> >> I recently updated to Visual Studio 2015 Update 3, which has improved its >> diagnostics. As

Re: [lldb-dev] Passing std::atomics by value

So after speaking with local experts on the subject, we do indeed have a problem. Please convert all placed where we pass lldb_private::Address by value to pass by "const Address &". Anyone that is modifying the address should make a local copy and work with that. Is Address the only class that

Re: [lldb-dev] Passing std::atomics by value

There is no need to delete the lldb_private::Address copy constructor. Just stop functions from passing it by value. > On Aug 26, 2016, at 1:13 PM, Zachary Turner wrote: > > IOW, marking it =delete() is no different than deleting the copy constructor > above, but at least if you mark it delete

Re: [lldb-dev] Passing std::atomics by value

> On Aug 26, 2016, at 5:37 PM, Zachary Turner wrote: > > How would you enforce that, other than to ask people to try to remember not > to do it? It seems to me like std::atomic not being copy-constructible is > telling you that, well, you shouldn't be copying it. It just won't compile on pla

Re: [lldb-dev] Symbol Server for everyone.

If you want to go agnostic, then you can just integrate into the following functions from Symbols.h: //-- // Locate the symbol file given a module specification. // // Locating the file should happen only on the l

Re: [lldb-dev] Passing std::atomics by value

> On Aug 29, 2016, at 8:56 AM, Zachary Turner wrote: > > How about making it a std::unique_ptr>? This way > there's no risk of re-introducing a potential race, and copying still works. lldb_private::Address is a member variable in lldb_private::Symbol and it needs to say as small as possible

Re: [lldb-dev] debugserver and llvm

> On Aug 27, 2016, at 3:14 PM, Zachary Turner via lldb-dev > wrote: > > What is the status of using LLVM from debugserver? AFAICT, it doesn't use > llvm, but it DOES use some lldb private libraries, in which case it is > already implicitly linking against LLVM anyway. > > So why can't LLVM

Re: [lldb-dev] debugserver and llvm

> On Aug 29, 2016, at 10:58 AM, Zachary Turner wrote: > > I don't plan to change debugserver's link requirements. What I'm saying is > that debugserver is including StringExtractor.h cross-project from LLDB, and > so even something as simple as including an LLVM header from > StringExtractor

Re: [lldb-dev] debugserver and llvm

That is fine. > On Aug 29, 2016, at 11:40 AM, Zachary Turner wrote: > > I think the easiest way to do this is to copy the current implementation to > StdStringExtractor and then have debugserver use that. That only requires > 1-2 lines of code change in debugserver, and no code change in LLDB

Re: [lldb-dev] Not able to set breakpoints above line #70 in lldb-mi.

Seems to work for me just fine with your binary: lldb /Volumes/work/gclayton/Downloads/MipsTest.bin (lldb) target create "/Volumes/work/gclayton/Downloads/MipsTest.bin" Current executable set to '/Volumes/work/gclayton/Downloads/MipsTest.bin' (mipsr6el). (lldb) break set -H -f Main.cpp -l 70 Brea

Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

> On Aug 30, 2016, at 7:33 AM, Howard Hellyer via lldb-dev > wrote: > > "Ted Woodward" wrote on 26/08/2016 16:17:18: > > > That works fine for host debug, but not so much for embedded. On > > Hexagon, we support 2 OS cases – standalone (which means no OS, or > > an OS that lldb doesn’t know

Re: [lldb-dev] Problem with watchpoints

> On Sep 8, 2016, at 4:47 PM, Ted Woodward via lldb-dev > wrote: > > I recently discovered a problem with watchpoints talking to the Hexagon > simulator: > > (lldb) w s e 0x1000 > error: Watchpoint creation failed (addr=0x1000, size=4). > error: Target supports (0) hardware watchpoint slots.

Re: [lldb-dev] [OS X]: building lldb with cmake

The biggest issue with trying to use cmake on macOS is that there is no support for building frameworks, please correct me if I am wrong. The xcode build will build a "LLDB.framework" that contains all headers and the shared library, and the "lldb" command line tool that links against that. We r

Re: [lldb-dev] Help with Xcode crash on lldb_private::(anonymous namespace)::parse_builtin_type

So any string that will be demangled by our internal demangler must start with "_Z". In the shared library or main application's executable mach-o file, the mangled names will contain an extra leading "_". We strip off this extra leading _ and will end up with a string of "_Z". So your strin

Re: [lldb-dev] lldb type summary provider - SBProcess is invalid

> On Sep 13, 2016, at 9:50 PM, Lei Kong via lldb-dev > wrote: > > Thanks! > SBValue.process works! > > I have another script that I run manually to search process memory for > certain patterns, not a type summary provider, there is no SBValue passed to > my script, in such a case, how do I

Re: [lldb-dev] lldb type summary provider - SBProcess is invalid

When using the "script" command, lldb.process/thread/frame are always setup so you can use them _in_your_text_, but you probably shouldn't rely on them being setup inside your function. You should pass the process to it: (lldb) script myfile.func(lldb.process, args) Then you can use "myfile.fun

Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'

Try printing the type of the value you are passing in the line: vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr-8, error) print type(vtableAddr) print type(vtableAddr-8) It seems like it thinks vtableAddr doesn't fit into a lldb::addr_t which is a uint64_t > On Sep 16, 2016

Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'

If you want to send your fabdbg.py we can try it out and see if we see anything wrong. > On Sep 19, 2016, at 9:12 AM, Greg Clayton wrote: > > Try printing the type of the value you are passing in the line: > >vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr-8, error) > > prin

Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'

> On Sep 19, 2016, at 10:33 AM, Lei Kong wrote: > > You are right, it seems the argument is out of range, both vtableAddr and > vtableAddr-8 are “8.5” byte long. Maybe there is something wrong with the way > I get vtableAddress? I will clean up my full script and send it to you if the > follo

Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'

> On Sep 19, 2016, at 1:09 PM, Greg Clayton wrote: > > >> On Sep 19, 2016, at 10:33 AM, Lei Kong wrote: >> >> You are right, it seems the argument is out of range, both vtableAddr and >> vtableAddr-8 are “8.5” byte long. Maybe there is something wrong with the >> way I get vtableAddress? I

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev > wrote: > > Following up with Kate's post from a few weeks ago, I think the dust has > settled on the code reformat and it went over pretty smoothly for the most > part. So I thought it might be worth throwing out some ideas for whe

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:11 PM, Zachary Turner wrote: > > > > On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > • Separate testing tools > > • One question that remains open is how to represent > > the complicated needs of a debugger in lit tests.

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote: > >> >> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev >> wrote: >> >> >>> On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev >>> wrote: >>> >>>

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:24 PM, Zachary Turner wrote: > > > > On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev > > wrote: > > > > Following up with Kate's post from a few weeks ago, I think the dust has > > settled on the co

Re: [lldb-dev] LLDB Evolution - Final Form

t; On Mon, Sep 19, 2016 at 2:34 PM Greg Clayton wrote: > > > On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote: > > > >> > >> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev > >> wrote: > >> > >> > >>> On Sep 19, 2016, a

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:46 PM, Mehdi Amini wrote: > >> >> On Sep 19, 2016, at 2:34 PM, Greg Clayton wrote: >> >>> >>> On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote: >>> >>>> >>>> On Sep 19, 2016, at 2:02 PM, Greg

Re: [lldb-dev] LLDB Evolution - Final Form

uld be one thing. But they aren't. You just run into them and must decipher what it means. > > On Tue, Sep 20, 2016 at 10:33 AM Greg Clayton wrote: > > > On Sep 19, 2016, at 2:46 PM, Mehdi Amini wrote: > > > >> > >> On Sep 19, 2016, at 2:34 PM, Greg C

Re: [lldb-dev] LLDB Evolution - Final Form

Greg Clayton wrote: >>>> >>>>> >>>>> On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote: >>>>> >>>>>> >>>>>> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev >>>>>> wrot

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 1:45 PM, Zachary Turner wrote: > > I do agree that asserts are sometimes used improperly. But who's to say that > the bug was the assert, and not the surrounding code? For example, consider > this code: > > assert(p); > int x = *p; Should be written as: assert(p); if

Re: [lldb-dev] LLDB Evolution - Final Form

Again, strlen is a stupid example as it is well documented. All of llvm and clang are not. > On Sep 20, 2016, at 1:59 PM, Zachary Turner wrote: > > > > On Tue, Sep 20, 2016 at 1:55 PM Greg Clayton wrote: > > > On Sep 20, 2016, at 1:45 PM, Zachary Turner wrote: > > > > I do agree that assert

Re: [lldb-dev] LLDB Evolution - Final Form

A better solution would be to return an error indicating what went wrong with llvm::Error. I really can't believe people are ok with "well you called me with the wrong parameters that aren't documented, I am unhappy and will crash your program" mentality. > On Sep 20, 2016, at 2:11 PM, Adria

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 2:21 PM, Ed Maste via lldb-dev > wrote: > > On 19 September 2016 at 16:18, Zachary Turner via lldb-dev > wrote: >> >> De-inventing the wheel - We should use more code from LLVM, and delete code >> in LLDB where LLVM provides a solution. > > Another example of duplicated

Re: [lldb-dev] LLDB Evolution - Final Form

We should avoid crashing if there is a reasonable work around when the input is bad. StringRef with NULL is easy, just put NULL and zero length and don't crash. Just because it is documented, doesn't mean it needs to stay that way, but I am not going to fight that battle. We should make every e

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 2:49 PM, Mehdi Amini wrote: > > >> On Sep 20, 2016, at 2:46 PM, Zachary Turner wrote: >> >> Occasionally (and in my experience *very* occasionally), you need to treat >> "" as different from null. doesn't StringRef store an actual pointer to ""? This would mean String

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 2:41 PM, Mehdi Amini wrote: > >> >> On Sep 20, 2016, at 2:31 PM, Greg Clayton wrote: >> >> We should avoid crashing if there is a reasonable work around when the input >> is bad. StringRef with NULL is easy, just put NULL and zero length and don't >> crash. Just becaus

Re: [lldb-dev] LLDB Evolution - Final Form

I agree that for case #1, we must handle that by checking the pointer. Same thing for #2. For #3 we just need to fix the bug in clang. Our case in more of a different issue. The cause of most crashes for us is in the clang::ASTContext class as we try to create types from DWARF. clang::ASTContex

Re: [lldb-dev] Adding D language demangling support

It might be nice to add demangling support to llvm and then use it by modifying "Mangled::GetDemangledName()" in Mangled.cpp. This is where all demangling happens. Hopefully you have a great prefix that won't conflict with other languages "_Z" for C++, "_T" for swift. But the code in Mangled::G

Re: [lldb-dev] LLDB Evolution - Final Form

the variable used to be a "const char *" in the last example... > On Sep 21, 2016, at 1:43 PM, Greg Clayton wrote: > > I am laughing as I convert code over to using StringRef and I get crashes: > > if (name == NULL) > > StringRef is nice enough to implicitly construct a StringRef from NULL or

Re: [lldb-dev] LLDB Evolution - Final Form

I am laughing as I convert code over to using StringRef and I get crashes: if (name == NULL) StringRef is nice enough to implicitly construct a StringRef from NULL or nullptr so that it can crash for me... > On Sep 21, 2016, at 11:09 AM, Zachary Turner via lldb-dev > wrote: > > Adding anothe

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 21, 2016, at 1:55 PM, Zachary Turner wrote: > > :-/ The same thing happens if you write Foo &f = *nullptr; It's a > reference. I might be a good idea to add an overloaded constructor for nullptr and void * and delete them so that we can't implicitly create a StringRef from nullptr

Re: [lldb-dev] Adding D language demangling support

stead of duplicating code > > On Wed, Sep 21, 2016 at 10:24 AM, Greg Clayton via lldb-dev > wrote: > It might be nice to add demangling support to llvm and then use it by > modifying "Mangled::GetDemangledName()" in Mangled.cpp. This is where all > demangling h

Re: [lldb-dev] Adding D language demangling support

ess useful than > current situation, where lldb just returns the symbol unchanged if it can't > demangle. > > > > > > On Sep 21, 2016, at 3:00 PM, Timothee Cour wrote: > > > > Is there a way to provide a hook (eg, via an extern(C) function, or using

Re: [lldb-dev] Adding D language demangling support

PM, Timothee Cour wrote: > > > > On Wed, Sep 21, 2016 at 3:35 PM, Greg Clayton via lldb-dev > wrote: > Sounds like you could then make a setting that is a dictionary where you say > what the prefix is (like maybe "_D") and the value is the path to the too

Re: [lldb-dev] Converting global option tables to use ArrayRef

That sounds like a good patch. I look forward to seeing it. > On Sep 21, 2016, at 11:48 PM, Zachary Turner via lldb-dev > wrote: > > I have a patch I'd like to submit tomorrow which converts all of the global > command option tables from C-style arrays to llvm ArrayRefs. > > Actually they are

Re: [lldb-dev] Adding D language demangling support

quot;lldb" namespace, is an API and we don't break it. We could try to make these plug-ins at the public layer, but we can't done that with anything except command line command plugins. Greg > > -Johan > > On Thu, Sep 22, 2016 at 1:13 AM, Greg Clayton via lldb-dev

Re: [lldb-dev] Adding D language demangling support

d, Sep 21, 2016 at 4:13 PM, Greg Clayton via lldb-dev > wrote: > You could have a setting that allows you to specify prefix as the key with a > dylib path as a value. Would you expect a function with certain name or would > you need to specify the function name (probably mangled) as w

Re: [lldb-dev] Adding D language demangling support

, debugging D code is very much > broken without that change). > > -Johan > > > On Thu, Sep 22, 2016 at 7:21 PM, Greg Clayton via lldb-dev > wrote: > I like the JSON approach. We might need to include the mangled name for the > function or specify where arguments go

Re: [lldb-dev] RFC: Break/Watchpoint refactor

> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev > wrote: > > I have been giving study to the private and public classes for > break/watchpoints and I have some ideas for how to improve them. I am > looking for comments from the community on this now to avoid wasted work and

Re: [lldb-dev] RFC: Break/Watchpoint refactor

> On Sep 27, 2016, at 3:43 PM, Zachary Turner via lldb-dev > wrote: > > One solution I've seen (I think boost does this as well) is to make a utility > class called noncopyable that you can privately inherit from: > > class noncopyable { > public: >noncopyable(const noncopyable &) = delet

Re: [lldb-dev] LLDB can't find source...but it can?

> On Oct 7, 2016, at 4:53 PM, Ted Woodward via lldb-dev > wrote: > > Background – I’m working on getting LLDB to run on Hexagon Linux, built with > an LLVM toolchain. We’re using libc++ and MUSL. The loader is a bit > squirrelly right now, so I’ve built LLDB statically. > > I’ve got full so

Re: [lldb-dev] fate of TimeValue

I am fine with TimeValue going away. I would love to just use STL std::chrono stuff if we can get away with it. If there is a bunch of code that gets re-written all of the time, then using the LLVM TimeValue class is fine if it is needed. Greg > On Oct 7, 2016, at 10:29 PM, Mehdi Amini via lld

Re: [lldb-dev] get function name from dwarf info

> On Oct 7, 2016, at 7:32 AM, Carlo Kok via lldb-dev > wrote: > > >>> How do I get the dw_at_name field? I don't need lldb to decypher the >>> mangling I use, I just want access to the linkage name and real encoded >>> name? >>> >>> Also how do I get the type this is contained in (presuming t

Re: [lldb-dev] add custom vendor commands

> On Oct 13, 2016, at 2:24 AM, Giusti, Valentina via lldb-dev > wrote: > > Hello all, > > Background: > Intel CPUs that support MPX have a limited number of bound registers. For any > program that has more objects than fit into these registers, the bounds must > be kept elsewhere. For this

Re: [lldb-dev] unaligned cast in TCPSocket::Connect

> On Oct 13, 2016, at 10:52 AM, Ted Woodward via lldb-dev > wrote: > > TCPSocket::Connect has this line: > host_str = ::inet_ntoa (*(struct in_addr > *)*host_entry->h_addr_list); > > host_entry->h_addr_list is a char**, while struct in_addr contains a > uint32_t. Casting like th

Re: [lldb-dev] LLDB can't find source...but it can?

This is a compiler bug. > On Oct 14, 2016, at 12:14 PM, Ted Woodward > wrote: > >> Probably a debug info problem. Before we know to look for addresses within >> a compile unit, the compile unit must claim it has a function that contains >> this >> address. So check the DWARF in the compile un

Re: [lldb-dev] LLDB can't find source...but it can?

Send me the file offline. I will help narrow it down for you. > On Oct 17, 2016, at 9:58 AM, Ted Woodward wrote: > > What's the compiler bug? I see a DW_AT_subprogram entry for main_gdbserver, > and linetable entries for the addresses of main_gdbserver. > > I've found that getting DWARF compi

Re: [lldb-dev] File::Read does not read everything

It is probably best to make the code loop as long as "bytes_reads > 0" and we haven't read "num_bytes" yet. The darwin kernel has a INT32_MAX read size which gets set to MAX_READ_SIZE, but we need to do that because if you try to read more than that it reads nothing. So MAX_READ_SIZE is more for

Re: [lldb-dev] add custom vendor commands

> On Oct 18, 2016, at 7:48 AM, Giusti, Valentina > wrote: > > Hi Greg, > > Thanks a lot for your reply, please find below my answers. > >> You can install new python commands that can do the job to work out the >> details. >> >> http://lldb.llvm.org/python-reference.html >> >> See the secti

Re: [lldb-dev] lldb-mi stopped after '-target-select remote'

> On Oct 18, 2016, at 10:14 PM, Chunseok Lee via lldb-dev > wrote: > > I have noticed that lldb-mi stopped after executing "-target-select remote". > My execution step is like: > - > $ lldb-server g --platform=remote-linux "*:1234" > > $ lldb-mi > (g

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

I believe we are good, but it would be good to verify via testing once a compiler becomes available. Greg > On Oct 19, 2016, at 12:19 PM, Ted Woodward via lldb-dev > wrote: > > This might affect us. Do we handle it correctly? > > https://reviews.llvm.org/D16697 > > -- > Qualcomm Innovatio

Re: [lldb-dev] LLDB support for python scripts in ELF section, like .debug_gdb_scripts in GDB

We currently have the ability to support this for ELf. It is only currently hooked up for Mach-O binaries when you have a dSYM (stand alone debug info bundle). You will want to implement this for your platform: FileSpecList Platform::LocateExecutableScriptingResources(Target *target, Module &mod

Re: [lldb-dev] Returning multiple values in Python API function

> On Oct 21, 2016, at 1:03 PM, Francis Ricci via lldb-dev > wrote: > > Hi all, > > I'm looking to add Platform::LaunchGDBServer() to the SBPlatform API, > but it requires two return values - an lldb::pid_t and a string url. > Internally, we just pass by reference, but we can't do that in the >

Re: [lldb-dev] Returning multiple values in Python API function

The 'A' packet is for launching a process that is to be debugged only, it isn't supposed to be used just to launch a process that should just run. If the 'A' packet is being used in lldb-server in platform mode, then it is just wrong. We should probably pull it out of the server, or return an er

Re: [lldb-dev] Generating an event when calling SBThread::SetSelectedFrame and SBProcess::SetSelectedThreadByID

I agree with Jim here. If you are calling an API manually, I don't see a reason for a notification. A few ways to fix this: 1 - Add a SBBroadcaster to your code and then listen to it in your main event loop that is already listening to events. When you call SBProcess::SetSelectedThreadByID(), yo

Re: [lldb-dev] LLDB hang loading Linux core files from live processes (Bug 26322)

I think both are valid fixes. Threads in core files can have a non-zero signal. See comments below. > On Nov 11, 2016, at 5:36 AM, Howard Hellyer via lldb-dev > wrote: > > Hi Jim > > I was afraid someone would say that but I've done some digging and found a > difference in the core files I

Re: [lldb-dev] "image search-paths add" removes all breakpoints from remote server

If you call SetExecutableModule while a process is running, we probably need to ask the dynamic loader plug-in to update the loaded shared libraries. We might actually need to clear the dynamic loader and let the process load a new one since some dynamic loaders might use the executable to figur

Re: [lldb-dev] Refactoring in LLDB Windows Plugin

One thing that we have talked about is to move the ProcessWindows stuff into lldb-server (it has a NativeProcess and NativeThread class you would need to subclass instead of making ProcessWindows and ThreadWindows classes) instead of making a native plug-in that is only useful on the current sys

Re: [lldb-dev] Refactoring in LLDB Windows Plugin

> On Nov 29, 2016, at 10:16 PM, Zachary Turner wrote: > > What would it take to make it so that local and remote process plugins use > the same exact interface? I mean in theory they're doing the same thing, > just on a different machine. If they shared an identical interface then you > cou

Re: [lldb-dev] Refactoring in LLDB Windows Plugin

t; >> cheers, >> pl >> >> On 1 December 2016 at 07:57, Stephane Sezer via lldb-dev >> wrote: >>> >>> For what it's worth, we've been using lldb with ds2 to do remote >>> debugging on Windows (x86) and Windows Phone

Re: [lldb-dev] logging in lldb

The other problem with using streams is we need each log line to come out in a single chunk. So we somehow need to specify the start and end of a log. For example if two threads are doing: if (log) log->Printf("%i %i %i\n", x, y z); And we switch over to using: if (log) *log << 1 << ' ' <<

Re: [lldb-dev] logging in lldb

I like the the llvm::formatv stuff and could see using this exclusively. I am getting scared of using streams and << the more I think about it after my previous email since we would need to mark a log message as starting and ending somehow and that would make things messy. Note that our logging

Re: [lldb-dev] logging in lldb

> On Dec 6, 2016, at 10:20 AM, Pavel Labath wrote: > > On 6 December 2016 at 17:39, Jim Ingham wrote: >> >>> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote: >>> >>> Hello all, >>> >>> I've been thinking about how to simplify the way we do logging in >>> lldb. The main two problems I see are

Re: [lldb-dev] Shared Process plugin between Linux and BSD

I am wondering if it would be better to make a common base class, like NativeProcessPtrace, where all of the common Ptrace stuff lives and then subclass and override the functions that are different. There seemed to be a bunch of "#if defined(NETBSD)" stuff in the second patch. Without extra cod

Re: [lldb-dev] LLDB bare-metal and 'load' command

> On Dec 16, 2016, at 9:00 AM, Abid, Hafiz wrote: > > Hi Greg, > I was trying to do some bare-metal debugging with LLDB and an ARM board. I > noticed that > LLDB does not have a command similar to 'load' command of GDB. Searching the > mailing list, > it seems that this issue has been discusse

Re: [lldb-dev] LLDB bare-metal and 'load' command

> On Dec 16, 2016, at 2:29 PM, Abid, Hafiz wrote: > > > > Original message > From: Greg Clayton > Date: 16/12/2016 21:48 (GMT+00:00) > To: "Abid, Hafiz" > Cc: lldb-dev@lists.llvm.org > Subject: Re: LLDB bare-metal and 'load' command > > > > On Dec 16, 2016, at 9:00 AM, Ab

Re: [lldb-dev] LLDB bare-metal and 'load' command

> On Dec 19, 2016, at 4:33 AM, Abid, Hafiz wrote: > > > Hi Greg, I was trying to do some bare-metal debugging with LLDB and an ARM >> board. I noticed that LLDB does not have a command similar to 'load' command of GDB. >> Searching the mailing list, it seems that this issue

Re: [lldb-dev] LLDB failed to locate source when dwarf symbols are inside compile unit on Linux

Comments below. > On Jan 9, 2017, at 1:10 PM, Jeffrey Tan via lldb-dev > wrote: > > Hi, > > O ur company is using Buck(https://buckbuild.com/ ) > to build internal service. Recently the build team made a change in buck to > not merge dwarf symbols from each object fil

Re: [lldb-dev] LLDB failed to locate source when dwarf symbols are inside compile unit on Linux

In ELF files if there is a section named “.gnu_debuglink” it will contain a path to the external debug file. Dump this section and see what it contains. This section contains a null terminated C string as the path followed by a 4 byte aligned 32 bit integer which is a file CRC. Check to see the

Re: [lldb-dev] ELF header does not hold big modules

Found this on the web: e_shnum This member holds the number of entries in the section header table. Thus the product of e_shentsize and e_shnum gives the section header table's size in bytes. If a file has no section header table, e_shnum holds the value zero. If the number of

Re: [lldb-dev] Navigating STL types

You could add an explicit instantiation of your template for C++ types you need. Example without: #include #include int main (int argc, char const *argv[]) { std::vector ints = { 1,2,3,4 }; for (auto i: ints) printf("%i\n", i); return 0; } (lldb) target create "a.out" (lldb) b /a

Re: [lldb-dev] non-stop mode with lldb-mi?

Non-stop mode is a huge change to the core of LLDB isn’t it. I think you might think this is easier than it actually is to enable in LLDB? Is non-stop mode where you can leave some threads running while others are stopped? The biggest issue with this is to do it right we need to be able to emu

Re: [lldb-dev] RTTI does not work stable in LLDB.

You have found a bug. It should be reporting this correctly but it isn’t. I verified it fails on MacOSX. Greg Clayton > On Feb 5, 2017, at 1:19 PM, Roman Popov via lldb-dev > wrote: > > Hello, > I'm observing very strange LLDB behavior: it does not always shows a correct > dynamic type when

Re: [lldb-dev] RTTI does not work stable in LLDB.

I am looking at this now. I will let you know what I find. Greg > On Feb 6, 2017, at 10:00 AM, Roman Popov wrote: > > Yes, that was my thought. > > FYI, checked in GDB: it's working correctly on this testcase showing correct > dynamic type in both cases. > > 2017-02-06 9:48 GMT-08:00 Greg C

Re: [lldb-dev] RTTI does not work stable in LLDB.

the compiler here at Apple for the fix. Greg > On Feb 6, 2017, at 10:22 AM, Greg Clayton via lldb-dev > wrote: > > I am looking at this now. I will let you know what I find. > > Greg > >> On Feb 6, 2017, at 10:00 AM, Roman Popov > <mailto:ripo...@gmail.com&g

Re: [lldb-dev] RTTI does not work stable in LLDB.

pec does not really specify what the name > of a template instantiation should be, and in particular does not *want* to > specify whether it matches any given demangler's opinion of the name. > --paulr >   <> > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On

Re: [lldb-dev] RTTI does not work stable in LLDB.

x27;t the DWARF have a record for the VTable itself? I know PDB does, you > can look up the class name through the VTable debug info record rather than > trying to demangle the name. > > On Mon, Feb 6, 2017 at 2:21 PM Greg Clayton via lldb-dev > mailto:lldb-dev@lists.llvm.org>&

Re: [lldb-dev] RTTI does not work stable in LLDB.

> On Feb 6, 2017, at 3:38 PM, Robinson, Paul wrote: > > It's not practical for the DWARF to try to identify the actual address of the > vtable; that address might not be available. > it seems like we could hang onto the linkage_name of the vtable though, > somewhere, so you wouldn't be relying

Re: [lldb-dev] RTTI does not work stable in LLDB.

> On Feb 6, 2017, at 5:58 PM, Roman Popov wrote: > > Hello, > I just found out that sometimes I don't get correct dynamic type in LLDB even > if I compile with g++. How can I get typeinfo/vtable dump from LLDB to check > if it is still the same name matching issue? Stop where dynamic typi

Re: [lldb-dev] A typo on the "Testing LLDB" tutorial page?

Thanks for this, fixed with: % svn commit test.html Sendingtest.html Transmitting file data .done Committing transaction... Committed revision 294597. > On Feb 8, 2017, at 8:44 PM, Ramana via lldb-dev > wrote: > > On the "Testing LLDB" tutorial page, in the description under "RUNNING

Re: [lldb-dev] RTTI does not work stable in LLDB.

> On Feb 10, 2017, at 12:55 AM, Roman Popov wrote: > > Thanks Greg, > > So here is another case when LLDB fails to resolve dynamic type. Compiled > with G++5.4 on Ubuntu 16.04. > > Here I want to get dynamic type for some variable apb_memories > > (lldb) expr -d no-run -- apb_memories > (sc

Re: [lldb-dev] Why is function not present in target?

I believe if the function's visibility is hidden, then there is no need to create class methods that aren't used. I will check with our linker experts and get a more comprehensive reply for everyone later today. > On Feb 10, 2017, at 8:39 AM, Pavel Labath via lldb-dev > wrote: > > Interesting

Re: [lldb-dev] RTTI does not work stable in LLDB.

Roman, Thanks for verifying. I am trying to see how far this goes. It would be interesting to look at the GCC DWARF for this. If you can attach a copy of the binary, I would like to take a look to see if the DWARF itself has any offending type info where it sometimes has the 'u' and other times

Re: [lldb-dev] Python example does not work with latest LLDBs

The example code is: #!/usr/bin/python import lldb import os def disassemble_instructions(insts): for i in insts: print i # Set the path to the executable to debug exe = "./a.out" # Create a new debugger instance debugger = lldb.SBDebugger.Create() # When we step or continue, don'

Re: [lldb-dev] Python example does not work with latest LLDBs

I would be probably best to just step through it and see why it is incorrectly returning. We know it is broken. We should also add a test for this so we don't regress again. Greg > On Feb 13, 2017, at 10:19 AM, Roman Popov wrote: > > Yes Greg, this was my expectation that it should not return

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

Clang just doesn't currently know where to look for the standard headers. Not sure if this is a top level code only bug or not. I know the expression parser can include common C headers on Darwin. Not sure if any includes work on linux. Try importing and see how that goes? The better way to d

Re: [lldb-dev] Python example does not work with latest LLDBs

Works for me with top of tree: % PYTHONPATH=/tmp/lldb/build/Debug/LLDB.framework/Resources/Python ; ./foo.py ) Creating a target for './a.out' SBBreakpoint: id = 1, name = 'main', module = a.out, locations = 1 SBProcess: pid = 62855, state = stopped, threads = 1, executable = a.out thread #1: tid

<    1   2   3   4   5   6   7   >