search for: dsyms

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

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

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

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

On Sat, Aug 28, 2010 at 10:58 PM, Talin <viridia at gmail.com> wrote: > On Sat, Aug 28, 2010 at 4:05 PM, Talin <viridia at gmail.com> wrote: > >> On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote: >> >>> >>> On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: >>> >>>> I

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

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

Hi, We have a lot of non-trivial logic accumulated in the implementation of llvm-symbolizer tool (tools/llvm-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

I have received three distinct (non-)bug reports where someone claimed a recent package of mine was broken ... simply because the macOS binary was not there. Is there something wrong with the cronjob providing the indices? Why is it pointing people to binaries that do not exist? Concretely, file https://cloud.r-project.org/bin/macosx/el-capitan/contrib/3.4/PACKAGES contains Package:

>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 01 Sep 2010, at 08:47, Talin wrote: > Once again, I have no idea what this means or how to go about > debugging it. > This is my biggest frustration with DIFactory - there's absolutely > no way to > verify that the DWARF debugging information that I've emitted into > my module > is correct or even sensible. The only way to test it is to try and > debug

To create unit tests is a pretty good reason IMO :) That said, I'd be a fan of trying to encapsulate all of this behind an interface. I like that most of the tools are exceptionally light weight and it makes it much more obvious what's "wrapper" versus "functionality" in something like llvm-symbolize. That said, I'll be interested to see the library design :)

Dirk, yes, thanks, the edge server that serves the Mac binaries to CRAN has run out of disk space (due to size of CRAN itself) so the sync was incomplete. It is fixed now -- you can try by using the macos master server as mirror: https://r.research.att.com/ and it will propagate through other mirrors as usual. Thanks, Simon > On Jan 31, 2018, at 1:34 PM, Dirk Eddelbuettel <edd at

On Mon, Feb 29, 2016 at 3:36 PM, Adrian Prantl <aprantl at apple.com> wrote: > > On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > Just in case it interests anyone else, I'm playing around with trying to > broaden the MCStreamer API to allow for emission of bytes without copying > the contents into a local buffer first (either because

I hope this is the place for this... I have to rebuild from scratch under Snow Leopard, and when I attempted to build R-2.9.1, I get the following results from ./ configure: checking how to get verbose linking output from fc... configure: WARNING: compilation failed checking for Fortran 77 libraries of fc... checking how to get verbose linking output from gcc -std=gnu99... -v checking for

Current llvm release 2.8 branch at r115409 is broken on x86_64-apple-darwin10. #!/bin/bash -ev export LD=`xcode-select -print-path`/usr/bin/ld xcode-select -print-path ulimit -s `ulimit -s` ulimit -s mv ../clang-2.8 ./tools/clang mkdir ../llvm_objdir cd ../llvm_objdir ../llvm-2.8/configure --prefix=/sw --prefix=/sw --mandir=/sw/share/man --infodir=/sw/share/info --with-gmp=/sw

> 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

On Wed, Oct 21, 2015 at 12:17 PM Alexey Samsonov <vonosmas at gmail.com> wrote: > We have out-of-tree implementation of llvm-symbolizer-as-a-library, and I > still hope to upstream it one day (unfortunately, its build process is > really complicated). > > Mike can probably comment on his plans for using symbolization in > coverage-related tools. > > On Wed, Oct 21,