date:20170810

Re: head -r320192 vs. devel/aarch64-xtoolchain-gcc and devel/aarch64-binutils (/usr/ports -r443557): "liblto_plugin.so: error loading plugin: Service unavailable" for .pico link

2017-08-10 Thread Mark Millard

[The problem during buildworld via aarch64-xtoolchain-gcc still occurs
for -r322287 of head and -r447082 of /usr/ports. It is because of using
the default static-link of devel/aarch64-binutils utilities, including
/usr/local/bin/aarch64-freebsd-ld . A non-default devel/aarch64-binutils
is required.]

FYI:

# pkg info | grep aarch64
aarch64-binutils-2.28,1GNU binutils for AArch64 cross-development
aarch64-gcc-6.3.0  Cross GNU Compiler Collection for aarch64
aarch64-xtoolchain-gcc-0.2 Pre seeded toolchain to cross build FreeBSD base

For aarch64-binutils-2.28,1 :

Configuration Options
===> The following configuration options are available for 
aarch64-binutils-2.28,1:
 RELRO=off: enable -z relro in ELF linker by default
 STATIC=on: Build static executables and/or libraries
===> Use 'make config' to modify these settings

It build aarch64-binutils as static by default as of 2017-Feb-22:

This is required to build Arm64 packages using QEMU.  Poudriere copies
the native ld from the host into the jail and uses that during the build.
This only works if ld is static.

Reported by:krion
Approved by:bapt


But for aarch64-xtoolchain-gcc related use the default blocks buildworld :



building shared library libc.so.7
/usr/local/bin/aarch64-freebsd-ld: 
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so: 
error loading plugin: Service unavailable
collect2: error: ld returned 1 exit status
*** [libc.so.7.full] Error code 1

make[4]: stopped in /usr/src/lib/libc
.ERROR_TARGET='libc.so.7.full'
.ERROR_META_FILE='/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/lib/libc/libc.so.7.full.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
. . .

# file /usr/local/bin/aarch64-freebsd-ld
/usr/local/bin/aarch64-freebsd-ld: ELF 64-bit LSB executable, x86-64, version 1 
(FreeBSD), statically linked, for FreeBSD 12.0 (1200036), FreeBSD-style, not 
stripped

# ls -lt /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/
total 43913
drwxr-xr-x  2 root  wheel 3 Jun 28 17:51 plugin
drwxr-xr-x  2 root  wheel 6 Jun 28 17:51 install-tools
-r-xr-xr-x  1 root  wheel   1422072 Jun 28 17:51 lto-wrapper
-r-xr-xr-x  1 root  wheel   1229416 Jun 28 17:51 collect2
-r-xr-xr-x  1 root  wheel  28472516 Jun 28 17:51 lto1
-r-xr-xr-x  1 root  wheel  32125603 Jun 28 17:51 cc1plus
-r-xr-xr-x  1 root  wheel  29707472 Jun 28 17:51 cc1
lrwxr-xr-x  1 root  wheel22 Jun 28 17:51 liblto_plugin.so -> 
liblto_plugin.so.0.0.0
lrwxr-xr-x  1 root  wheel22 Jun 28 17:51 liblto_plugin.so.0 -> 
liblto_plugin.so.0.0.0
-rwxr-xr-x  1 root  wheel253310 Jun 28 17:51 liblto_plugin.so.0.0.0

# file /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/*
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/cc1:   
 ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, 
interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 (1200036), FreeBSD-style, 
not stripped
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/cc1plus:   
 ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, 
interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 (1200036), FreeBSD-style, 
not stripped
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/collect2:  
 ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, 
interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 (1200036), FreeBSD-style, 
not stripped
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/install-tools: 
 directory
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:  
 symbolic link to liblto_plugin.so.0.0.0
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so.0:
 symbolic link to liblto_plugin.so.0.0.0
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so.0.0.0:
 ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, 
not stripped
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/lto-wrapper:   
 ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, 
interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 (1200036), FreeBSD-style, 
not stripped
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/lto1:  
 ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, 
interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 (1200036), FreeBSD-style, 
not stripped
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/plugin:
 directory

