search for: dsymutil

(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 consistency? > > On Fri, Nov 7, 2014 at 8:09 AM, Frédéric Riss <friss at apple.com> wrote: > >> Hi...

Hi, [ I Cc'd lld people and debug info people. Apologies if I omitted some stakeholder. ] As stated in the subject, I’d like to start working on an in-tree reimplementation of Darwin’s dsymutil utility. This is an initial step on the path to having lld handle the debug information itself. For those who are not familiar with the debug flow on MacOS, dsymutil is a DWARF linker. Darwin’s linker (ld64) doesn’t link the DWARF debug info found in the object files, instead it writes a “debug-ma...

Trying to run make to build llvm, I faced the following error: Linking CXX shared library ../../lib/libLTO.so collect2: error: ld returned 1 exit status make[2]: *** [lib/libLTO.so.3.8.0svn] Error 1 make[1]: *** [tools/lto/CMakeFiles/LTO.dir/all] Error 2 make: *** [all] Error 2 So, what's the problem here? Regards, Marwa Yusuf Teaching Assistant - Computer Engineering Department

...efer > invocation of pxdb until the first debug session, set LD_PXDB to > /bin/true. > > </snip> > > Few questions :- > > a) Will the utility understand that the linker garbage collected few functions and the utility not create map for it ? Yes. It’s not dsymutil that creates the map though. It’s the linker that emit the map, and the map tells dsymutil that some atoms aren’t present in the linked binary (in fact the map won’t mention these at all and that’s how the utility knows that they have been dropped). > b) How will it work with LTO ? With LTO you...

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) Assuming the proposal is accepted, this shou...

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 d...

