powerpc-vxworks testers needed

powerpc-vxworks testers needed

[Alan Modra]

We have ELF ppc32 targets that don't use ppc32elf.em, which meant they
broke with https://sourceware.org/ml/binutils/2014-02/msg00010.html
due to a NULL htab->params dereference.  I suppose I could find out if
anyone still uses powerpc-lynxos, powerpc-netware, or powerpc-windiss
by leaving them broken..  Really, all the ppc32 ELF targets ought to
be updated to use ppc32elf.em, as I'm doing for powerpc-vxworks here,
but for the others the elf32-ppc.c patch ought to be good enough.

Now, I don't have access to a powerpc-vxworks system, so this patch
might leave vxworks broken due to additional features being enabled.
For example, TLS optimisation will now occur on powerpc-vxworks, and
I don't have any information on how TLS is implemented on vxworks.
Hopefully, it follows my original ppc tls implementation in terms of
code and reloc sequences..  If not, I'd like to hear about problems
now rather than a week or so after the next binutils release.  ;)

bfd/
	* elf32-ppc.c (ppc_elf_link_hash_table_create): Provide default
	params for targets that don't use ppc32elf.em.
ld/
	* emulparams/elf32ppcvxworks.sh: Source plt_unwind.sh and
	use ppc32elf.em.
	* emultempl/ppc32elf.em (ppc_after_open): Don't compile for
	vxworks.
	(LDEMUL_AFTER_OPEN): Don't set for vxworks.
	(PARSE_AND_LIST_LONGOPTS, PARSE_AND_LIST_OPTIONS): Exclude
	-secure-plt, -bss-plt and -sdata-got when vxworks.