# ldd /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:
libc.so.7 => /lib/libc.so.7 (0x800825000)

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 447082
Last Changed Rev: 447082



===
M

head -r322287 buildworld vs. devel/aarch64-xtoolchain-gcc devel/aarch64-binutils devel/aarch64-gcc: Error: selected processor does not support

2017-08-10 Thread Mark Millard

Attempting buildworld with devel/aarch64-xtoolchain-gcc
and devel/aarch64-binutils I got:

/usr/src/crypto/openssl/crypto/arm64cpuid.S: Assembler messages:
/usr/src/crypto/openssl/crypto/arm64cpuid.S:23: Error: selected processor does 
not support `aese v0.16b,v0.16b'
/usr/src/crypto/openssl/crypto/arm64cpuid.S:30: Error: selected processor does 
not support `sha1h s0,s0'
/usr/src/crypto/openssl/crypto/arm64cpuid.S:37: Error: selected processor does 
not support `sha256su0 v0.4s,v0.4s'
/usr/src/crypto/openssl/crypto/arm64cpuid.S:43: Error: selected processor does 
not support `pmull v0.1q,v0.1d,v0.1d'
*** [arm64cpuid.o] Error code 1

The code in question is the probe source code:

. . .
.global _armv8_aes_probe
.type   _armv8_aes_probe,%function
_armv8_aes_probe:
aesev0.16b, v0.16b
ret
.size   _armv8_aes_probe,.-_armv8_aes_probe

.global _armv8_sha1_probe
.type   _armv8_sha1_probe,%function
_armv8_sha1_probe:
sha1h   s0, s0
ret
.size   _armv8_sha1_probe,.-_armv8_sha1_probe

.global _armv8_sha256_probe
.type   _armv8_sha256_probe,%function
_armv8_sha256_probe:
sha256su0   v0.4s, v0.4s
ret
.size   _armv8_sha256_probe,.-_armv8_sha256_probe
.global _armv8_pmull_probe
.type   _armv8_pmull_probe,%function
_armv8_pmull_probe:
pmull   v0.1q, v0.1d, v0.1d
ret
.size   _armv8_pmull_probe,.-_armv8_pmull_probe


This source presumes that the assembler will allow
the instructions via official mnemonics but
/usr/local/bin/aarch64-freebsd-as does not do so
here.

My environment has -mcpu=cortex-a53 explicitly via
XCFLAGS. (It shows in reported
/usr/local/bin/aarch64-unknown-freebsd12.0-gcc command for
arm64cpuid.S and in the
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/cc1
command. In the /usr/local/bin/aarch64-freebsd-as
command that results there is: -march=armv8-a+crypto
-march=armv8-a+crc . See later in this submittal.)

Supporting details follow for reference, with
the full failure text last.

# more 
~/sys_build_scripts.amd64-host/make_cortexA53_nodebug_incl_clang_xtoolchain-gcc-amd64-host.sh
 
kldload -n filemon && \
script 
~/sys_typescripts/typescript_make_cortexA53_nodebug_incl_clang_xtoolchain-gcc-amd64-host-$(date
 +%Y-%m-%d:%H:%M:%S) \
env __MAKE_CONF="/root/src.configs/make.conf" SRCCONF="/dev/null" 
SRC_ENV_CONF="/root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host" \
WITH_META_MODE=yes \
MAKEOBJDIRPREFIX="/usr/obj/cortexA53_xtoolchain-gcc" \
make $*

# more /root/src.configs/make.conf
CFLAGS.gcc+= -v

