similar to: [LLVMdev] Fix for forward-declare-class.cpp in debuginfo-tests

Hi, Please could someone kindly review this patch for me? Many thanks Andy On Wednesday, July 18, 2012 9:15 AM, Andy Gibbs wrote: > Hi, > > I'm not sure where to post this since it relates to the "debuginfo-tests" > repository, so please tell me where to forward it if this is the wrong > place! > > I've fixed the forward-declare-class.cpp test-case in

On Tuesday, July 31, 2012 7:19 PM, Andy Gibbs wrote: > I'm afraid it looks like commit r160899 has broken two test-cases > which are part of the "debuginfo-tests" repository. I believe I > have narrowed it down to the correct commit... Erm, but I didn't post the details (obviously too much in a rush to get home last night! My apologies!) So here it is: The tests that

Hi, I'm afraid it looks like commit r160899 has broken two test-cases which are part of the "debuginfo-tests" repository. I believe I have narrowed it down to the correct commit... Cheers Andy

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

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

Greetings, If you dont' care about running debuginfo-tests, and don't maintain a bot that runs debuginfo-tests, you can stop reading. I've uploaded a patch [https://reviews.llvm.org/D39605] that changes the way you run debuginfo-tests. Prior to this patch, the way to run them is to clone an external git repository into clang/test and then debuginfo-tests will happen transparently

Hi all, Could we branch llvm's debuginfo-tests project for releases [1]? This project contains useful debugging integration tests. It's currently not possible to run these tests against anything older than trunk, so we end up losing some valuable test coverage when we branch. (I'm not suggesting that we include the source of this project in official releases, just that we create a

cmake -G Ninja -DLLVM_ENABLE_PROJECTS="debuginfo-tests" -DLLVM_USE_LINKER=lld -DCMAKE_BUILD_TYPE="Release" -DLLVM_TARGETS_TO_BUILD=X86 -Wno-dev ../llvm &> ../../cmake.log in cmake.log -- Targeting X86 CMake Error at /home/nnelson/Documents/llvm-project/debuginfo-tests/CMakeLists.txt:30 (message):   Cannot run debuginfo-tests without python 3 installed python3

llvm-profdata is part of llvm though. It’s perfectly fine for something in clang to depend on something in llvm. However, clang and lld are two independent llvm subprojects, neither of which can depend on each other. Generally speaking, from a layering perspective, if A depends on B and C, but B and C are independent, that should be reflected in the structure. For example, in CMake we will need

> On Sep 7, 2017, at 11:37 AM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > To be clear, the tests I'm proposing will have no resemblance whatsoever to GDB, so I would be intentionally forking the set of tests in this regards. So there would very clearly be a paradigm shift in writing CodeView debug info tests (which would be written in JavaScript using

Yes I can reproduce this locally. It looks like we are not passing an -isysroot (pointing to the SDK) to clang but it isn’t clear what lit magic would expand this. -- adrian > On Nov 13, 2017, at 3:30 PM, Zachary Turner <zturner at google.com> wrote: > > Yea I'm preparing a revert right now. Does it happen for you when you run debuginfo-tests locally? > > On Mon, Nov

Since this is causing all of our internal CI to back up, could you please revert your two changes, so we can make sure that they were actually responsible, and can work on a fix for this? Let me know how we can help investigate this. -- adrian > On Nov 13, 2017, at 3:25 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The first build where a test fails with

Hi list, I found relevant documentation regarding DebugInfo creation in the LLVM IR bytecode. It can be done for compileunits, functions, and other constructs, with the help of DIBuilder class. However I can't save debug information related to individual llvm::Instructions. I tried DebugLoc, DILocation setting directly with setMetadata(). I tried other ways, for e.g.:

Yea I also just found it. Try adding this code in the bottom of debuginfo-tests/lit.cfg.py lit.util.usePlatformSdkOnDarwin(config, lit_config) On Mon, Nov 13, 2017 at 4:38 PM Adrian Prantl <aprantl at apple.com> wrote: > Ha! Found it. *Somebody* is setting an SDKROOT variable in the > environment. Can you find the code that would do this? > > — adrian > > > On Nov

IIUC you are mainly wanting to test LLD's PDB generation. Obviously a test suite plugged in under clang/test is not a good fit for that. It could arguably fit into the LLD project, but separating it out as a more end-to-end integration project a-la test-suite seems like a much better idea. Moving debuginfo-tests seems like a way to get a project in place with the right layering and maybe

As executable tests, they fail spectacularly in a cross-build environment. And you need some sort of debugger with GDB-like commands and output (or have some front end to your debugger that imitates that) in order to run them. I think they would need to stay in a separate project because of those requirements. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David

Great! It's close to the end of the day, so I'll submit tomorrow to make sure everything has a chance to go fully green again to ensure I get failure emails if it breaks. On Mon, Nov 13, 2017 at 4:43 PM Adrian Prantl <aprantl at apple.com> wrote: > I can confirm that that fixes the issue! > > — adrian > > > On Nov 13, 2017, at 4:38 PM, Zachary Turner <zturner

Hi Zackary, Did you see my followup to you cfe-commits rollback: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171120/210212.html I think you can just remove the change to cfe/trunk/test/CMakeLists.txt and it should work just fine. hth... don On Tue, Nov 21, 2017 at 12:00 PM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Just an update, > > At

Hi, Even though I am not running a centos.plus kernel yum wants to install the kernel-debuginfo for it. # yum install --disablerepo=\* --enablerepo=base-debuginfo kernel-debuginfo Loaded plugins: fastestmirror, refresh-packagekit Setting up Install Process Loading mirror speeds from cached hostfile Resolving Dependencies --> Running transaction check ---> Package kernel-debuginfo.x86_64

On the other hand this file hasn't changed recently, but I have no way to test this as it uses the LLDB code path, which only runs on OSX. On Mon, Nov 13, 2017 at 3:19 PM Zachary Turner <zturner at google.com> wrote: > I might be missing something, but this doesn't look like me? > > >