search for: dsym

I am compiling the vlckit for IOS and besides a LOT of warnings, I got this and, as asked, am sending to you: 1 warning generated. rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory configure: WARNING: using cross tools not prefixed with host triplet rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory configure: WARNING: x86intrin.h: present but...

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 “debu...

>*nod* That's been the historic ELF+DWARF approach, but both MacOS (with dsyms+DWARF) and Windows >(COFF+CodeView+PDB) don't do it that way, and instead involve the linker to a degree. >Mostly I'm wondering if it'd be reasonable to (and if anyone would be interested in doing it) do >something more like the PDB support - fully debug-aware linking. Honest...

> On Oct 27, 2016, at 6:38 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Oct 27, 2016 at 5:39 PM, Maxime Chevalier-Boisvert via > llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hello, >> >> We’d like to keep track of which clang version was used to build our LLVM binaries. We use cmake and ninja with clang to build.

...ray.tart:103:11 ] > call _malloc ## Array.tart:103:11[ > Array.tart:103:11 ] > > > -- > -- Talin > Well, I figured out why the line numbers were getting set to -1: My "add_custom_command" directive in my CMake file which was supposed to run dsymutil was silently failing: add_custom_command( OUTPUT "${EXE_FILE}.dSYM/Contents/Resources/DWARF/${EXE_FILE}" COMMAND ${DSYMUTIL} "${EXE_FILE}" MAIN_DEPENDENCY "${EXE_FILE}" COMMENT "Generating debug symbols for ${EXE_FILE}")...

Is anybody testing mongrel on ruby 1.9. I just tried installing mongrel on trunk 1.9 and trunk rubygems and got this error compiling fastthread: /Users/stephen/dev/ruby/1.9_trunk/bin/ruby extconf.rb install mongrel --no-rdoc creating Makefile make gcc -I. -I/Users/stephen/dev/ruby/1.9_trunk/include/ruby-1.9/i686-darwin8.10.1 -I/Users/stephen/dev/ruby/1.9_trunk/include/ruby-1.9 -I.

(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: > >&gt...

...e paths to all the .o files used to create the image. This approach makes linking fast. Next, if you happen to run the program in the debugger, the debugger would see the debug notes and go read the .o files' dwarf information. Lastly, if you are making a release build, you run a tool called dsymutil on the final linked image. dsymutil finds the debug notes, parses the .o files' dwarf information then does all the computation to produce an optimal dwarf output file (we use a .dSYM extension). Later, if you need to debug a release build, you point the debugger at the .dSYM file. Per...

...vm-symbolizer/LLVMSymbolize.{h,cpp}), for instance: * dynamic dispatch between DWARF and PDB debug info; * building address->symbol_name mapping from object file (with special cases for PowerPC function descriptor section, and COFF export tables); * finding debug info stored in separate files (.dSYM files on Darwin, ELF .gnu_debuglink section, etc.); * demangling (with platform-specific implementations for Windows and Unix). I propose to move this code into a separate library LLVMSymbolize (stored under lib/DebugInfo/Symbolize), and make llvm-symbolizer a short and simple tool using it. This...

...oject.org/bin/macosx/el-capitan/contrib/3.4/PACKAGES contains Package: digest Version: 0.6.15 Title: Create Compact Hash Digests of R Objects Depends: R (>= 2.4.1) Suggests: knitr, rmarkdown Built: R 3.4.3; x86_64-apple-darwin15.6.0; 2018-01-29 05:21:06 UTC; unix Archs: digest.so.dSYM yet the _same directory_ only has: digest_0.6.14.tgz 15-Jan-2018 21:36 157K I presume this is a temporary accident. We are all spoiled by you all providing such a wonderfully robust and well-oiled service---so again big THANKS for that--but today something is out of order. Dirk -- http://d...

>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 it'd possibly have a big tradeoff in link time and/or linker memory usage (I'm not sure how much dsymutil needs/uses of either). +...

...e paths to all the .o files used to create the image. This approach makes linking fast. Next, if you happen to run the program in the debugger, the debugger would see the debug notes and go read the .o files' dwarf information. Lastly, if you are making a release build, you run a tool called dsymutil on the final linked image. dsymutil finds the debug notes, parses the .o files' dwarf information then does all the computation to produce an optimal dwarf output file (we use a .dSYM extension). Later, if you need to debug a release build, you point the debugger at the .dSYM file. This f...

...l that will tell you is that *something* failed - it > won't > tell you where or what. It's not so much like looking for a needle > in a > haystack - more like looking for a particular needle in a needlestack. You can also try running "dwarfdump --verify" on your dsymutil file (not on the dSYM bundle, but on the file inside the bundle). It sometimes gives a bit more information. Also simply using "dwarfdump - a" can be helpful to see wrong references (e.g., if the type info is structurally invalid then dwarfdump may simply stop dumping at that...

...t; > > > * dynamic dispatch between DWARF and PDB debug info; > > * building address->symbol_name mapping from object file (with special > cases > > for PowerPC function descriptor section, and COFF export tables); > > * finding debug info stored in separate files (.dSYM files on Darwin, ELF > > .gnu_debuglink section, etc.); > > * demangling (with platform-specific implementations for Windows and > Unix). > > > > I propose to move this code into a separate library LLVMSymbolize (stored > > under lib/DebugInfo/Symbolize), and make l...

...ntains > | > | Package: digest > | Version: 0.6.15 > | Title: Create Compact Hash Digests of R Objects > | Depends: R (>= 2.4.1) > | Suggests: knitr, rmarkdown > | Built: R 3.4.3; x86_64-apple-darwin15.6.0; 2018-01-29 05:21:06 UTC; unix > | Archs: digest.so.dSYM > | > | yet the _same directory_ only has: > | > | digest_0.6.14.tgz 15-Jan-2018 21:36 157K > | > | I presume this is a temporary accident. > | > | We are all spoiled by you all providing such a wonderfully robust and > | well-oiled service---so again big THANKS for...

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

...64 -L/usr/lib/ i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1 -L/ usr/lib/gcc/i686-apple-darwin10/4.2.1/../../../i686-apple- darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../.. - lSystem checking for dummy main to link with Fortran 77 libraries... rm: conftest.dSYM: is a directory none checking for Fortran 77 name-mangling scheme... configure: error: cannot compile a simple Fortran program See `config.log' for more details. Jeff-Hamanns-MacBook-Pro:R-2.9.1 hamannj Since this seems to be a 'fortran thing' methinks I should send this to Apple a...

...ion is used for loadable modules... .dylib checking which variable specifies run-time library path... DYLD_LIBRARY_PATH checking for the default library search path... /usr/local/lib /lib /usr/lib checking for objdir... .libs checking command to parse /usr/bin/nm output from object... rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory ok checking whether libtool supports -dlopen/-dlpreopen... yes checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen in -ldl... yes checking for dlerr...

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

...atch between DWARF and PDB debug info; >>> > * building address->symbol_name mapping from object file (with special >>> cases >>> > for PowerPC function descriptor section, and COFF export tables); >>> > * finding debug info stored in separate files (.dSYM files on Darwin, >>> ELF >>> > .gnu_debuglink section, etc.); >>> > * demangling (with platform-specific implementations for Windows and >>> Unix). >>> > >>> > I propose to move this code into a separate library LLVMSymbolize >&gt...