# more /root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host
TO_TYPE=aarch64
TOOLS_TO_TYPE=${TO_TYPE}
VERSION_CONTEXT=12.0
#
KERNCONF=GENERIC-NODBG
TARGET=arm64
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITHOUT_BINUTILS_BOOTSTRAP=
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITHOUT_LLD_BOOTSTRAP=
WITH_LLD=
WITH_LLD_IS_LD=
WITH_LLDB=
#
WITH_BOOT=
WITHOUT_LIB32=
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
XCFLAGS+= -mcpu=cortex-a53
XCXXFLAGS+= -mcpu=cortex-a53
# There is no XCPPFLAGS but XCPP gets XCFLAGS content.
#
#
# For TO (so-called "cross") stages . . .
# So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
# TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
#
CROSS_TOOLCHAIN=${TO_TYPE}-gcc
X_COMPILER_TYPE=gcc
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
.if ${.MAKE.LEVEL} == 0
XCC=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gcc
XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g++
XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-cpp
.export XCC
.export XCXX
.export XCPP
XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
#NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
.export XAS
.export XAR
.export XLD
.export XNM
.export XOBJCOPY
.export XOBJDUMP
.export XRANLIB
.export XSIZE
.export XSTRINGS
.endif
#
#
# From based on clang (via system). . .
#
.if ${.MAKE.LEVEL} == 0
CC=/usr/bin/clang
CXX=/usr/bin/clang++
CPP=/usr/bin/clang-cpp
.export CC
.export CXX
.export CPP
.endif

NOTE: devel/aarch64-binutils is built with the
static linking disabled in order to get this
far in the first place: Otherwise its ld fails
for attempting a dlopen use from a
statically linked program.

Re: I have submitted bugzilla 221107 for a (e.g.) -r321706 system clang 5 vintage TARGET_ARCH=powerpc buildkernel failure for aha.kld: R_PPC_PLTREL24 reloc against local symbol

2017-08-10 Thread Mark Millard

[A top post about the failing R_PPC_PLTREL24 since
the material does not flow well as a sequential
read from prior material. I found that the .kld
does not match the contributing .o for GLOBAL
status for routines and the LOCAL in the .kld is
rejected by ld in ppc_elf_check_relocs.]

There is something consistent between the two example
failures. (The examples here are from a more recent
head version for a buildkernel attempt.)

(I inserted some lines not matched by the shown grep.)

# readelf -a 
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/aha/aha.kld
 | grep aha_alloc
2b8c 3e12 R_PPC_PLTREL24   aha_alloc + 0
31a8 3e12 R_PPC_PLTREL24   aha_alloc + 0
Symbol table (.symtab) contains 180 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
62: 96 FUNCLOCAL  DEFAULT1 aha_alloc

but in aha.o :

44: 96 FUNCGLOBAL DEFAULT2 aha_alloc

# readelf -a 
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/agp/agp.kld
 | grep agp_find_caps
2e08 4912 R_PPC_PLTREL24   agp_find_caps + 0
Symbol table (.symtab) contains 180 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
73:    172 FUNCLOCAL  DEFAULT1 agp_find_caps

but in agp.o :

58:    172 FUNCGLOBAL DEFAULT2 agp_find_caps

building the .kld's is turning GLOBAL into LOCAL -- and the LOCAL
is being rejected by:

/usr/src/contrib/binutils/bfd/elf32-ppc.c

in its routine:

/* Look through the relocs for a section during the first phase, and
   allocate space in the global offset table or procedure linkage
   table.  */

static bfd_boolean
ppc_elf_check_relocs (bfd *abfd,
  struct bfd_link_info *info,
  asection *sec,
  const Elf_Internal_Rela *relocs)

via:

  r_symndx = ELF32_R_SYM (rel->r_info);
  if (r_symndx < symtab_hdr->sh_info)
h = NULL;
  else  

. . .
  tls_type = 0;
  r_type = ELF32_R_TYPE (rel->r_info);
