similar to: [LLVMdev] Reimplementing Darwin's dsymutil as an lld helper

> On Nov 7, 2014, at 9:20 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > > Hi Fred, > > Could this tool be extended to read DWARF information in the final image and then pack it differently for other architectures as well ? I guess it could, depending on what you exactly mean by “pack it differently”. It could certainly strip some parts, or merge it with other

(oops, switch mailing list) On Tue, Nov 17, 2015 at 4:07 PM, David Blaikie <dblaikie at gmail.com> wrote: > Wee, delayed response, but nothing drastic: > > I just noticed the tool is "llvm-dsymutil" but it's in tools/dsymutil, > unlike all the other tools that have the llvm-prefix in the directory name. > Could we move it to "tools/llvm-dsymutil" for

> On Nov 7, 2014, at 10:07 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > > Thanks for your reply, Fred. > > It might work better, if its in a form of an API. So that the linker could call an API instead of running a tool ? Yes, the long term goal would be to expose it as an API. The separate tool is just a first step. I can’t give you the exact shape of the API

Hi,   We propose llvm-dwarfutil - a dsymutil-like tool for ELF.   Any thoughts on this?   Thanks in advance, Alexey. ====================================================================== llvm-dwarfutil(Apndx A) - is a tool that is used for processing debug info(DWARF) located in built binary files to improve debug info quality, reduce debug info size and accelerate debug info processing.

On 26.08.2020 10:58, James Henderson wrote: > In principle, this sounds reasonable to me. I don't know enough about > dsymutil's interface to know whether it makes sense to try to make it > multi-format compatible or not. If it doesn't I'm perfectly happy for > a new tool to be added using the DWARFLinker library. > > Some more general thoughts: > 1)

Hi James, Thank you for the comments. >I think we're not terribly far from that ideal, now, for ELF. Maybe only these three things need to be done? -- >  1. Teach lld how to emit a separated debuginfo output file directly, without requiring an objcopy step. >  2. Integrate DWARFLinker into lld. >  3. Create a new tool which takes the separated debuginfo and DWO/DWP files

On 03.09.2020 01:36, David Blaikie wrote: > > > On Wed, Sep 2, 2020 at 3:26 PM Alexey <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > > On 02.09.2020 21:44, David Blaikie wrote: >> >> >> On Wed, Sep 2, 2020 at 9:56 AM Alexey <avl.lapshin at gmail.com >> <mailto:avl.lapshin at gmail.com>>

On 01.09.2020 06:27, David Blaikie wrote: > A quick note: The feature as currently proposed sounds like it's an > exact match for 'dwz'? Is there any benefit to this over the existing > dwz project? Is it different in some ways I'm not aware of? (I haven't > actually used dwz, so I might have some mistaken ideas about how it > should work) > > If

On 02.09.2020 21:44, David Blaikie wrote: > > > On Wed, Sep 2, 2020 at 9:56 AM Alexey <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > > On 01.09.2020 20:07, David Blaikie wrote: >> Fair enough - thanks for clarifying the differences! (I'd still >> lean a bit towards this being dwz-esque, as you say "an

On 01.09.2020 20:07, David Blaikie wrote: > Fair enough - thanks for clarifying the differences! (I'd still lean a > bit towards this being dwz-esque, as you say "an extension of classic dwz" I doubt a little about "llvm-dwz" since it might confuse people who would expect exactly the same behavior. But if we think of it as "an extension of classic dwz" and

Is there/could you further explain the use-case for adding an index to an existing binary? Certainly not the worst idea/could come in handy sometimes, but you mention benchmarking - is the benefit of not recompiling/relinking that significant to such experiments? If it's not for use in a common workflow, but only in a compiler/debugger development workflow, it doesn't seem so important to

On Oct 30, 2012, at 11:10 AM, Shankar Easwaran wrote: >>> >>> 3) How are you planning to support Atom specific flags ? Is there a way already ? >>> (This would be needed to group similiar atoms together) >> It is still an open question how to support platform specific Atom attributes. As much as possible we'd like to expand the Atom model to be a superset

On Tue, Sep 24, 2019 at 11:22 PM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Alexay, > > Thank you for the detailed explanation. The other question I have is, as > discussed above, about dsymutil. You said that dsymutil is not usable at > link-time. What does that mean? If we only have to emit an output file in > the usual way and then automatically

>If you're interested in things you can do in the linker for this - you might consider something more aggressive: Fully DWARF aware deduplication. > >This could be done hopefully by reusing some of the code in the dsymutil implementation in LLVM. > >This would be much more effective (and without the possible context-sensitive tradeoffs) than using type units. >Though

Hi Nick, Thanks for your reply. How about if the atom flags could be overridden ? The Atom flag could have a MIN/MAX and anything above the MAX or lower than the MIN are platform specific, like how its dealt with section indexes ? > I know ELF file format has some ranges for various values that are specifically reserved for processors or "user" defined functionality. It serves the

>On Mon, Jun 22, 2020 at 7:21 AM Alexey Lapshin ><alapshin at accesssoftek.com> wrote: >> >> >> >> >> >> This idea goes in another direction than fragmenting dwarf >> >> >> using elf sections&tricks. It seems to me that the cost of fragmenting is too high. >> >> >> >> >I tend to agree - but I'm

On 28.07.2020 10:29, David Blaikie via llvm-dev wrote: > On Fri, Jun 26, 2020 at 9:28 AM Alexey Lapshin > <alapshin at accesssoftek.com> wrote: >> >>>>>>>>>> This idea goes in another direction than fragmenting dwarf >>>>>>>>>> using elf sections&tricks. It seems to me that the cost of fragmenting is too high.

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

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

>> >> >> >> This idea goes in another direction than fragmenting dwarf >> >> >> >> using elf sections&tricks. It seems to me that the cost of fragmenting is too high. >> >> >> >> >> >> >I tend to agree - but I'm sort of leaning towards trying to use object >> >> >> >features as much