similar to: [LLVMdev] failure mode of invalid (debug info) metadata

Hi David, On 12/03/13 21:38, David Blaikie wrote: > Currently the debug info metadata handling is a bit loose - LLVM > accepts pretty much anything that looks roughly like the desired > schema & is lazily resilient to some differences (see, for example, > llvm::DIDescriptor::get*Field functions (lib/IR/DebugInfo.cpp:81)). > > I made some parts of debug info handling more

On Mon, Nov 18, 2013 at 10:37 AM, Chandler Carruth <chandlerc at google.com> wrote: > > On Mon, Nov 18, 2013 at 10:35 AM, Eric Christopher <echristo at gmail.com> > wrote: >> >> >> At a minimum, it seems like we need a version number in the debug info >> >> metadata so we can detect this situation and avoid crashing. >> > >> >

Hi all, Currently, debug info verifier is part of the IR verifier which is a function pass. One part of the IR verifier that I don't like is it verifies module-level data in doFinalization. If we have two verifier passes in a single module pass manager, doFinalization of the two passes will run on the same module data after all passes. I followed the same model for debug info verifier:

My off the cuff idea here is to make it a module pass, but we'll split the verification a bit: a) IR verification time - Verify debug metadata attached to instructions (i.e. line information). Only check it for structure (i.e. do the various metadata nodes have the right number and kind of operands). b) Module pass - Walk down from the CUs in the file and verify everything we see. I think

On Mon, Dec 16, 2013 at 4:05 PM, Eric Christopher <echristo at gmail.com>wrote: > My off the cuff idea here is to make it a module pass, but we'll split the > verification a bit: > > a) IR verification time - > > Verify debug metadata attached to instructions (i.e. line information). > Only check it for structure (i.e. do the various metadata nodes have the >

John Criswell wrote: > Zheng Wang wrote: >> Hello, >> >> Is there anyway to disable the module verifier pass (in llvm-ld and llc)? >> >> I got an error as " Instruction does not dominate all uses!". >> Obviously, there must be something wrong. The module verifier simply >> aborts `llvm-ld` instead of generating bytecode. If somehow I can

>> >> At a minimum, it seems like we need a version number in the debug info >> metadata so we can detect this situation and avoid crashing. > > > Or to put it in the terms of the IR: we need to autoupgrade the debug info > metadata just like we do intrinsics. With debug info this might (at the > worst) involve dropping old metadata. > The verifier is probably

On Mon, Nov 18, 2013 at 11:06 AM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Mon, Nov 18, 2013 at 10:55 AM, Eric Christopher <echristo at gmail.com> > wrote: >> >> On Sun, Nov 17, 2013 at 6:35 PM, Manman Ren <manman.ren at gmail.com> wrote: >> > Hi Bill, >> > >> > Thanks for the testing case. Most of the time is

Hello, Is there anyway to disable the module verifier pass (in llvm-ld and llc)? I got an error as " Instruction does not dominate all uses!". Obviously, there must be something wrong. The module verifier simply aborts `llvm-ld` instead of generating bytecode. If somehow I can disable the module verifier, then I can use llc to produce LLVM assembly code for my program. This will help

On Mon, Nov 18, 2013 at 10:35 AM, Eric Christopher <echristo at gmail.com>wrote: > >> At a minimum, it seems like we need a version number in the debug info > >> metadata so we can detect this situation and avoid crashing. > > > > > > Or to put it in the terms of the IR: we need to autoupgrade the debug > info > > metadata just like we do

Zheng Wang wrote: > Hello, > > Is there anyway to disable the module verifier pass (in llvm-ld and llc)? > > I got an error as " Instruction does not dominate all uses!". > Obviously, there must be something wrong. The module verifier simply > aborts `llvm-ld` instead of generating bytecode. If somehow I can > disable the module verifier, then I can use llc to

We had the same problem with verification when merging/linking 2 modules: a compile unit is not listed in named metadata (llvm.dbg.cu), We worked around this problem by using the DebugInfoFinder processModule function, which identifies all the compile units in the new module, by visiting all the subprogram scopes and the already available compile units. However, this succeeds verification only if

On Fri, Dec 23, 2016 at 11:04 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 23, 2016, at 9:34 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Thu, Dec 22, 2016 at 8:55 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> Hey, >> >> As I’m playing with Metadata lazy-loading, I added a verifier right

> On Dec 23, 2016, at 9:34 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Thu, Dec 22, 2016 at 8:55 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > Hey, > > As I’m playing with Metadata lazy-loading, I added a verifier right before running the IRLinker in FunctionImport.cpp, and it does not pass (on

Hi Seb, On 05/07/13 11:08, Sebastien DELDON-GNB wrote: > Hi all, > > Is there an easy way to check that debug metadata in a .ll file are well formed ? > > Thanks for you answers I don't think so. It would be great if the verifier checked debug and other standard meta data. Ciao, Duncan.

One problem that has been vexing me of late: It seems that whenever I run into a problem that requires debugging one of my programs in gdb, before I can do that I have to fix my frontend's broken generation of debugging info. The code that generates debugging information is quite fragile - you have to generate metadata for each of your files, classes, and functions, and do so without error,

Hi Bill, Thanks for the testing case. Most of the time is spent on debug info verifier. I fixed a bug in r194974, now it takes too long to run debug info verification. Debug info verifier is part of the verifier which is a Function Pass. Tot currently tries to pull all reachable debug info MDNodes in each function, which is too time-consuming. The correct fix seems to be separating debug info

On Sun, Nov 17, 2013 at 6:35 PM, Manman Ren <manman.ren at gmail.com> wrote: > Hi Bill, > > Thanks for the testing case. Most of the time is spent on debug info > verifier. > I fixed a bug in r194974, now it takes too long to run debug info > verification. > > Debug info verifier is part of the verifier which is a Function Pass. Tot > currently tries to pull all

On Mon, Nov 18, 2013 at 10:55 AM, Eric Christopher <echristo at gmail.com>wrote: > On Sun, Nov 17, 2013 at 6:35 PM, Manman Ren <manman.ren at gmail.com> wrote: > > Hi Bill, > > > > Thanks for the testing case. Most of the time is spent on debug info > > verifier. > > I fixed a bug in r194974, now it takes too long to run debug info > >

On Mon, Nov 18, 2013 at 10:45 AM, Eric Christopher <echristo at gmail.com>wrote: > On Mon, Nov 18, 2013 at 10:37 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > > > On Mon, Nov 18, 2013 at 10:35 AM, Eric Christopher <echristo at gmail.com> > > wrote: > >> > >> >> At a minimum, it seems like we need a version number in