search for: bozier

On 21 July 2015 at 09:34, Dave Bozier <seifsta at gmail.com> wrote: > Sounds reasonable. The sstrip tool that performs stripping of the > section header does state that this makes shared libraries unsuitable > for static linking. From the documentation: > >> A shared-object library stripped in this fashion will...

...re appears to be chat about replacing it with the fast demangler implementation in LLDB. Could you please advise if we should put our contributing efforts into enhancing the fast demangler in LLDB so that it can replace the existing one or just work on what is already there. Regards, David Bozier Technical lead of linker and binutils SN Systems - Sony Interactive Entertainment http://www.snsystems.com https://twitter.com/SNSystemsEU -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161215/b057fa22/attac...

Sent from my iPhone > On Jan 26, 2016, at 7:40 AM, Dave Bozier via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > There is some eh_frame section parsing going on in the linker which is > required for .eh_frame_hdr creation and probably useful for dead-frame > elimination in the future. I think there's 2 linker parsers (a macho one and...

...ous so I went ahead and resubmitted Pete’s original change. So far no buildbot failures, looks promising. On 26 January 2016 at 09:19, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Sent from my iPhone On Jan 26, 2016, at 7:40 AM, Dave Bozier via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: It would be great if there was a single parser used by all llvm tools. Absolutely. We'll get to that stage, I hope. We'll need to work out if there's a way to abstract what we need from each...

On Fri, May 15, 2015 at 5:11 AM, Dave Bozier <seifsta at gmail.com> wrote: > > Are you sure about the additional I/O? With native symtab, existing > tools just need to read those, while plugin based approach needs to read > bit code section to feedback symbols to the tool. > > The additional I/O will be quite big if y...

> On Dec 15, 2016, at 6:18 AM, Dave Bozier via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > > We’re hoping to replace the demangler in some of our tools to use the LLVM demangler. We’d like to enhance it with missing functionality (legal names that it cannot demangle) and provide a set of tests that...

Hi, > Scenario 1: you added -fuse-ld=lld to your command line, but you are suspecting that the option is ignored. Currently, it's actually surprisingly hard to tell if an output was created by LLD. Can't you use -v to see what linker the compiler driver invoked? On Wed, Oct 19, 2016 at 4:41 AM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Tue, Oct 18,

Hi all, Not so long ago we have found ourselves in need of a robust _eh_frame parser. All we wanted is the ability to parse .eh_frame section emitted by LLVM's MCJIT. Considering this, LLVM would be a natural place for implementing such parser. Previous email thread about the issue (https://groups.google.com/forum/#!topic/llvm-dev/Vb_VYU7Eo0k) showed some interest among the community. Folks

On Tue, Oct 18, 2016 at 8:22 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Oct 18, 2016, at 6:44 PM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I'd like to make LLD embed version information so that we can determine > if an executable was created by LLD and if that's the case which version of > LLD. >

...with byte code with debug is about 3%. More importantly, it is also possible to use the symtab also for index/summary purpose, which makes the space usage completely 'unwasted'. That gets into the details which will follow when patches are in. David On Fri, May 15, 2015 at 5:11 AM, Dave Bozier <seifsta at gmail.com> wrote: > > Are you sure about the additional I/O? With native symtab, existing > tools just need to read those, while plugin based approach needs to read > bit code section to feedback symbols to the tool. > > The additional I/O will be quite big if y...

On Wed, Jun 3, 2015 at 4:19 AM, Dave Bozier <seifsta at gmail.com> wrote: > Hi Teresa, > > Thanks for providing this updated RFC. > >> For Sony's linker, are you using the gold plugin or libLTO interfaces? >> If the latter, I suppose some ThinLTO handling would have to be added >> to your linker (e.g....

Most ELF shared libraries can be sliced in two ways. One is following the information in the program headers (e_phoff). The other is following the information in the section headers (e_shoff). Regular relocatable objects only have the section header. At runtime, the dynamic linker only uses the program headers. In fact, the section headers is optional. When given a shared library, how should

...%. > > More importantly, it is also possible to use the symtab also for > index/summary purpose, which makes the space usage completely 'unwasted'. > That gets into the details which will follow when patches are in. > > David > > On Fri, May 15, 2015 at 5:11 AM, Dave Bozier <seifsta at gmail.com> wrote: > >> > Are you sure about the additional I/O? With native symtab, existing >> tools just need to read those, while plugin based approach needs to read >> bit code section to feedback symbols to the tool. >> >> The additional I/...

Hi Andrew, LLD relies on various bits of global state which are manipulated during the link, so I wouldn't expect it to be thread safe at that level, although it does attempt to reset that global state at the start of each call to link(), so it should be callable sequentially. Regards, James On 25 July 2018 at 02:37, Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote:

On Thu, May 14, 2015 at 2:09 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Thu, May 14, 2015 at 1:35 PM Teresa Johnson <tejohnson at google.com> > wrote: > >> On Thu, May 14, 2015 at 1:18 PM, Eric Christopher <echristo at gmail.com> >> wrote: >> > >> > >> > On Thu, May 14, 2015 at 1:11 PM David Blaikie

On Fri, May 29, 2015 at 6:56 AM, Alex Rosenberg <alexr at leftfield.org> wrote: > My earlier statement about wrapping things in a native object file held in that it is controversial. It appears to be still central to your design. > > It may help to look at the problem from a different viewpoint: LLVM is not a compiler. It is a framework that can be used to make compiler-like tools.