similar to: StarFaxCoverSheet

Hi llvm-dev@, This is a proposal for LLVM to adopt Sony's Dexter tool [0], import it into the debuginfo-tests repo, and use it to run integration tests between debuggers and clang/llvms debuginfo. (Sony has approved donating Dexter to LLVM). Background ---------- The debuginfo-tests repo contains an integration test suite for debug data, which builds each test case from its source code

Good day! I'm trying to run CwSkimmer (http://www.dxatlas.com/CwSkimmer/) with wine 1.0 Installation was finished, but the program drops dialog with this error: Code: For security purposes, this program will not run while system debuggers are active. Please remove or disable the system debugger before trying to run this program again. What I have to do to let application think that

Another example would be .debug_pubnames and .debug_pubtypes sections. Currently these default to omitted for Darwin and PS4, but included everywhere else. My initial patch for "tuning" changes the PS4 platform criterion to the SCE debugger predicate; quite likely the "not Darwin" criterion ought to be "not LLDB" or in other words "on for GDB only."

> On May 1, 2015, at 2:18 PM, Greg Clayton <gclayton at apple.com> wrote: > > >> On May 1, 2015, at 2:00 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: >> >>> A few more things that vote for debugger tuning: >>> >>> - LLDB doesn't like to have DWARF that has a class A that inherits from >>> class B, but

> A few more things that vote for debugger tuning: > > - LLDB doesn't like to have DWARF that has a class A that inherits from > class B, but only a forward declaration of class B is provided. Hmm do we emit that kind of thing today? In a naïve test, I'm seeing the full description of class B. > - LLDB wants the .apple_XXX accelerator tables, GDB wants >

On 18 October 2012 02:53, Robinson, Paul <Paul.Robinson at am.sony.com> wrote: > I had a "quality suite" at a previous job; it was the result of many PY > of effort. It was also debugger-based, which is a mixed blessing; you > get a lot of DWARF-parsing code for free, but then you get a lot of > debugger bugs for free too! And you don't get to test the DWARF >

> On May 5, 2015, at 8:12 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, May 5, 2015 at 4:04 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > > > On May 1, 2015, at 2:18 PM, Greg Clayton <gclayton at apple.com <mailto:gclayton at apple.com>> wrote: > > > > > >> On May 1,

This is basically a reboot of the previous thread titled About the "debugger target" except that "target" was really too strong a term for what I had intended to use this feature for. "Debugger tuning" is more like it. You don't need to have read the previous thread, I'll recap here. Fundamentally, Clang/LLVM uses DWARF as the specification for the

I just skimmed through the thread again, and I *think* all the main questions have been answered… It feels like the consensus is "reluctant agreement," with the specific design points being: - a "debugger tuning" option would have some sort of target-based default - the "debugger tuning" option would unpack into defaults for individual feature flags -

Renato Golin wrote: > On 18 October 2012 02:53, Robinson, Paul <Paul.Robinson at am.sony.com> wrote: > > I had a "quality suite" at a previous job; it was the result of many PY > > of effort. It was also debugger-based, which is a mixed blessing; you > > get a lot of DWARF-parsing code for free, but then you get a lot of > > debugger bugs for free too!

I've bought my 12 yr old son a used laptop (Dell Latitude D600) and convinced him to use a version of linux unstead of Windows. The laptop came with PCLinuxOS release 2007. He really wants to be able to run some of his games, so I used the Synaptic Package Manager to install Wine. The version available for PCLinuxOS was Wine 0.9.58. So far I've tried two games, and I've struck out

I don’t think there was a driver patch so far, was there? -- adrian > On May 6, 2015, at 1:19 PM, Eric Christopher <echristo at gmail.com> wrote: > > Does the patch do all of this? > > -eric > > On Wed, May 6, 2015 at 1:18 PM Robinson, Paul <Paul_Robinson at playstation.sony.com <mailto:Paul_Robinson at playstation.sony.com>> wrote: > I just skimmed

In some cases we do want to make the decision based on the target. For Hexagon, we don't support GDB anymore, only LLDB, so we always want LLDB tuning. The clang driver should have a way to specify that. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -----Original Message----- From:

Hi llvm-dev@, There's been some renewed interest in integration tests for debuginfo, checking that debuggers interpret LLVMs output in the way we expect. Paul suggested a while back [0] that our (Sony's) Dexter [1] tool could be a useful driver for running debuginfo tests -- I'd like to ask whether people think this would be desirable course to take, and what the requirements for

Comments on the patch raise the following questions, probably better discussed here. First: Should LLVM default to "no tuning" rather than a target-specific default? There are two natural follow-up questions: What would "no tuning" actually mean? Where would the target-specific defaulting occur? I originally came down against the "no tuning" option, in favor of the

Rick Foos wrote: > The error we are getting is: > “Undefined Form Value: 25” > ... > DW_FORM_flag_present caused the problem. The old DW_FORM_flag works for us. I see this error from GDB 7.0 but GDB 7.2 is okay with it. Now you know as much as I do. :-) Eric Christopher wrote: > [in reply to what Renato Golin wrote:] > > With time, you might get to a point where Dwarf is a

> -----Original Message----- > From: Daniel Berlin [mailto:dberlin at dberlin.org] > Sent: Friday, May 01, 2015 3:15 PM > To: Robinson, Paul > Cc: cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM Developers > Mailing List (llvmdev at cs.uiuc.edu); lldb-dev at cs.uiuc.edu > Subject: Re: [LLVMdev] What does "debugger tuning" mean? > > On Fri, May

> > This reflects the compiler's view of things correctly, but is problematic > for a debugger. The debugger should know that arg_arr refers to a 42-element > array and isn't just a pointer into a buffer of unspecified length. This is > something the user would expect. > > On the other hand, the debugger should also get the information that > arg_arr is actually a

Hi all, As you may know modern C++ debuggers (GDB and LLDB) support dynamic type identification for polymorphic objects, by utilizing C++ RTTI. Unfortunately this feature does not work with Clang and GDB >= 7.x . The last compiler that worked well was G++ 6.x I've asked about this issue both on GDB and LLDB maillists. Unfortunately it's hard or impossible to fix it on debugger side.

On 15 July 2011 06:35, Eli Bendersky <eliben at gmail.com> wrote: > >> > This reflects the compiler's view of things correctly, but is >> > problematic for a debugger. The debugger should know that arg_arr refers to >> > a 42-element array and isn't just a pointer into a buffer of unspecified >> > length. This is something the user would expect.