Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions
The binutils and gdb projects do not even pretend to a stable ABI or API for libbfd and libopcodes. Particularly not ABI, that gets broken on almost every week. perf and other projects that want to use libbfd or libopcodes are of course welcome to do so, but they then need to deal with the changing API. Complaints that Nick, Alan, or H.J. Lu have broken perf or similar *will be ignored*, except possibly to tell you that you may as well stop complaining. I've said before that the most obvious way to deal with the unstable API is to import a snapshot of the libbfd and libopcodes code into those projects and merge from upstream as new upstream support becomes desirable. That's not hard to do! -- Alan Modra Australia Development Lab, IBM
Bug#880627: polyml: FTBFS on hppa - error linking poly
Source: polyml Version: 5.7 Severity: normal On Thu, Nov 02, 2017 at 08:47:30AM -0400, John David Anglin wrote: > On 2017-11-02, at 3:59 AM, Alan Modra wrote: > > Even when this has been worked around by the binutils change, polyml > > still fails to build. > > > > echo "use \"/home/amodra/src/polyml/modules/IntInfAsInt/ROOT.sml\";" | > > ../../poly -q -error-exit > > Segmentation fault > > I'm not seeing this fault. I just redid a polyml build with virgin source > and I didn't see the segmentation fault. > > gcc version 7.2.1 20171025 (Debian 7.2.0-12) > > dave@mx3210:~/debian/polyml/polyml-5.7$ as --version > GNU assembler (GNU Binutils) 2.29.51.20171031 > > Binutils was trunk with your elf32-hppa.c patch. Yes, but that patch hasn't been committed yet. What's more, binutils-2.28 and binutils-2.29 both fail with a segfault (after working around the OS/ABI problem). I suspect older binutils will show the same thing. In one of my earlier emails to you Dave, I misdiagnosed the segfault as being due to binutils commit d336fa6d82. That wasn't true. > > Some debugging shows this is due to a NULL function pointer, traceable > > back to this relocation in polyexport.o > > > > 0134 1301 R_PARISC_DIR32 PolyProcessEnvGeneral + 0 > > > > That's also an ABI violation. Function pointers on hppa32 require > > plabel relocations. > > No, that's not correct. Calls using function pointers are done using > $$dyncall or equivalent. It checks > the plabel bit to determine whether or not the call is direct or via an > function descriptor. Direct calls > work when a new PIC register value isn't needed. I'll defer to you on whether it is an ABI violation. It's been quite a while since I've done any serious parisc work.. The fact remains that this part of the ABI isn't currently supported by any released binutils as far as I know. -- Alan Modra Australia Development Lab, IBM
Bug#880023: polyml: FTBFS on hppa - error linking poly
On Sat, 28 Oct 2017 10:51:01 -0400 John David Anglin wrote: > Source: polyml > Version: 5.7 > Severity: normal > > Dear Maintainer, > > Build fails here: > > Making STRUCT_CONVERSIONALS > Created functor STRUCT_CONVERSIONALS > Created structure StructConversionals > Created structure CInterface > /bin/bash ./libtool --tag=CC --mode=link gcc -Wall -fno-strict-aliasing > -g -O2 -fdebug-prefix-map=/<>=. -Wformat -Werror=format-security > -Wl,--as-needed -o poly polyexport.o libpolymain/libpolymain.la > libpolyml/libpolyml.la -lpthread -lffi -lm -ldl -lstdc++ -lgcc_s -lgcc > libtool: link: gcc -Wall -fno-strict-aliasing -g -O2 > -fdebug-prefix-map=/<>=. -Wformat -Werror=format-security > -Wl,--as-needed -o .libs/poly polyexport.o libpolymain/.libs/libpolymain.a > libpolyml/.libs/libpolyml.so -lpthread -lffi -lm -ldl -lstdc++ -lgcc_s -lgcc > /usr/bin/ld: BFD (GNU Binutils for Debian) 2.29.1 internal error, aborting at > ../../bfd/elf32-hppa.c:4054 in elf32_hppa_relocate_section > > /usr/bin/ld: Please report this bug. > > collect2: error: ld returned 1 exit status > Makefile:588: recipe for target 'poly' failed > > Full build log is here: > https://buildd.debian.org/status/fetch.php?pkg=polyml&arch=hppa&ver=5.7-2&stamp=1507223380&raw=0 > > The error was reported to binutils: > https://sourceware.org/bugzilla/show_bug.cgi?id=22300 > > See "bug 1: polyimport, the producer of polyexport.o is using the wrong > os/abi for hppa-linux." in comment 4. > > The binutils part of this bug should now be fixed by commit > c0e331c794d6bd75d9be9bea6145513074c33f39. Even when this has been worked around by the binutils change, polyml still fails to build. echo "use \"/home/amodra/src/polyml/modules/IntInfAsInt/ROOT.sml\";" | ../../poly -q -error-exit Segmentation fault Some debugging shows this is due to a NULL function pointer, traceable back to this relocation in polyexport.o 0134 1301 R_PARISC_DIR32 PolyProcessEnvGeneral + 0 That's also an ABI violation. Function pointers on hppa32 require plabel relocations. $ cat funcp.c extern void foo(void); void (*fp)(void) = foo; $ hppa-linux-gcc -O -c -save-temps funcp.c $ cat funcp.s .LEVEL 1.1 .globl fp .section.data.rel,"aw",@progbits .align 4 .type fp, @object .size fp, 4 fp: .word P%foo .ident "GCC: (GNU) 8.0.0 20171018 (experimental)" .section.note.GNU-stack,"",@progbits $ readelf -r funcp.o Relocation section '.rela.data.rel' at offset 0xfc contains 1 entries: Offset InfoTypeSym.Value Sym. Name + Addend 0841 R_PARISC_PLABEL32 foo + 0 -- Alan Modra Australia Development Lab, IBM
Bug#749060: [PATCH] [klibc] ppc64: ELFv2: Load TOC value in system call stub
On Tue, Sep 09, 2014 at 07:17:19PM -0300, Mauricio Faria de Oliveira wrote:
> usr/klibc/arch/ppc64/sysstub.ph |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/usr/klibc/arch/ppc64/sysstub.ph b/usr/klibc/arch/ppc64/sysstub.ph
> index b3f6e38..a0c6d41 100644
> --- a/usr/klibc/arch/ppc64/sysstub.ph
> +++ b/usr/klibc/arch/ppc64/sysstub.ph
> @@ -18,6 +18,9 @@ sub make_sysstub($@) {
> #if _CALL_ELF == 2
> .type ${fname},\@function
> ${fname}:
> +0: addis 2,12,(.TOC.-0b)\@ha
> + addi2,2,(.TOC.-0b)\@l
> + .localentry ${fname},.-${fname}
> #else
> .section ".opd","aw"
> .balign 8
> --
> 1.7.1
Looks good.
--
Alan Modra
Australia Development Lab, IBM
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#617633: klibc: Install static binaries on ppc64
On Wed, Mar 16, 2011 at 11:24:54PM +0100, Loïc Minier wrote: > forcemerge 613955 617633 > stop > > I'm guessing you didn't intend to open another report and just Cc:ed > submit@bugs.d.o by accident Yes, sorry about that. Newb user of debian bug system here. -- Alan Modra Australia Development Lab, IBM -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#617633: klibc: Install static binaries on ppc64
Package: klibc Version: 1.5.20-1 On Fri, Feb 18, 2011 at 01:42:31PM +, Colin Watson wrote: > We've been experimenting with bringing up a ppc64 port of Ubuntu. As > part of this I found that, much like ia64 (#439181), klibc shared > binaries simply segfault on ppc64: they seem to be loading > __malloc_head.next_free from the wrong place so as soon as anything > calls malloc it segfaults. Confirmed. The problem is that the correct toc pointer (r2) is not being set on calls into klibc. Instead of going via a plt call stub, a call just goes directly like any other call to locally defined functions. > so perhaps you could add it to the list of > architectures that need static binaries? A better fix would be to teach GNU ld how to handle -R objects. I'm looking into that. Another workaround is simply to never build ppc64 klibc. After all, ppc64 machines will quite happily run ppc32 klibc and 32-bit binaries are likely to be smaller. -- Alan Modra Australia Development Lab, IBM -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#370341: CVS fails to update some repositories
https://bugzilla.mindrot.org/show_bug.cgi?id=85 perhaps? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
