search for: beginmodule

...ious .cfi directives. The assemblers seem to be happy if the .cfi_sections directive precedes any other .cfi directive. Is this a bug in binutils or LLVM? It looks as if a fix might be to move the generation of the .cfi_sections directive from endModule() to somewhere else (maybe a non-existant beginModule()?). Could someone give me some hints about what the right approach might be? It looks as if the ARM code generator might need special handling also since it appears to emit the .cfi_sections directive itself. Thanks for any suggestions. -Rich

...gsignal + 53 4 libc.so.6 0x00007fa91cc3baf0 abort + 272 5 libc.so.6 0x00007fa91cc332df __assert_fail + 239 6 llc 0x0000000000ebfdad 7 llc 0x0000000000ebffa6 8 llc 0x0000000000ec2f7b 9 llc 0x0000000000eb95e0 llvm::DwarfWriter::BeginModule(llvm::Module*, llvm::MachineModuleInfo*, llvm::raw_ostream&, llvm::AsmPrinter*, llvm::TargetAsmInfo const*) + 166 10 llc 0x0000000000b9b513 11 llc 0x0000000001142c73 llvm::FPPassManager::doInitialization(llvm::Module&) + 65 12 llc 0x0000000001142...

...do CU-at-a-time DWARF emission to reduce memory > overhead. There's nothing in the design today that I know of that would > make CU-at-a-time DWARF emission anything other than trivial. We build all > the DIEs for a CU in one go, then move on to the next CU - the CU_Nodes > loop in beginModule does this. > In beginModule, we construct the CUs, but not all the DIEs that belong to the CU. In endFunction, we started to construct the scope DIEs. So in some sense, we are adding things to prior CUs. Looking at void CompileUnit::addDIEEntry(DIE *Die, uint16_t Attribute, DIE *Entry), we can...

...DWARF emission to reduce memory >> overhead. There's nothing in the design today that I know of that would >> make CU-at-a-time DWARF emission anything other than trivial. We build all >> the DIEs for a CU in one go, then move on to the next CU - the CU_Nodes >> loop in beginModule does this. >> > > In beginModule, we construct the CUs, but not all the DIEs that belong to > the CU. > In endFunction, we started to construct the scope DIEs. So in some sense, > we are adding things to prior CUs. > > Looking at void CompileUnit::addDIEEntry(DIE *Die, ui...

