similar to: [LLD] Should --compress_debug_sections be enabled (=zlib) by default ?

Hi, Alexei On 2015/7/30 1:13, Alexei Starovoitov wrote: > On 7/29/15 2:38 AM, He Kuang wrote: >> Hi, Alexei >> >> On 2015/7/28 10:18, Alexei Starovoitov wrote: >>> On 7/25/15 3:04 AM, He Kuang wrote: >>>> I noticed that for 64-bit elf format, the reloc sections have >>>> 'Addend' in the entry, but there's no 'Addend' info

Hello, I'm having problems updating from 7.3 to 7.4 on my ppc64 (IBM Power7 p770) installation. yum update stops with Error: Multilib version problems found. [..] Protected multilib versions: systemd-libs-219-42.el7.ppc != systemd-libs-219-42.el7_4.1.ppc64 When I scroll back through the transaction check I see various package dependencies for *.ppc instead of *.ppc64. First appearance in

Yep. This worked. Thanks! Why yum can't figure this out itself? On Mon, Sep 18, 2017 at 3:29 PM, Johnny Hughes <johnny at centos.org> wrote: > On 09/18/2017 08:18 AM, Armin Kunaschik wrote: >> Hello, >> >> I'm having problems updating from 7.3 to 7.4 on my ppc64 (IBM Power7 >> p770) installation. >> yum update stops with >> Error: Multilib

> Le 3 oct. 2017 à 00:09, Rui Ueyama <ruiu at google.com> a écrit : > > I read through the binutils mailing list thread, but I couldn't find the exact reason why making --hash-style=gnu default except MIPS wasn't a good idea.Do you mind if I ask you to explain it again for me? > > Since lld is a new linker, we could make a bit more radical change than GNU ld can do,

Le 2 oct. 2017 à 18:37, Rui Ueyama <ruiu at google.com<mailto:ruiu at google.com>> a écrit : Changing default to "both" is probably fine, but what does that change actually mean in practice? I believe clang already passes --hash-style=both to the linker by default. Not exactly. The current Linux driver (I haven't checked other ELF-based systems) reads this

Em Tue, Feb 25, 2014 at 10:52:02PM +1030, Rusty Russell escreveu: > Borislav Petkov <bp at suse.de> writes: > > On Tue, Feb 25, 2014 at 12:09:23PM +1030, Rusty Russell wrote: > >> Should we get more ambitious and start a fake-kernel/ directory where > >> we can put userspace equivs/stubs of kernel functionality? > > > > Dunno - people like to do that

Em Tue, Feb 25, 2014 at 10:52:02PM +1030, Rusty Russell escreveu: > Borislav Petkov <bp at suse.de> writes: > > On Tue, Feb 25, 2014 at 12:09:23PM +1030, Rusty Russell wrote: > >> Should we get more ambitious and start a fake-kernel/ directory where > >> we can put userspace equivs/stubs of kernel functionality? > > > > Dunno - people like to do that

I personally haven't tried gdb_index, and I don't know the quality of the produced index. Most of the code was written by George. One thing I noticed about the feature (and filed as http://bugs.llvm.org/show_bug.cgi?id=32228) is that our gdb_index feature is much slower than the gold. Apparently there's room for improvement. On Thu, Mar 16, 2017 at 8:35 AM, David Blaikie <dblaikie

What program did you use to test the feature, and what was missing information? I'd like to file that as a bug so that we can fix this later. On Thu, Mar 16, 2017 at 2:34 PM, David Blaikie <dblaikie at gmail.com> wrote: > FWIW - selfhosting I did find that GDB wasn't able to find the source code > for some functions when using LLD's gdb_index, so I've switched back to

Hello, I'm taking 7.4 for a spin.? I did the minimal install, and ran into trouble with groupinstall base.? The trouble seems to stem from elfutils.? One command claims elfutils-libs-0.166-2.el7.x86_64 is missing, and another one claims it's installed.? Not sure what's going on here. [root at ip-172-31-34-187 ~]# yum -y install elfutils.x86_64 Loaded plugins: fastestmirror

>FWIW - selfhosting I did find that GDB wasn't able to find the source code >for some functions when using LLD's gdb_index, so I've switched back to >gold+gdb_index for now (given the performance problems you mentioned, >sounds like I wasn't gaining much/anything in terms of link time by using >lld anyway). > >On Thu, Mar 16, 2017 at 11:17 AM Rui Ueyama

Sorry if this is the wrong list, but doing a code checkout via Mercurial produces the following: #hg clone http://xenbits.xensource.com/xen-3.2-testing.hg destination directory: xen-3.2-testing.hg requesting all changes adding changesets abort: could not import module ELFCLASS32! transaction abort! rollback completed Is there a workaround for this right now? -- Joe Auty NetMusician: web

On Thu, Apr 10, 2014 at 07:38:05PM +0200, Borislav Petkov wrote: > Rebased onto current acme/perf/core: > > -- > From: Borislav Petkov <bp at suse.de> > Date: Sun, 23 Feb 2014 12:04:53 +0100 > Subject: [PATCH] tools: Unify export.h > > So tools/ has been growing three, at a different stage of their > development export.h headers and so we should unite into one.

On Thu, Apr 10, 2014 at 07:38:05PM +0200, Borislav Petkov wrote: > Rebased onto current acme/perf/core: > > -- > From: Borislav Petkov <bp at suse.de> > Date: Sun, 23 Feb 2014 12:04:53 +0100 > Subject: [PATCH] tools: Unify export.h > > So tools/ has been growing three, at a different stage of their > development export.h headers and so we should unite into one.

hey guys, One of our developers DESTROYED both yum and rpm on one of the development machines with an rm command. And guess who's lucky enough to get to fix this mess? *raises hand* So I hope y'all don't mind me turning to you once again for some advice. You've been wonderful in the past. Pavlov's dogs as they say. At any rate, I've managed to fix rpm (yay) by copying

hi everyone just a quickie to devel maybe. I'm looking at some bits: devtoolset-4-elfutils-libelf-0.163-2.el7.x86_64 VS elfutils-0.166-2.el7.x86_64 isn't devtool ageing? Could this be the case with more packages? regards, L.

Hi all, LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for production use at least for x86-64 (and probably for AArch64 and MIPS). I believe you've heard a few good news about the linker -- it just works <http://lld.llvm.org/#features> and is very fast <http://lld.llvm.org/#performance>, clean, compact and supported by the active community. I don't think I need to

I just noticed this, which doesn't actually seem to affect anything but does create a mystery: [frankcox at mutt temp]$ cat test.c #include <stdio.h> int main(void) { printf("Hello world\n"); return 0; } [frankcox at mutt temp]$ gcc -o test test.c [frankcox at mutt temp]$ file test test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared

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 debug info size and accelerate debug info processing.

The package elfutils-debuginfod-client is needed for even a minimal install, but it is not available on most mirrors. I suspect some are excluding mirroring debuginfo packages with just a *debuginfo* pattern to rsync, where they should do something like *-debuginfo-*.rpm (which should be good for now as I don't see any package with just "debuginfo" in the name, even in Fedora). The