. . .  
  switch (r_type)
{
. . .
case R_PPC_PLT32:
case R_PPC_PLTREL24:
case R_PPC_PLTREL32:
case R_PPC_PLT16_LO:
case R_PPC_PLT16_HI:
case R_PPC_PLT16_HA:
#ifdef DEBUG
  fprintf (stderr, "Reloc requires a PLT entry\n");
#endif
  /* This symbol requires a procedure linkage table entry.  We
 actually build the entry in finish_dynamic_symbol,
 because this might be a case of linking PIC code without
 linking in any dynamic objects, in which case we don't
 need to generate a procedure linkage table after all.  */

  if (h == NULL)
{
  /* It does not make sense to have a procedure linkage
 table entry for a local symbol.  */
  (*_bfd_error_handler) (_("%B(%A+0x%lx): %s reloc against "
   "local symbol"),
 abfd,
 sec,
 (long) rel->r_offset,
 ppc_elf_howto_table[r_type]->name);
  bfd_set_error (bfd_error_bad_value);
  return FALSE;
}
  else
. . .

===
Mark Millard
markmi at dsl-only.net

On 2017-Aug-6, at 2:44 PM, Mark Millard  wrote:

[-r322109 update failed for agp.kld instead. It may just be
a race for which happens first during the build.]

On 2017-Jul-30, at 3:03 PM, Mark Millard  wrote:

> [Just correcting the -r's to be -r321706.]
> 
> On 2017-Jul-30, at 1:34 PM, Mark Millard  wrote:
> 
> I experiment with system clang targeting powerpc
> (and powerpc64). Until recently I could buildkernel
> via system clang 4 (but it had problems if tried to
> boot such a kernel). After clang 5 it no longer
> completes the buildkernel. I'm submitting based on
> a -r321706 build attempt. The system binutils are
> in use.
> 
> The technical material from the submittal is. . .
> 
> First I list what the R_PPC_PLTREL24 is tied to
> then the error text then the build context.
> 
> objdump reports that the .text+0x2b94 involved
> is in aha_isa_probe and is a reference to aha_alloc:
> 
> (sorted objdump -x output:)
> 2b78 R_PPC_PLTREL24bus_alloc_resource
> 2b88 R_PPC_PLTREL24rman_get_start
> 2b94 R_PPC_PLTREL24aha_alloc
> 2b96 R_PPC_ADDR32  .debug_str+0x266c
> 2b9c R_PPC_PLTREL24aha_probe
> 2b9f R_PPC_ADDR32  .debug_str+0x1904
> 
> (objdump -d --prefix-addresses output:)
> 2aa4  mflrr0
> . . .
> 2b7c  cmplwi  r3,0
> 2b80  stw r3,188(r28)
> 2b84  beq 2c1c 
> 2b88  bl  2b88 
> 2b8c  mr  r3,r28
> 2b90  mr  r27,r4
> 2b94  bl

Re: I have submitted bugzilla 221107 for a (e.g.) -r321706 system clang 5 vintage TARGET_ARCH=powerpc buildkernel failure for aha.kld: R_PPC_PLTREL24 reloc against local symbol

2017-08-10 Thread Mark Millard

[clang 5 generates R_PPC_PLTREL24 in the .o files
for global symbols in places gcc 4.2.1 generates
R_PPC_ADDR16_HA / R_PPC_ADDR16_LO pairs.]

On 2017-Aug-10, at 7:22 PM, Mark Millard  wrote:

> [A top post about the failing R_PPC_PLTREL24 since
> the material does not flow well as a sequential
> read from prior material. I found that the .kld
> does not match the contributing .o for GLOBAL
> status for routines and the LOCAL in the .kld is
> rejected by ld in ppc_elf_check_relocs.]
> 
> There is something consistent between the two example
> failures. (The examples here are from a more recent
> head version for a buildkernel attempt.)
> 
> (I inserted some lines not matched by the shown grep.)
> 
> # readelf -a 
> /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/aha/aha.kld
>  | grep aha_alloc
> 2b8c 3e12 R_PPC_PLTREL24   aha_alloc + 0
> 31a8 3e12 R_PPC_PLTREL24   aha_alloc + 0
> Symbol table (.symtab) contains 180 entries:
>   Num:Value  Size TypeBind   Vis  Ndx Name
>62: 96 FUNCLOCAL  DEFAULT1 aha_alloc
> 
> but in aha.o :
> 
>44: 96 FUNCGLOBAL DEFAULT2 aha_alloc
> 
> # readelf -a 
> /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/agp/agp.kld
>  | grep agp_find_caps
> 2e08 4912 R_PPC_PLTREL24   agp_find_caps + 0
> Symbol table (.symtab) contains 180 entries:
>   Num:Value  Size TypeBind   Vis  Ndx Name
>73:    172 FUNCLOCAL  DEFAULT1 agp_find_caps
> 
> but in agp.o :
> 
>58:    172 FUNCGLOBAL DEFAULT2 agp_find_caps
> 
> building the .kld's is turning GLOBAL into LOCAL -- and the LOCAL
> is being rejected by:
> 
> /usr/src/contrib/binutils/bfd/elf32-ppc.c
> 
> in its routine:
> 
> /* Look through the relocs for a section during the first phase, and
>   allocate space in the global offset table or procedure linkage
>   table.  */
> 
> static bfd_boolean
> ppc_elf_check_relocs (bfd *abfd,
>  struct bfd_link_info *info,
>  asection *sec,
>  const Elf_Internal_Rela *relocs)
> 
> via:
> 
> 
>  r_symndx = ELF32_R_SYM (rel->r_info);
>  if (r_symndx < symtab_hdr->sh_info)
>h = NULL;
>  else  
> 
> . . .
>  tls_type = 0;
>  r_type = ELF32_R_TYPE (rel->r_info);
> . . .  
>  switch (r_type)
>{
> . . .
>case R_PPC_PLT32:
>case R_PPC_PLTREL24:
>case R_PPC_PLTREL32:
>case R_PPC_PLT16_LO:
>case R_PPC_PLT16_HI:
>case R_PPC_PLT16_HA:
> #ifdef DEBUG
>  fprintf (stderr, "Reloc requires a PLT entry\n");
> #endif
>  /* This symbol requires a procedure linkage table entry.  We
> actually build the entry in finish_dynamic_symbol,
> because this might be a case of linking PIC code without
> linking in any dynamic objects, in which case we don't
> need to generate a procedure linkage table after all.  */
> 
>  if (h == NULL)
>{
>  /* It does not make sense to have a procedure linkage
> table entry for a local symbol.  */
>  (*_bfd_error_handler) (_("%B(%A+0x%lx): %s reloc against "
>   "local symbol"),
> abfd,
> sec,
> (long) rel->r_offset,
> ppc_elf_howto_table[r_type]->name);
>  bfd_set_error (bfd_error_bad_value);
>  return FALSE;
>}
>  else
> . . .

clang 5 and gcc 4.2.1 do not match for what
goes in aha*.o and agp*.o files for the
problem symbols in clang 5's output:

gcc 4.2.1 ( R_PPC_ADDR16_HA / R_PPC_ADDR16_LO ):

# readelf -at 
/usr/obj/powerpcvtsc_gcc421/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/aha/aha*.o
 | grep aha_alloc
50: 0514   112 FUNCGLOBAL DEFAULT1 aha_alloc
0032 3206 R_PPC_ADDR16_HA  aha_alloc + 0
003e 3204 R_PPC_ADDR16_LO  aha_alloc + 0
052a 3206 R_PPC_ADDR16_HA  aha_alloc + 0
052e 3204 R_PPC_ADDR16_LO  aha_alloc + 0
50:  0 NOTYPE  GLOBAL DEFAULT  UND aha_alloc

# readelf -at 
/usr/obj/powerpcvtsc_gcc421/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/agp/agp*.o
 | grep caps
204a 3a06 R_PPC_ADDR16_HA 0434 agp_find_caps + 0
204e 3a04 R_PPC_ADDR16_LO 0434 agp_find_caps + 0
2312 3a06 R_PPC_ADDR16_HA 0434 agp_find_caps + 0
231a 3a04 R_PPC_ADDR16_LO 0434 agp_find_caps + 0
 3a01 R_PPC_ADDR320434 agp_find_caps + 0
58: 000

Re: head -r320192 vs. devel/aarch64-xtoolchain-gcc and devel/aarch64-binutils (/usr/ports -r443557): "liblto_plugin.so: error loading plugin: Service unavailable" for .pico link

head -r322287 buildworld vs. devel/aarch64-xtoolchain-gcc devel/aarch64-binutils devel/aarch64-gcc: Error: selected processor does not support

Re: I have submitted bugzilla 221107 for a (e.g.) -r321706 system clang 5 vintage TARGET_ARCH=powerpc buildkernel failure for aha.kld: R_PPC_PLTREL24 reloc against local symbol

Re: I have submitted bugzilla 221107 for a (e.g.) -r321706 system clang 5 vintage TARGET_ARCH=powerpc buildkernel failure for aha.kld: R_PPC_PLTREL24 reloc against local symbol

4 matches

Site Navigation

Mail list logo

Footer information