...would expect exactly the same behavior. But if we think of it as "an extension of classic dwz" and the possible confusion is not a big deal then I would be fine with "llvm-dwz". > using a bit more domain knowledge (of terminators and C++ odr - though > I'm not sure dsymutil does rely on the ODR, does it? It relies on it > to know that two names represent the same type, I suppose, but doesn't > assume they're already identical, instead it merges their members)) if dsymutil is able to find a full definition then it would remove all other definitions(wh...

...> But if we think of it as "an extension of classic dwz" and the > possible confusion is not a big deal then > I would be fine with "llvm-dwz". >> using a bit more domain knowledge (of terminators and C++ odr - >> though I'm not sure dsymutil does rely on the ODR, does it? It >> relies on it to know that two names represent the same type, I >> suppose, but doesn't assume they're already identical, instead it >> merges their members)) > > if dsymutil is able to find a full definition then i...

...maybe that could be taught to use DwarfLinker as a library to > optionally do DWARF-aware linking depending on the users time/space > tradeoff desires. Still benefiting from any improvements to the > underlying DwarfLinker library (at which point that would be shared > between llvm-dsymutil, llvm-dwz, and llvm-dwp). > > On Tue, Aug 25, 2020 at 7:29 AM Alexey <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > Hi, > >    We propose llvm-dwarfutil - a dsymutil-like tool for ELF. >    Any thoughts on this? >   ...

...uot;linking with a few extra steps". > > But to check that these changes might be more generally applicable, I > thought I'd solicit data from anyone building tools that might be memory > constrained as well. > > First that comes to mind (Eric suggested/mentioned) is llvm-dsymutil. > > Adrian/Fred - do you guys ever have trouble with memory usage of > llvm-dsymutil? Do you have an example you could provide that has high > memory usage, so I could see if any simple changes based on my prototype MC > changes would help. > > > Since dsymutil processes ob...

...as "an extension of classic dwz" and >> the possible confusion is not a big deal then >> I would be fine with "llvm-dwz". >>> using a bit more domain knowledge (of terminators and C++ >>> odr - though I'm not sure dsymutil does rely on the ODR, >>> does it? It relies on it to know that two names represent >>> the same type, I suppose, but doesn't assume they're already >>> identical, instead it merges their members)) >> >> if dsymutil is a...

...xtra steps". >> >> But to check that these changes might be more generally applicable, I >> thought I'd solicit data from anyone building tools that might be memory >> constrained as well. >> >> First that comes to mind (Eric suggested/mentioned) is llvm-dsymutil. >> >> Adrian/Fred - do you guys ever have trouble with memory usage of >> llvm-dsymutil? Do you have an example you could provide that has high >> memory usage, so I could see if any simple changes based on my prototype MC >> changes would help. >> >> >...

...ing with a few extra steps". >> >> But to check that these changes might be more generally applicable, I thought I'd solicit data from anyone building tools that might be memory constrained as well. >> >> First that comes to mind (Eric suggested/mentioned) is llvm-dsymutil. >> >> Adrian/Fred - do you guys ever have trouble with memory usage of llvm-dsymutil? Do you have an example you could provide that has high memory usage, so I could see if any simple changes based on my prototype MC changes would help. > > Since dsymutil processes object file...

...n/llc] Error 254 CMakeFiles/Makefile2:22024: recipe for target 'tools/llc/CMakeFiles/llc.dir/all' failed make[1]: *** [tools/llc/CMakeFiles/llc.dir/all] Error 2 clang: error: unable to execute command: Killed clang: error: linker command failed due to signal (use -v to see invocation) tools/dsymutil/CMakeFiles/dsymutil.dir/build.make:476: recipe for target 'bin/dsymutil' failed make[2]: *** [bin/dsymutil] Error 254 CMakeFiles/Makefile2:21803: recipe for target 'tools/dsymutil/CMakeFiles/dsymutil.dir/all' failed make[1]: *** [tools/dsymutil/CMakeFiles/dsymutil.dir/all] Error 2 c...

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 DW...

...dwp, looks very much like "linking with a few extra steps". But to check that these changes might be more generally applicable, I thought I'd solicit data from anyone building tools that might be memory constrained as well. First that comes to mind (Eric suggested/mentioned) is llvm-dsymutil. Adrian/Fred - do you guys ever have trouble with memory usage of llvm-dsymutil? Do you have an example you could provide that has high memory usage, so I could see if any simple changes based on my prototype MC changes would help. A quick glance at dsymutil's code indicates it might benefit...

...xtra steps". >>> >>> But to check that these changes might be more generally applicable, I thought I'd solicit data from anyone building tools that might be memory constrained as well. >>> >>> First that comes to mind (Eric suggested/mentioned) is llvm-dsymutil. >>> >>> Adrian/Fred - do you guys ever have trouble with memory usage of llvm-dsymutil? Do you have an example you could provide that has high memory usage, so I could see if any simple changes based on my prototype MC changes would help. >> >> Since dsymutil proce...

...e for target > 'tools/llc/CMakeFiles/llc.dir/all' failed > > make[1]: *** [tools/llc/CMakeFiles/llc.dir/all] Error 2 > > clang: error: unable to execute command: Killed > > clang: error: linker command failed due to signal (use -v to see > invocation) > > tools/dsymutil/CMakeFiles/dsymutil.dir/build.make:476: recipe for target > 'bin/dsymutil' failed > > make[2]: *** [bin/dsymutil] Error 254 > > CMakeFiles/Makefile2:21803: recipe for target > 'tools/dsymutil/CMakeFiles/dsymutil.dir/all' failed > > make[1]: *** [tools/dsymuti...

...; > On Mar 2, 2020, at 3:44 PM, Eric Christopher <echristo at gmail.com> wrote: > > I'd like it... Adrian? Fred? > > -eric > > On Mon, Mar 2, 2020 at 3:44 PM Greg Clayton <clayborg at gmail.com> wrote: > >> Yes. I am fine with adding ELF support to llvm-dsymutil if that is the >> way people think we should go? >> > Feels like a bit of a weird fit to me (equally llvm-objcopy seems like a weird fit too) - given the specific name & nature of Darwin debug info distribution being a bit different (reading object files, having input from the li...

...able to read fragmented DWARF, > >>>>>>>>>>>> but applied to linked executable it should work with > non-fragmented DWARF). > >>>>>>>>>>>> That idea is for the tool which works the same way as > dsymutil ODR. > >>>>>>>>>>>> > >>>>>>>>>>>> I will shortly describe the idea of making DWARF be > easier processed by dsymutil/DWARFLinker: > >>>>>>>>>>>> > >>...