Hi Olaf, This patch looks good to me. I just have a few minor comments: > + inline df_iterator() { CurrentTopNode = 0; /* End is when stack is empty */ } Should the comment here be updated to say that the End is reached when the stack is empty and when CurrentTopNode is null? > + inline void toNext() > + { LLVM style puts the open brace on the same line as the function name.

...16, 2013 at 10:54 AM, Manman Ren <manman.ren at gmail.com>wrote: >>> >>>> >>>> >>>> >>>> On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com>wrote: >>>> >>>>> >>>>> In beginModule, we construct the CUs, but not all the DIEs that >>>>>>>> belong to the CU. >>>>>>>> In endFunction, we started to construct the scope DIEs. So in some >>>>>>>> sense, we are adding things to prior CUs. >>>>>>...

...to reduce memory >>> overhead. There's nothing in the design today that I know of that would >>> make CU-at-a-time DWARF emission anything other than trivial. We build all >>> the DIEs for a CU in one go, then move on to the next CU - the CU_Nodes >>> loop in beginModule does this. >>> >> >> In beginModule, we construct the CUs, but not all the DIEs that belong to >> the CU. >> In endFunction, we started to construct the scope DIEs. So in some sense, >> we are adding things to prior CUs. >> >> Looking at void Compi...

...t; >> >> On Wed, Oct 16, 2013 at 10:54 AM, Manman Ren <manman.ren at gmail.com>wrote: >> >>> >>> >>> >>> On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com>wrote: >>> >>>> >>>> In beginModule, we construct the CUs, but not all the DIEs that >>>>>>> belong to the CU. >>>>>>> In endFunction, we started to construct the scope DIEs. So in some >>>>>>> sense, we are adding things to prior CUs. >>>>>>> >&gt...

...iant one day when we do CU-at-a-time DWARF emission to reduce memory overhead. There's nothing in the design today that I know of that would make CU-at-a-time DWARF emission anything other than trivial. We build all the DIEs for a CU in one go, then move on to the next CU - the CU_Nodes loop in beginModule does this. > The CU constructing a DIE will add the DIE to the context owner, which may > not belong to the CU itself. > That's the question, isn't it? When is it ever /not/ the current CU under construction? > In the case that a DIE is added to an owner in DwarfDebug, I do...

Hi @clang and @llvm, attached you'll find a patch dealing with some iterator issues I already mentioned in both lists. Since there was no reaction I cross-post again - now IMHO production-ready code. The patch is considered to get checked-in out of the box. It should not affect the behavior of existing and working code. I really need it for clang AST processing. Changes: 1. Both

> In beginModule, we construct the CUs, but not all the DIEs that belong to >>> the CU. >>> In endFunction, we started to construct the scope DIEs. So in some >>> sense, we are adding things to prior CUs. >>> >>> Looking at void CompileUnit::addDIEEntry(DIE *Die, uint16_...

...ocation(RI->getFrameRegister(*Asm->MF)); + SPCU.addAddress(*SPDie, dwarf::DW_AT_frame_base, Location); + } // Add name to the name table, we do this here because we're guaranteed // to have concrete versions of our DW_TAG_subprogram nodes. @@ -751,6 +754,11 @@ void DwarfDebug::beginModule() { for (MDNode *N : CU_Nodes->operands()) { DICompileUnit CUNode(N); DwarfCompileUnit &CU = constructDwarfCompileUnit(CUNode); + DIArray SPs = CUNode.getSubprograms(); + for (unsigned i = 0, e = SPs.getNumElements(); i != e; ++i) + SPMap.insert(std::make_pair(SPs.get...

On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com> wrote: > > In beginModule, we construct the CUs, but not all the DIEs that belong >>>> to the CU. >>>> In endFunction, we started to construct the scope DIEs. So in some >>>> sense, we are adding things to prior CUs. >>>> >>>> Looking at void CompileUnit::addDIEEnt...

On Wed, Oct 16, 2013 at 10:54 AM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> In beginModule, we construct the CUs, but not all the DIEs that belong >>>>> to the CU. >>>>> In endFunction, we started to construct the scope DIEs. So in some >>>>> sense, we are adding things to prior CUs. >>>>> >>>>> Looking at void Co...

...laikie at gmail.com> wrote: > > > > On Wed, Oct 16, 2013 at 10:54 AM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com>wrote: >> >>> >>> In beginModule, we construct the CUs, but not all the DIEs that >>>>>> belong to the CU. >>>>>> In endFunction, we started to construct the scope DIEs. So in some >>>>>> sense, we are adding things to prior CUs. >>>>>> >>>>>&gt...

...do CU-at-a-time DWARF emission to reduce memory > overhead. There's nothing in the design today that I know of that would > make CU-at-a-time DWARF emission anything other than trivial. We build all > the DIEs for a CU in one go, then move on to the next CU - the CU_Nodes > loop in beginModule does this. > > >> The CU constructing a DIE will add the DIE to the context owner, which >> may not belong to the CU itself. >> > > That's the question, isn't it? When is it ever /not/ the current CU under > construction? > > >> In the case that...

...t; >> >> On Wed, Oct 16, 2013 at 10:54 AM, Manman Ren <manman.ren at gmail.com>wrote: >> >>> >>> >>> >>> On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com>wrote: >>> >>>> >>>> In beginModule, we construct the CUs, but not all the DIEs that >>>>>>> belong to the CU. >>>>>>> In endFunction, we started to construct the scope DIEs. So in some >>>>>>> sense, we are adding things to prior CUs. >>>>>>> >&gt...

On Tue, Oct 15, 2013 at 1:37 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Oct 15, 2013 at 1:22 PM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> On Tue, Oct 15, 2013 at 11:34 AM, David Blaikie <dblaikie at gmail.com>wrote: >> >>> >>> >>> >>> On Tue, Oct 15, 2013 at

On Tue, Oct 15, 2013 at 1:22 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Tue, Oct 15, 2013 at 11:34 AM, David Blaikie <dblaikie at gmail.com>wrote: > >> >> >> >> On Tue, Oct 15, 2013 at 10:51 AM, Manman Ren <manman.ren at gmail.com>wrote: >> >>> >>> >>> >>> On Tue, Oct 15, 2013 at