[patch] handle unaligned arm abs relocs

[patch] handle unaligned arm abs relocs

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

background can be found here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51456

patch is below
-mike

2011-12-12  Mike Frysinger  <vapier@gentoo.org>

	* dl-machine.h (elf_machine_rel, R_ARM_ABS32): Declare "reloc_value".
	Replace reloc_addr addition with memcpy's.

diff --git a/sysdeps/arm/dl-machine.h b/sysdeps/arm/dl-machine.h
index 5ceeaa9..fe64800 100644
--- a/sysdeps/arm/dl-machine.h
+++ b/sysdeps/arm/dl-machine.h
@@ -413,6 +413,7 @@ elf_machine_rel (struct link_map *map, const Elf32_Rel 
*reloc,
 	  break;
 	case R_ARM_ABS32:
 	  {
+	    Elf32_Addr reloc_value;
 # ifndef RTLD_BOOTSTRAP
 	   /* This is defined in rtld.c, but nowhere in the static
 	      libc.a; make the reference weak so static programs can
@@ -431,7 +432,10 @@ elf_machine_rel (struct link_map *map, const Elf32_Rel 
*reloc,
 		 used while loading those libraries.  */
 	      value -= map->l_addr + refsym->st_value;
 # endif
-	    *reloc_addr += value;
+	    /* Support relocations on mis-aligned offsets.  */
+	    memcpy (&reloc_value, reloc_addr_arg, sizeof (reloc_value));
+	    reloc_value += value;
+	    memcpy (reloc_addr_arg, &reloc_value, sizeof (reloc_value));
 	    break;
 	  }
 	case R_ARM_TLS_DESC:

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [patch] handle unaligned arm abs relocs

[Carlos O'Donell]

On 12/12/2011 7:20 PM, Mike Frysinger wrote:
> background can be found here:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51456
> 
> patch is below
> -mike
> 
> 2011-12-12  Mike Frysinger  <vapier@gentoo.org>
> 
> 	* dl-machine.h (elf_machine_rel, R_ARM_ABS32): Declare "reloc_value".
> 	Replace reloc_addr addition with memcpy's.
> 
> diff --git a/sysdeps/arm/dl-machine.h b/sysdeps/arm/dl-machine.h
> index 5ceeaa9..fe64800 100644
> --- a/sysdeps/arm/dl-machine.h
> +++ b/sysdeps/arm/dl-machine.h
> @@ -413,6 +413,7 @@ elf_machine_rel (struct link_map *map, const Elf32_Rel 
> *reloc,
>  	  break;
>  	case R_ARM_ABS32:
>  	  {
> +	    Elf32_Addr reloc_value;
>  # ifndef RTLD_BOOTSTRAP
>  	   /* This is defined in rtld.c, but nowhere in the static
>  	      libc.a; make the reference weak so static programs can
> @@ -431,7 +432,10 @@ elf_machine_rel (struct link_map *map, const Elf32_Rel 
> *reloc,
>  		 used while loading those libraries.  */
>  	      value -= map->l_addr + refsym->st_value;
>  # endif
> -	    *reloc_addr += value;
> +	    /* Support relocations on mis-aligned offsets.  */
> +	    memcpy (&reloc_value, reloc_addr_arg, sizeof (reloc_value));
> +	    reloc_value += value;
> +	    memcpy (reloc_addr_arg, &reloc_value, sizeof (reloc_value));

I don't believe that memcpy is safe this early in the loader.

You might be lucky and get an inlined memcpy or builtin, but you
might not and if you go through the PLT you'll fault since
it's not yet setup.

On PARISC we do a byte copy of unaligned relocation.

e.g.
      /* .eh_frame can have unaligned relocs.  */
      if ((unsigned long) reloc_addr_arg & 3)
        {
          char *rel_addr = (char *) reloc_addr_arg;
          rel_addr[0] = value >> 24;
          rel_addr[1] = value >> 16;
          rel_addr[2] = value >> 8;
          rel_addr[3] = value;
          return;
        }

>  	    break;
>  	  }
>  	case R_ARM_TLS_DESC:

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos@codesourcery.com
+1 (613) 963 1026

Re: [patch] handle unaligned arm abs relocs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1933 bytes --]

On Wednesday 14 December 2011 17:05:25 Carlos O'Donell wrote:
> On 12/12/2011 7:20 PM, Mike Frysinger wrote:
> > background can be found here:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51456
> > 
> > 2011-12-12  Mike Frysinger  <vapier@gentoo.org>
> > 
> > 	* dl-machine.h (elf_machine_rel, R_ARM_ABS32): Declare "reloc_value".
> > 	Replace reloc_addr addition with memcpy's.
> > 
> > diff --git a/sysdeps/arm/dl-machine.h b/sysdeps/arm/dl-machine.h
> > index 5ceeaa9..fe64800 100644
> > --- a/sysdeps/arm/dl-machine.h
> > +++ b/sysdeps/arm/dl-machine.h
> > @@ -413,6 +413,7 @@ elf_machine_rel (struct link_map *map, const
> >  	  break;
> >  	case R_ARM_ABS32:
> >  	  {
> > +	    Elf32_Addr reloc_value;
> >  # ifndef RTLD_BOOTSTRAP
> >  	   /* This is defined in rtld.c, but nowhere in the static
> >  	      libc.a; make the reference weak so static programs can
> > @@ -431,7 +432,10 @@ elf_machine_rel (struct link_map *map, const
> >  		 used while loading those libraries.  */
> >  	      value -= map->l_addr + refsym->st_value;
> >  # endif
> > -	    *reloc_addr += value;
> > +	    /* Support relocations on mis-aligned offsets.  */
> > +	    memcpy (&reloc_value, reloc_addr_arg, sizeof (reloc_value));
> > +	    reloc_value += value;
> > +	    memcpy (reloc_addr_arg, &reloc_value, sizeof (reloc_value));
> 
> I don't believe that memcpy is safe this early in the loader.
> 
> You might be lucky and get an inlined memcpy or builtin, but you
> might not and if you go through the PLT you'll fault since
> it's not yet setup.

i thought it should be OK because R_ARM_COPY already calls memcpy() a few 
lines up, but i don't know the ARM loader that well to say what is necessary

looking at the relocs that exist on my local arm ldso and i only see:
	R_ARM_RELATIVE
	R_ARM_GLOB_DAT
	R_ARM_JUMP_SLOT

hopefully someone who understands ARM better can comment ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [patch] handle unaligned arm abs relocs

[Carlos O'Donell]

On 12/14/2011 5:29 PM, Mike Frysinger wrote:
> On Wednesday 14 December 2011 17:05:25 Carlos O'Donell wrote:
>> On 12/12/2011 7:20 PM, Mike Frysinger wrote:
>>> background can be found here:
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51456
>>>
>>> 2011-12-12  Mike Frysinger  <vapier@gentoo.org>
>>>
>>> 	* dl-machine.h (elf_machine_rel, R_ARM_ABS32): Declare "reloc_value".
>>> 	Replace reloc_addr addition with memcpy's.
>>>
>>> diff --git a/sysdeps/arm/dl-machine.h b/sysdeps/arm/dl-machine.h
>>> index 5ceeaa9..fe64800 100644
>>> --- a/sysdeps/arm/dl-machine.h
>>> +++ b/sysdeps/arm/dl-machine.h
>>> @@ -413,6 +413,7 @@ elf_machine_rel (struct link_map *map, const
>>>  	  break;
>>>  	case R_ARM_ABS32:
>>>  	  {
>>> +	    Elf32_Addr reloc_value;
>>>  # ifndef RTLD_BOOTSTRAP
>>>  	   /* This is defined in rtld.c, but nowhere in the static
>>>  	      libc.a; make the reference weak so static programs can
>>> @@ -431,7 +432,10 @@ elf_machine_rel (struct link_map *map, const
>>>  		 used while loading those libraries.  */
>>>  	      value -= map->l_addr + refsym->st_value;
>>>  # endif
>>> -	    *reloc_addr += value;
>>> +	    /* Support relocations on mis-aligned offsets.  */
>>> +	    memcpy (&reloc_value, reloc_addr_arg, sizeof (reloc_value));
>>> +	    reloc_value += value;
>>> +	    memcpy (reloc_addr_arg, &reloc_value, sizeof (reloc_value));
>>
>> I don't believe that memcpy is safe this early in the loader.
>>
>> You might be lucky and get an inlined memcpy or builtin, but you
>> might not and if you go through the PLT you'll fault since
>> it's not yet setup.
> 
> i thought it should be OK because R_ARM_COPY already calls memcpy() a few 
> lines up, but i don't know the ARM loader that well to say what is necessary

COPY relocs are only for non-PIC executables accessing data from other
PIC objects. Almost all executables have a COPY reloc against stderr/stdout.

See this for some hand waving:
http://docs.oracle.com/cd/E19082-01/819-0690/chapter4-84604/index.html
 
> looking at the relocs that exist on my local arm ldso and i only see:
> 	R_ARM_RELATIVE
> 	R_ARM_GLOB_DAT
> 	R_ARM_JUMP_SLOT
> 
> hopefully someone who understands ARM better can comment ...

If it works, and you test that it works, then you're fine.

If you use mempcy and it's inlined then that's great, but it's
a possible point of failure when compiling glibc (or eglibc)
with options that don't inline memcpy e.g. -Os.

My warning to you is this: be very very careful calling any
library functions in dl-machine.h.

Cheers
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos@codesourcery.com
+1 (613) 963 1026

Re: [patch] handle unaligned arm abs relocs

[Richard Henderson]

On 12/14/2011 02:05 PM, Carlos O'Donell wrote:
> You might be lucky and get an inlined memcpy or builtin, but you
> might not and if you go through the PLT you'll fault since
> it's not yet setup.
> 
> On PARISC we do a byte copy of unaligned relocation.
> 
> e.g.
>       /* .eh_frame can have unaligned relocs.  */
>       if ((unsigned long) reloc_addr_arg & 3)
>         {
>           char *rel_addr = (char *) reloc_addr_arg;
>           rel_addr[0] = value >> 24;
>           rel_addr[1] = value >> 16;
>           rel_addr[2] = value >> 8;
>           rel_addr[3] = value;
>           return;
>         }

Let the compiler do that for you.

struct S { int x; } __attribute__((packed, may_alias));
void f(int *x, int y)
{
  ((struct S *)x)->x = y;
}

In particular, this will Know that armv[4-6] needs byte-by-byte copy
and armv7 does not.


r~

Re: [patch] handle unaligned arm abs relocs

[Joseph S. Myers]

On Mon, 12 Dec 2011, Mike Frysinger wrote:

> +	    /* Support relocations on mis-aligned offsets.  */
> +	    memcpy (&reloc_value, reloc_addr_arg, sizeof (reloc_value));
> +	    reloc_value += value;
> +	    memcpy (reloc_addr_arg, &reloc_value, sizeof (reloc_value));

It seems from the discussion that it would be useful to see exactly what 
code ends up getting generated for these memcpy calls.  Is it a function 
call or inlined?  What about all the other memcpy calls in the dynamic 
linker?  For calls to memcpy that really are function calls, do they end 
up going through the PLT, or do they end up as direct calls to the copy of 
memcpy in the dynamic linker (given that it's linked with a version script 
that hides memcpy along with all the other libc functions it uses, so it 
shouldn't be necessary for calls to go through the PLT)?

(If it ends up as a direct call, care might still be needed if ARM memcpy 
ends up using STT_GNU_IFUNC in future - I think some architectures disable 
IFUNC versions of string functions in the dynamic linker, though that may 
be for code size reasons - but that's something to watch out for in future 
rather than needing addressing now.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [patch] handle unaligned arm abs relocs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1149 bytes --]

On Monday 19 December 2011 12:45:30 Joseph S. Myers wrote:
> On Mon, 12 Dec 2011, Mike Frysinger wrote:
> > +	    /* Support relocations on mis-aligned offsets.  */
> > +	    memcpy (&reloc_value, reloc_addr_arg, sizeof (reloc_value));
> > +	    reloc_value += value;
> > +	    memcpy (reloc_addr_arg, &reloc_value, sizeof (reloc_value));
> 
> It seems from the discussion that it would be useful to see exactly what
> code ends up getting generated for these memcpy calls.  Is it a function
> call or inlined?  What about all the other memcpy calls in the dynamic
> linker?  For calls to memcpy that really are function calls, do they end
> up going through the PLT, or do they end up as direct calls to the copy of
> memcpy in the dynamic linker (given that it's linked with a version script
> that hides memcpy along with all the other libc functions it uses, so it
> shouldn't be necessary for calls to go through the PLT)?

i was in the process of implementing Richard's suggestion for using a struct 
and gcc attributes.  but i'm hitting unrelated arm build failures which i'm 
trying to resolve before moving on ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [patch] handle unaligned arm abs relocs

[Joseph S. Myers]

On Mon, 19 Dec 2011, Mike Frysinger wrote:

> i was in the process of implementing Richard's suggestion for using a struct 
> and gcc attributes.  but i'm hitting unrelated arm build failures which i'm 

That's also a reasonable way of implementing things (such packed 
structures are how libgcc implements functions such as __aeabi_uread4, for 
example), though I suspect memcpy would turn out to be safe as well.

-- 
Joseph S. Myers
joseph@codesourcery.com

[PATCH v2] arm: handle unaligned ABS relocs

[Mike Frysinger]

When relocating a misaligned R_ARM_ABS32, glibc currently crashes.

URL: https://bugs.gentoo.org/394237
URL: http://gcc.gnu.org/PR51456
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

2012-08-12  Mike Frysinger  <vapier@gentoo.org>

	* sysdeps/arm/dl-machine.h (elf_machine_rel) [R_ARM_ABS32]: Declare
	a new unaligned struct.  Cast reloc_addr to that when updating the
	value it points to.
---
 ports/sysdeps/arm/dl-machine.h |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/ports/sysdeps/arm/dl-machine.h b/ports/sysdeps/arm/dl-machine.h
index fe39a5e..ca66e83 100644
--- a/ports/sysdeps/arm/dl-machine.h
+++ b/ports/sysdeps/arm/dl-machine.h
@@ -413,6 +413,10 @@ elf_machine_rel (struct link_map *map, const Elf32_Rel *reloc,
 	  break;
 	case R_ARM_ABS32:
 	  {
+	    struct unaligned
+	      {
+		Elf32_Addr x;
+	      } __attribute__((packed, may_alias));
 # ifndef RTLD_BOOTSTRAP
 	   /* This is defined in rtld.c, but nowhere in the static
 	      libc.a; make the reference weak so static programs can
@@ -431,7 +435,8 @@ elf_machine_rel (struct link_map *map, const Elf32_Rel *reloc,
 		 used while loading those libraries.  */
 	      value -= map->l_addr + refsym->st_value;
 # endif
-	    *reloc_addr += value;
+	    /* Support relocations on mis-aligned offsets.  */
+	    ((struct unaligned *) reloc_addr)->x += value;
 	    break;
 	  }
 	case R_ARM_TLS_DESC:
-- 
1.7.9.7

Re: [PATCH v2] arm: handle unaligned ABS relocs

[Joseph S. Myers]

On Sun, 12 Aug 2012, Mike Frysinger wrote:

> 2012-08-12  Mike Frysinger  <vapier@gentoo.org>
> 
> 	* sysdeps/arm/dl-machine.h (elf_machine_rel) [R_ARM_ABS32]: Declare
> 	a new unaligned struct.  Cast reloc_addr to that when updating the
> 	value it points to.

OK, presuming you've tested that this does indeed fix the described 
problem.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH v2] arm: handle unaligned ABS relocs

[Carlos O'Donell]

On Sun, Aug 12, 2012 at 1:50 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> When relocating a misaligned R_ARM_ABS32, glibc currently crashes.
>
> URL: https://bugs.gentoo.org/394237
> URL: http://gcc.gnu.org/PR51456
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
>
> 2012-08-12  Mike Frysinger  <vapier@gentoo.org>
>
>         * sysdeps/arm/dl-machine.h (elf_machine_rel) [R_ARM_ABS32]: Declare
>         a new unaligned struct.  Cast reloc_addr to that when updating the
>         value it points to.

Almost every other architecture that does this uses a char array and pulls the
data out of the char array. Why?

> ---
>  ports/sysdeps/arm/dl-machine.h |    7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/ports/sysdeps/arm/dl-machine.h b/ports/sysdeps/arm/dl-machine.h
> index fe39a5e..ca66e83 100644
> --- a/ports/sysdeps/arm/dl-machine.h
> +++ b/ports/sysdeps/arm/dl-machine.h
> @@ -413,6 +413,10 @@ elf_machine_rel (struct link_map *map, const Elf32_Rel *reloc,
>           break;
>         case R_ARM_ABS32:
>           {
> +           struct unaligned
> +             {
> +               Elf32_Addr x;
> +             } __attribute__((packed, may_alias));

Packed only says that the internals of the structure will be packed
with minimal alignment.

It doesn't say anything about the alignment of the structure itself IIRC.

Will this actually do what you want consistently and across supported
compiler versions?

As opposed to the char array method used by other machines.

>  # ifndef RTLD_BOOTSTRAP
>            /* This is defined in rtld.c, but nowhere in the static
>               libc.a; make the reference weak so static programs can
> @@ -431,7 +435,8 @@ elf_machine_rel (struct link_map *map, const Elf32_Rel *reloc,
>                  used while loading those libraries.  */
>               value -= map->l_addr + refsym->st_value;
>  # endif
> -           *reloc_addr += value;
> +           /* Support relocations on mis-aligned offsets.  */
> +           ((struct unaligned *) reloc_addr)->x += value;
>             break;
>           }
>         case R_ARM_TLS_DESC:
> --
> 1.7.9.7
>

Cheers,
Carlos.

Re: [PATCH v2] arm: handle unaligned ABS relocs

[Andreas Schwab]

"Carlos O'Donell" <carlos@systemhalted.org> writes:

> Packed only says that the internals of the structure will be packed
> with minimal alignment.
>
> It doesn't say anything about the alignment of the structure itself IIRC.

The struct inherits the alignment of the most aligned member.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH v2] arm: handle unaligned ABS relocs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 543 bytes --]

On Sunday 12 August 2012 09:00:50 Joseph S. Myers wrote:
> On Sun, 12 Aug 2012, Mike Frysinger wrote:
> > 2012-08-12  Mike Frysinger  <vapier@gentoo.org>
> > 
> > 	* sysdeps/arm/dl-machine.h (elf_machine_rel) [R_ARM_ABS32]: Declare
> > 	a new unaligned struct.  Cast reloc_addr to that when updating the
> > 	value it points to.
> 
> OK, presuming you've tested that this does indeed fix the described
> problem.

i verified it compiles warning free.  the original reporter verified it fixed the 
issue that he was seeing.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2] arm: handle unaligned ABS relocs

[Joseph S. Myers]

On Sun, 12 Aug 2012, Mike Frysinger wrote:

> On Sunday 12 August 2012 09:00:50 Joseph S. Myers wrote:
> > On Sun, 12 Aug 2012, Mike Frysinger wrote:
> > > 2012-08-12  Mike Frysinger  <vapier@gentoo.org>
> > > 
> > > 	* sysdeps/arm/dl-machine.h (elf_machine_rel) [R_ARM_ABS32]: Declare
> > > 	a new unaligned struct.  Cast reloc_addr to that when updating the
> > > 	value it points to.
> > 
> > OK, presuming you've tested that this does indeed fix the described
> > problem.
> 
> i verified it compiles warning free.  the original reporter verified it 
> fixed the issue that he was seeing.

Thanks.  The patch is OK.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH v2] arm: handle unaligned ABS relocs

[Joseph S. Myers]

On Sun, 12 Aug 2012, Carlos O'Donell wrote:

> Will this actually do what you want consistently and across supported
> compiler versions?

It's what's used in libgcc for __aeabi_uwrite4....

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH v2] arm: handle unaligned ABS relocs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 746 bytes --]

On Sunday 12 August 2012 11:55:32 Joseph S. Myers wrote:
> On Sun, 12 Aug 2012, Mike Frysinger wrote:
> > On Sunday 12 August 2012 09:00:50 Joseph S. Myers wrote:
> > > On Sun, 12 Aug 2012, Mike Frysinger wrote:
> > > > 2012-08-12  Mike Frysinger  <vapier@gentoo.org>
> > > > 
> > > > 	* sysdeps/arm/dl-machine.h (elf_machine_rel) [R_ARM_ABS32]: Declare
> > > > 	a new unaligned struct.  Cast reloc_addr to that when updating the
> > > > 	value it points to.
> > > 
> > > OK, presuming you've tested that this does indeed fix the described
> > > problem.
> > 
> > i verified it compiles warning free.  the original reporter verified it
> > fixed the issue that he was seeing.
> 
> Thanks.  The patch is OK.

pushed then
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2] arm: handle unaligned ABS relocs

[Roland McGrath]

> +		Elf32_Addr x;
> +	      } __attribute__((packed, may_alias));

We put a space between __attribute__ and ((.

Re: [PATCH v2] arm: handle unaligned ABS relocs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1276 bytes --]

On Tuesday 14 August 2012 17:48:46 Roland McGrath wrote:
> > +		Elf32_Addr x;
> > +	      } __attribute__((packed, may_alias));
> 
> We put a space between __attribute__ and ((.

committed this:
diff --git a/ports/ChangeLog.arm b/ports/ChangeLog.arm
index 6775af4..9434a53 100644
--- a/ports/ChangeLog.arm
+++ b/ports/ChangeLog.arm
@@ -1,5 +1,9 @@
 2012-08-12  Mike Frysinger  <vapier@gentoo.org>
 
+	* sysdeps/arm/dl-machine.h (elf_machine_rel) [R_ARM_ABS32]: Fix style.
+
+2012-08-12  Mike Frysinger  <vapier@gentoo.org>
+
 	* sysdeps/arm/dl-machine.h (elf_machine_rel) [R_ARM_ABS32]: Declare
 	a new unaligned struct.  Cast reloc_addr to that when updating the
 	value it points to.
diff --git a/ports/sysdeps/arm/dl-machine.h b/ports/sysdeps/arm/dl-machine.h
index ca66e83..343a83e 100644
--- a/ports/sysdeps/arm/dl-machine.h
+++ b/ports/sysdeps/arm/dl-machine.h
@@ -416,7 +416,7 @@ elf_machine_rel (struct link_map *map, const Elf32_Rel *reloc,
 	    struct unaligned
 	      {
 		Elf32_Addr x;
-	      } __attribute__((packed, may_alias));
+	      } __attribute__ ((packed, may_alias));
 # ifndef RTLD_BOOTSTRAP
 	   /* This is defined in rtld.c, but nowhere in the static
 	      libc.a; make the reference weak so static programs can

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]