search for: seifsta

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 still be usa...

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 you are going...

...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 you are going...

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

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. to invoke th...

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

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.