search for: dwarfemitter

...same personality > function (EH gurus, correct me if I'm wrong) > > Note that since only x86 generates correct exception tables (that I > know > of), you can only test this on x86. > > Let me know what you think about it. > > Nicolas > Index: include/llvm/CodeGen/DwarfEmitter.h > =================================================================== > --- include/llvm/CodeGen/DwarfEmitter.h (revision 0) > +++ include/llvm/CodeGen/DwarfEmitter.h (revision 0) > @@ -0,0 +1,167 @@ > +//===------- llvm/CodeGen/DwarfEmitter.h - Dwarf emission ------- > *- C++...

Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

...ails. >> +// >> +// >> ===------------------------------------------------------------------- >> ---===// >> +// >> +// >> ===------------------------------------------------------------------- >> ---===// >> + >> +#ifndef LLVM_CODEGEN_DWARFEMITTER_H >> +#define LLVM_CODEGEN_DWARFEMITTER_H >> + >> +#include "llvm/Support/DataTypes.h" >> +#include <string> >> +#include <vector> >> + >> +namespace llvm { >> + >> +class Function; >> +class MachineCodeEmitter; >&...

...he --gc-debuginfo option is off by default. So it would affect only those who need it and explicitly specified it. I think the current DWARFLinker code could be optimized more to improve performance results. 2. Support of type units. That could be implemented further. 3. DWARF5. Current DWARFEmitter/DWARFStreamer has an implementation for DWARF generation, which does not support DWARF5(only debug_names table). At the same time, there already exists code in CodeGen/AsmPrinter/DwarfDebug.h, which implements most of DWARF5. It seems that DWARFEmitter/DWARFStreamer should be rewritten using DwarfD...

...accelerator tables can improve the debugging experience as debuggers don't need to manually index all of the debug info during debugging. Looking at how accelerator tables are currently emitted, they seem to be built up as DWARF is being created or linked, and then emitted using a subclass of DWARFEmitter. The only subclass if this right now that I see is one in dsymutil which ends up emitting everything using an AsmPrinter by eventually emitAppleAccelTable(...) from llvm/include/llvm/CodeGen/AccelTable.h. I spoke briefly with Shoaib on this subject and he suggested adding code to llvm-objcopy. I b...

On Fri, Feb 5, 2016 at 5:56 PM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On Feb 5, 2016, at 5:53 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Fri, Feb 5, 2016 at 5:51 PM Mehdi Amini via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> > On Feb 5, 2016, at 5:40 PM, Peter Collingbourne

...s these tables available since dsymutil already creates either Apple or DWARF accelerator tables. COFF and Wasm can come later. > >> Looking at how accelerator tables are currently emitted, they seem to be built up as DWARF is being created or linked, and then emitted using a subclass of DWARFEmitter. The only subclass if this right now that I see is one in dsymutil which ends up emitting everything using an AsmPrinter by eventually emitAppleAccelTable(...) from llvm/include/llvm/CodeGen/AccelTable.h. >> >> I spoke briefly with Shoaib on this subject and he suggested adding code to...

...le and only knows about label names, not label addresses. > IMO the > refactoring is non-trivial. > >>> >> I am not sure if it makes sense for this to maintain it's own >> buffers. Can it be modified to use MachineCodeEmitter? >> >> > > You mean DwarfEmitter inherits MachineCodeEmitter? There are > MachineCodeEmitter functions that are really not related to > MachineCodeEmitter (eg addRelocation, getConstantPoolEntryAddress, > etc). How about just passing it a ptr to a MachineCodeEmitter object? > > Again, I've sent you the patch...

Hello, Johannes > Oh, I forgot to say that I use -g -O0. I do get debug info, but no > line number information. Stuff like which function is where etc. is > all there. There are some known issues with debug/eh info on mingw32. Some of them (especially eh-related) will require DwarfEmitter refactoring and this is my todo list. > .file 1 "main.c" > .loc 1 4 0 > in there, while llvm-gcc has nothing. Line numbering is implemented, however llvm-gcc does not use .loc assembler directives to emit line numbering information - it does this directly, thus f...

I'm building a cross-gcc with target i386-mingw32msvc, running on Mac OS X 10.5.2. While it compiles and works fine and dandy, I don't seem to get any sensible debug output regarding lines/position in my program. Running the executables produced by the cross-compiler in gdb, I get full symbols in backtraces, but "the program doesn't contain any line number

...lable since > dsymutil already creates either Apple or DWARF accelerator tables. COFF and > Wasm can come later. > > > Looking at how accelerator tables are currently emitted, they seem to be > built up as DWARF is being created or linked, and then emitted using a > subclass of DWARFEmitter. The only subclass if this right now that I see is > one in dsymutil which ends up emitting everything using an AsmPrinter by > eventually emitAppleAccelTable(...) from > llvm/include/llvm/CodeGen/AccelTable.h. > > I spoke briefly with Shoaib on this subject and he suggested adding c...

...l already creates either Apple or DWARF accelerator tables. COFF and >> Wasm can come later. >> >> >> Looking at how accelerator tables are currently emitted, they seem to be >> built up as DWARF is being created or linked, and then emitted using a >> subclass of DWARFEmitter. The only subclass if this right now that I see is >> one in dsymutil which ends up emitting everything using an AsmPrinter by >> eventually emitAppleAccelTable(...) from >> llvm/include/llvm/CodeGen/AccelTable.h. >> >> I spoke briefly with Shoaib on this subject and h...

...mments, please find my answers below... > > On 06.08.2020 20:39, Jonas Devlieghere wrote: > > Hi Alexey, > > I should've looked at this earlier. I went through the thread again and I've > made some comments, mostly from the dsymutil point of view. > > > Current DWARFEmitter/DWARFStreamer has an implementation for DWARF > > generation, which does not support DWARF5(only debug_names table). At the > > same time, there already exists code in CodeGen/AsmPrinter/DwarfDebug.h, > > which implements most of DWARF5. It seems that DWARFEmitter/DWARFStreamer &g...

...Apple or DWARF accelerator tables. COFF and >>> Wasm can come later. >>> >>> >>> Looking at how accelerator tables are currently emitted, they seem to be >>> built up as DWARF is being created or linked, and then emitted using a >>> subclass of DWARFEmitter. The only subclass if this right now that I see is >>> one in dsymutil which ends up emitting everything using an AsmPrinter by >>> eventually emitAppleAccelTable(...) from >>> llvm/include/llvm/CodeGen/AccelTable.h. >>> >>> I spoke briefly with Shoaib o...

Hi Alexey, I should've looked at this earlier. I went through the thread again and I've made some comments, mostly from the dsymutil point of view. > Current DWARFEmitter/DWARFStreamer has an implementation for DWARF > generation, which does not support DWARF5(only debug_names table). At the > same time, there already exists code in CodeGen/AsmPrinter/DwarfDebug.h, > which implements most of DWARF5. It seems that DWARFEmitter/DWARFStreamer > should be re...

Hi Eric, please On 31.07.2020 22:02, Eric Christopher wrote: > Hi Alexey, > > On Fri, Jul 31, 2020 at 4:02 AM Alexey Lapshin via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > On 28.07.2020 19:28, David Blaikie wrote: > > On Tue, Jul 28, 2020 at 8:55 AM Alexey Lapshin > <avl.lapshin at gmail.com