diff --git a/bfd/elf32-ppc.c b/bfd/elf32-ppc.c
index 1c8724f..529fd52 100644
--- a/bfd/elf32-ppc.c
+++ b/bfd/elf32-ppc.c
@@ -1,7 +1,5 @@
 /* PowerPC-specific support for 32-bit ELF
-   Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
-   2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
-   Free Software Foundation, Inc.
+   Copyright (C) 1994-2014 Free Software Foundation, Inc.
    Written by Ian Lance Taylor, Cygnus Support.
 
    This file is part of BFD, the Binary File Descriptor library.
@@ -3252,6 +3250,7 @@ static struct bfd_link_hash_table *
 ppc_elf_link_hash_table_create (bfd *abfd)
 {
   struct ppc_elf_link_hash_table *ret;
+  static struct ppc_elf_params default_params = { PLT_OLD, 0, 1, 0, 0, 4096 };
 
   ret = bfd_zmalloc (sizeof (struct ppc_elf_link_hash_table));
   if (ret == NULL)
@@ -3271,6 +3270,8 @@ ppc_elf_link_hash_table_create (bfd *abfd)
   ret->elf.init_plt_offset.offset = 0;
   ret->elf.init_plt_offset.glist = NULL;
 
+  ret->params = &default_params;
+
   ret->sdata[0].name = ".sdata";
   ret->sdata[0].sym_name = "_SDA_BASE_";
   ret->sdata[0].bss_name = ".sbss";
diff --git a/ld/emulparams/elf32ppcvxworks.sh b/ld/emulparams/elf32ppcvxworks.sh
index 1bc3f30..88c1da0 100644
--- a/ld/emulparams/elf32ppcvxworks.sh
+++ b/ld/emulparams/elf32ppcvxworks.sh
@@ -1,3 +1,5 @@
 . ${srcdir}/emulparams/elf32ppccommon.sh
+. ${srcdir}/emulparams/plt_unwind.sh
+EXTRA_EM_FILE=ppc32elf
 OUTPUT_FORMAT="elf32-powerpc-vxworks"
 . ${srcdir}/emulparams/vxworks.sh
diff --git a/ld/emultempl/ppc32elf.em b/ld/emultempl/ppc32elf.em
index f5a3a70..00a29e2 100644
--- a/ld/emultempl/ppc32elf.em
+++ b/ld/emultempl/ppc32elf.em
@@ -1,6 +1,5 @@
 # This shell script emits a C file. -*- C -*-
-#   Copyright 2003, 2005, 2007, 2008, 2009, 2010, 2011, 2012
-#   Free Software Foundation, Inc.
+#   Copyright (C) 2003-2014 Free Software Foundation, Inc.
 #
 # This file is part of the GNU Binutils.
 #
@@ -54,6 +53,11 @@ ppc_after_open_output (void)
   ppc_elf_link_params (&link_info, &params);
 }
 
+EOF
+
+# No --secure-plt, --bss-plt, or --sdata-got for vxworks.
+if test -z "$VXWORKS_BASE_EM_FILE" ; then
+  fragment <<EOF
 static void
 ppc_after_open (void)
 {
@@ -109,6 +113,9 @@ ppc_after_open (void)
   gld${EMULATION_NAME}_after_open ();
 }
 
+EOF
+fi
+fragment <<EOF
 static void
 ppc_before_allocation (void)
 {
@@ -206,10 +213,14 @@ PARSE_AND_LIST_LONGOPTS=${PARSE_AND_LIST_LONGOPTS}'
   { "emit-stub-syms", no_argument, NULL, OPTION_STUBSYMS },
   { "no-emit-stub-syms", no_argument, NULL, OPTION_NO_STUBSYMS },
   { "no-tls-optimize", no_argument, NULL, OPTION_NO_TLS_OPT },
-  { "no-tls-get-addr-optimize", no_argument, NULL, OPTION_NO_TLS_GET_ADDR_OPT },
+  { "no-tls-get-addr-optimize", no_argument, NULL, OPTION_NO_TLS_GET_ADDR_OPT },'
+if test -z "$VXWORKS_BASE_EM_FILE" ; then
+  PARSE_AND_LIST_LONGOPTS=${PARSE_AND_LIST_LONGOPTS}'
   { "secure-plt", no_argument, NULL, OPTION_NEW_PLT },
   { "bss-plt", no_argument, NULL, OPTION_OLD_PLT },
-  { "sdata-got", no_argument, NULL, OPTION_OLD_GOT },
+  { "sdata-got", no_argument, NULL, OPTION_OLD_GOT },'
+fi
+PARSE_AND_LIST_LONGOPTS=${PARSE_AND_LIST_LONGOPTS}'
   { "ppc476-workaround", optional_argument, NULL, OPTION_PPC476_WORKAROUND },
   { "no-ppc476-workaround", no_argument, NULL, OPTION_NO_PPC476_WORKAROUND },
 '
@@ -219,10 +230,14 @@ PARSE_AND_LIST_OPTIONS=${PARSE_AND_LIST_OPTIONS}'
   --emit-stub-syms            Label linker stubs with a symbol.\n\
   --no-emit-stub-syms         Don'\''t label linker stubs with a symbol.\n\
   --no-tls-optimize           Don'\''t try to optimize TLS accesses.\n\
-  --no-tls-get-addr-optimize  Don'\''t use a special __tls_get_addr call.\n\
+  --no-tls-get-addr-optimize  Don'\''t use a special __tls_get_addr call.\n'
+if test -z "$VXWORKS_BASE_EM_FILE" ; then
+  PARSE_AND_LIST_OPTIONS=${PARSE_AND_LIST_OPTIONS}'\
   --secure-plt                Use new-style PLT if possible.\n\
   --bss-plt                   Force old-style BSS PLT.\n\
-  --sdata-got                 Force GOT location just before .sdata.\n\
+  --sdata-got                 Force GOT location just before .sdata.\n'
+fi
+PARSE_AND_LIST_OPTIONS=${PARSE_AND_LIST_OPTIONS}'\
   --ppc476-workaround [=pagesize]\n\
                               Avoid a cache bug on ppc476.\n\
   --no-ppc476-workaround      Disable workaround.\n"
@@ -284,5 +299,7 @@ PARSE_AND_LIST_ARGS_CASES=${PARSE_AND_LIST_ARGS_CASES}'
 # Put these extra ppc32elf routines in ld_${EMULATION_NAME}_emulation
 #
 LDEMUL_CREATE_OUTPUT_SECTION_STATEMENTS=ppc_after_open_output
-LDEMUL_AFTER_OPEN=ppc_after_open
+if test -z "$VXWORKS_BASE_EM_FILE" ; then
+  LDEMUL_AFTER_OPEN=ppc_after_open
+fi
 LDEMUL_BEFORE_ALLOCATION=ppc_before_allocation

-- 
Alan Modra
Australia Development Lab, IBM

Re: powerpc-vxworks testers needed

[Jerome Guitton]

Alan Modra (amodra@gmail.com):

> Now, I don't have access to a powerpc-vxworks system, so this patch
> might leave vxworks broken due to additional features being enabled.
> For example, TLS optimisation will now occur on powerpc-vxworks, and
> I don't have any information on how TLS is implemented on vxworks.
> Hopefully, it follows my original ppc tls implementation in terms of
> code and reloc sequences..  If not, I'd like to hear about problems
> now rather than a week or so after the next binutils release.  ;)

FWIW, I've tested this patch against our internal Ada testsuites in
rtp/smp (the only configuration where we know that TLS would have an
impact). No regression.

Re: powerpc-vxworks testers needed

[Alan Modra]

On Mon, Mar 03, 2014 at 08:07:16PM +0100, Jerome Guitton wrote:
> Alan Modra (amodra@gmail.com):
> 
> > Now, I don't have access to a powerpc-vxworks system, so this patch
> > might leave vxworks broken due to additional features being enabled.
> > For example, TLS optimisation will now occur on powerpc-vxworks, and
> > I don't have any information on how TLS is implemented on vxworks.
> > Hopefully, it follows my original ppc tls implementation in terms of
> > code and reloc sequences..  If not, I'd like to hear about problems
> > now rather than a week or so after the next binutils release.  ;)
> 
> FWIW, I've tested this patch against our internal Ada testsuites in
> rtp/smp (the only configuration where we know that TLS would have an
> impact). No regression.

Thanks!

-- 
Alan Modra
Australia Development Lab, IBM

powerpc-rtems testers was Re: powerpc-vxworks testers needed

[Joel Sherrill]

On 3/3/2014 1:07 PM, Jerome Guitton wrote:
> Alan Modra (amodra@gmail.com):
>
>> Now, I don't have access to a powerpc-vxworks system, so this patch
>> might leave vxworks broken due to additional features being enabled.
>> For example, TLS optimisation will now occur on powerpc-vxworks, and
>> I don't have any information on how TLS is implemented on vxworks.
>> Hopefully, it follows my original ppc tls implementation in terms of
>> code and reloc sequences..  If not, I'd like to hear about problems
>> now rather than a week or so after the next binutils release.  ;)
> FWIW, I've tested this patch against our internal Ada testsuites in
> rtp/smp (the only configuration where we know that TLS would have an
> impact). No regression.
>
RTEMS has SMP support. What do we need to be on the lookout for?

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: powerpc-rtems testers was Re: powerpc-vxworks testers needed

[Alan Modra]

On Mon, Mar 03, 2014 at 02:37:25PM -0600, Joel Sherrill wrote:
> 
> On 3/3/2014 1:07 PM, Jerome Guitton wrote:
> > Alan Modra (amodra@gmail.com):
> >
> >> Now, I don't have access to a powerpc-vxworks system, so this patch
> >> might leave vxworks broken due to additional features being enabled.
> >> For example, TLS optimisation will now occur on powerpc-vxworks, and
> >> I don't have any information on how TLS is implemented on vxworks.
> >> Hopefully, it follows my original ppc tls implementation in terms of
> >> code and reloc sequences..  If not, I'd like to hear about problems
> >> now rather than a week or so after the next binutils release.  ;)
> > FWIW, I've tested this patch against our internal Ada testsuites in
> > rtp/smp (the only configuration where we know that TLS would have an
> > impact). No regression.
> >
> RTEMS has SMP support. What do we need to be on the lookout for?

You probably don't need to worry any more than you normally do when I
start hacking.  :)  powerpc-rtems ought to be unaffected since that
target has been using ppc32elf.em forever.

-- 
Alan Modra
Australia Development Lab, IBM

Re: powerpc-rtems testers was Re: powerpc-vxworks testers needed

[Joel Sherrill]

On 3/4/2014 5:45 PM, Alan Modra wrote:
> On Mon, Mar 03, 2014 at 02:37:25PM -0600, Joel Sherrill wrote:
>> On 3/3/2014 1:07 PM, Jerome Guitton wrote:
>>> Alan Modra (amodra@gmail.com):
>>>
>>>> Now, I don't have access to a powerpc-vxworks system, so this patch
>>>> might leave vxworks broken due to additional features being enabled.
>>>> For example, TLS optimisation will now occur on powerpc-vxworks, and
>>>> I don't have any information on how TLS is implemented on vxworks.
>>>> Hopefully, it follows my original ppc tls implementation in terms of
>>>> code and reloc sequences..  If not, I'd like to hear about problems
>>>> now rather than a week or so after the next binutils release.  ;)
>>> FWIW, I've tested this patch against our internal Ada testsuites in
>>> rtp/smp (the only configuration where we know that TLS would have an
>>> impact). No regression.
>>>
>> RTEMS has SMP support. What do we need to be on the lookout for?
> You probably don't need to worry any more than you normally do when I
> start hacking.  :)  powerpc-rtems ought to be unaffected since that
> target has been using ppc32elf.em forever.
>

:) We try very hard to stay close to the base configurations since that 
reduces the
likelihood of RTEMS specific bugs. Unfortunately, that sometimes means 
XXX-rtems
gets caught by *CPU*-*-* in a configure switch and we are invisible.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: powerpc-vxworks testers needed

[Kwok Cheung Yeung]

> Now, I don't have access to a powerpc-vxworks system, so this patch
> might leave vxworks broken due to additional features being enabled.
> For example, TLS optimisation will now occur on powerpc-vxworks, and
> I don't have any information on how TLS is implemented on vxworks.
> Hopefully, it follows my original ppc tls implementation in terms of
> code and reloc sequences..  If not, I'd like to hear about problems
> now rather than a week or so after the next binutils release.  ;)

I have backported your patches for the PPC476 workaround to an older 
version of binutils (a snapshot of 2.19, dating from around the middle 
of 2009). Automated Dejagnu testing shows no noticeable regressions on 
PowerPC VxWorks.

Regards

Kwok Yeung