search for: emitgendwarfarang

> On 2014-Jul-15, at 09:38, David Blaikie <dblaikie at gmail.com> wrote: > > On Tue, Jul 15, 2014 at 9:31 AM, Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: >> >>> On 2014-Jul-15, at 08:29, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> Sounds pretty clearly buggy, and against the original design of the

...e same (excluding tests), so >> if this is ever the "right" approach, it might still be worth it. > > After attempting, this gets a bit more insidious and (perhaps > unsurprisingly) my estimate turned out to be rather optimistic. > > (for the record, it gets ugly in EmitGenDwarfAranges which currently > computes the length ahead of time (so, it does things like take the > length of the ranges collection - so if we leave dead entries in there > it'd have to iterate through to count, for example - or just use a > label difference)) > > If you're happy t...

...ts. > > I agree, in it`s current state it would be less work to write separate implementation > than reusing CodeGen variants. The bad thing is that in such a case there is a lot of > code duplication: > > DwarfStreamer::emitUnitRangesEntries > DwarfDebug::emitDebugARanges > EmitGenDwarfAranges > DWARFYAML::emitDebugAranges Probably some opportunities to share some code, even if not the whole generator - might be best to refactor those opportunistically, rather than a wholesale "change DWARFLinker to use (all) of lib/CodeGen/AsmPrinter/Dwarf*". Sort of like the approach th...

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