search for: inghams

You'd probably need to pull the Unwinder in if you want backtraces, but that part shouldn't be that hard to disentangle. I don't think you'd need much else? Basing your work on NativeProcess rather than lldb proper would also cut the number of observer processes in half and avoid the context switches between the server and the debugger. That seems more appropriate for a

On 04/03/2020 21:45, Jim Ingham via llvm-dev wrote: > As you have seen, different machine architectures do different things after hitting a trap. On x86_64, the trap instruction is executed, and then you stop, so the PC is left after the stop. On arm64, when execution halts the pc is still pointing at the trap instruction. > > I don't think lldb should be in the business of telling

Hi LLVM Developer Team, My name is Mark Babatunde and I'm a third year computer science student at the University of Pittsburgh. I was looking at the potential list of projects and the project regarding adding support for batch-testing to the LLDB testsuite caught my interest. I was wondering how I can get started and if I can get in contact with Jim Ingham. Best, Mark Mark Babatunde

no expression parser or knowledge of any specific programming language. Basically I just mean that the parsing of the native DWARF format itself is in scope, but anything beyond that is out of scope. For symbolication we have things like llvm-symbolizer that already just work and are built on top of LLVM's dwarf parsing code. Similarly, LLDB's type system could be built on top of it as

On Wed, May 22, 2013 at 8:33 PM, Charles Davis <cdavis5x at gmail.com> wrote: > > On May 22, 2013, at 5:14 PM, Eric Christopher wrote: > > > Hi All, > > > > Can anyone see good a reason not to move to cmake as our only build > > configuration system and drop future support for autoconf + makefiles > > now that 3.3 has branched? > +1. > - CMake

On May 22, 2013, at 5:14 PM, Eric Christopher wrote: > Hi All, > > Can anyone see good a reason not to move to cmake as our only build > configuration system and drop future support for autoconf + makefiles > now that 3.3 has branched? I can think of several: - When the Clang CMakefiles go to build compiler-rt (if present), they use the compiler used to build Clang and not the

...6 1 4 1 311 2 2 10 got principal=NONE Got challenge flags: Got NTLMSSP neg_flags=0x60890215 NTLMSSP: Set final flags: Got NTLMSSP neg_flags=0x60080215 NTLMSSP Sign/Seal - Initialising with flags: Got NTLMSSP neg_flags=0x60080215 SPNEGO login failed: Logon failure Anonymous login successful Domain=[INGHAMS] OS=[Unix] Server=[Samba 3.0.11] Sharename Type Comment --------- ---- ------- netlogon Disk Network Logon Service print$ Disk Printer Drivers Share pub Disk IPC$ IPC...

This is Greg's area, he'll be able to answer in detail how the name chopper gets used. IIRC it chops demangled names, so it is indirectly a client of the demangler, but it doesn't use the demangler to do this directly. Name lookup is done by finding all the base name matches, then comparing the context. We don't do a very good job of doing fuzzy full name matches - for instance

Hi, I'm noticing an unexpected difference between targets when I hit a dbgtrap in the debugger. Consider this simple llvm function: define void @do_break() { entry: call void @llvm.debugtrap() ret void } If I compile that with llc and use lldb to launch a program that calls it, on x86_64 linux (Ubuntu 18.04), here's what I see at the stop: Process 130404 stopped * thread #1,

> On Jun 15, 2018, at 9:23 AM, <paul.robinson at sony.com> <paul.robinson at sony.com> wrote: > >> From: Greg Clayton [mailto:clayborg at gmail.com] >> >> ... >> If a class has templated functions, they will only be in the DWARF is a >> specialization was created and used. If you have a class that looks like: >> >> class A { >>

It is interesting that the stop reason on the thread that stopped is "trace". That's what you would expect returning from the single-step to step over the breakpoint. But it looks like we got a signal while single-stepping, but the stop reason was misreported by somebody. Jim > On Apr 17, 2018, at 6:00 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote:

Hi All, I fear starting another centi-thread on this but I'll give it a shot. We're currently supporting two build systems which is definitely one more than we (or I) want to support. I don't know of any support in autoconf past the --host/--build/--target case that's not supported in cmake. I'll send out an assertion here that this support isn't necessary and any system

> On Jun 15, 2018, at 10:40 AM, <paul.robinson at sony.com> <paul.robinson at sony.com> wrote: > > > >> -----Original Message----- >> From: Greg Clayton [mailto:clayborg at gmail.com <mailto:clayborg at gmail.com>] >> Sent: Friday, June 15, 2018 12:46 PM >> To: Robinson, Paul >> Cc: labath at google.com <mailto:labath at

Hi all, We have been thinking internally about a lightweight llvm-based ptracer. To address one question up front: the primary way in which this differs from LLDB is that it targets a more narrow use case -- there is no scripting support, no clang integration, no dynamic extensibility, no support for running jitted code in the target, and no user interface. We have several use cases internally

On Tue, Jun 26, 2018 at 1:28 PM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Jun 26, 2018, at 11:58 AM, Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi all, > > > > We have been thinking internally about a lightweight llvm-based > ptracer. To address one question up front: the primary way in which this

I am trying to apply some settings to a printer shared by Samba, including installing the drivers. I notice that I must be in printer admin or be root in order to do this, and I am. The logs say that I'm "logged in as admin user (root privileges)" which I assume is correct. I go into properties, click no when it asks me if I want to install drivers, and then go to New Driver and

In response to my own posting regarding being able to upload printer drivers but not being allowed to apply any settings ("Access Denied") with no obvious error in the logs, I have fixed it. All I did was copy the ntprinters.tdb from another Samba server, and it appears to work now. Not an ideal fix but it will have to do. I tried other versions of Samba but the problem persisted on