MIPs Unaligned Relocation Table in libstdc++.so

MIPs Unaligned Relocation Table in libstdc++.so

[Charles Hardin]

All,
 
I couldn't find an answer to this, so I apologize if this is already known...
 
For performance reasons, I instrumented the unaligned trap handler on a Linux 2.4.25 MIPs kernel to see when it was used... Oddly enough, the instrumentation triggered on application loads that were dynamically linked to libstdc++.so...
 
What I know so far... This is a cross compile environment so "mipsel-linux" is the cross compiler...
Using gcc 3.4.1
Using glibc 2.3.2
Using binutils 2.14.90.0.8
 
# mipsel-linux-objdump -R libstdc++.so | grep "[^048c] R_MIPS"
00114fe2 R_MIPS_REL32      __gxx_personality_v0
0011598d R_MIPS_REL32      __gxx_personality_v0
00115a96 R_MIPS_REL32      __gxx_personality_v0
001172b9 R_MIPS_REL32      __gxx_personality_v0
0011731a R_MIPS_REL32      __gxx_personality_v0
0011d525 R_MIPS_REL32      __gxx_personality_v0
0011d5ae R_MIPS_REL32      __gxx_personality_v0
00124be1 R_MIPS_REL32      __gxx_personality_v0
00124c42 R_MIPS_REL32      __gxx_personality_v0
0012507d R_MIPS_REL32      __gxx_personality_v0
001250fe R_MIPS_REL32      __gxx_personality_v0
00125149 R_MIPS_REL32      __gxx_personality_v0
001251a2 R_MIPS_REL32      __gxx_personality_v0
001253d1 R_MIPS_REL32      __gxx_personality_v0
00125456 R_MIPS_REL32      __gxx_personality_v0
001254ed R_MIPS_REL32      __gxx_personality_v0
001259e2 R_MIPS_REL32      __gxx_personality_v0
 
This seems to be a problem to me? and it doesn't happen on an x86 compile...
 
Any pointers are appreciated...
Charles
 
 

Re: MIPs Unaligned Relocation Table in libstdc++.so

[Ian Lance Taylor]

"Charles Hardin" <chardin@2wire.com> writes:

> I couldn't find an answer to this, so I apologize if this is already known...
>  
> For performance reasons, I instrumented the unaligned trap handler on a Linux 2.4.25 MIPs kernel to see when it was used... Oddly enough, the instrumentation triggered on application loads that were dynamically linked to libstdc++.so...
>  
> What I know so far... This is a cross compile environment so "mipsel-linux" is the cross compiler...
> Using gcc 3.4.1
> Using glibc 2.3.2
> Using binutils 2.14.90.0.8
>  
> # mipsel-linux-objdump -R libstdc++.so | grep "[^048c] R_MIPS"
> 00114fe2 R_MIPS_REL32      __gxx_personality_v0
> 0011598d R_MIPS_REL32      __gxx_personality_v0
> 00115a96 R_MIPS_REL32      __gxx_personality_v0
> 001172b9 R_MIPS_REL32      __gxx_personality_v0
> 0011731a R_MIPS_REL32      __gxx_personality_v0
> 0011d525 R_MIPS_REL32      __gxx_personality_v0
> 0011d5ae R_MIPS_REL32      __gxx_personality_v0
> 00124be1 R_MIPS_REL32      __gxx_personality_v0
> 00124c42 R_MIPS_REL32      __gxx_personality_v0
> 0012507d R_MIPS_REL32      __gxx_personality_v0
> 001250fe R_MIPS_REL32      __gxx_personality_v0
> 00125149 R_MIPS_REL32      __gxx_personality_v0
> 001251a2 R_MIPS_REL32      __gxx_personality_v0
> 001253d1 R_MIPS_REL32      __gxx_personality_v0
> 00125456 R_MIPS_REL32      __gxx_personality_v0
> 001254ed R_MIPS_REL32      __gxx_personality_v0
> 001259e2 R_MIPS_REL32      __gxx_personality_v0
>  
> This seems to be a problem to me? and it doesn't happen on an x86 compile...

I've seen this kind of misaligned access too.  While I haven't
investigated it fully, I believe the fix is to add this to
config/mips/mips.h:

#define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
  (flag_pic ? DW_EH_PE_aligned : DW_EH_PE_absptr)

You might want to see if there is a bug report in
http://gcc.gnu.org/bugzilla/ about this.

Ian

Re: MIPs Unaligned Relocation Table in libstdc++.so

[Richard Sandiford]

Ian Lance Taylor <ian@airs.com> writes:
> "Charles Hardin" <chardin@2wire.com> writes:
>> I couldn't find an answer to this, so I apologize if this is already known...
>>  
>> For performance reasons, I instrumented the unaligned trap handler on a Linux 2.4.25 MIPs kernel to see when it was used... Oddly enough, the instrumentation triggered on application loads that were dynamically linked to libstdc++.so...
>>  
>> What I know so far... This is a cross compile environment so "mipsel-linux" is the cross compiler...
>> Using gcc 3.4.1
>> Using glibc 2.3.2
>> Using binutils 2.14.90.0.8
>>  
>> # mipsel-linux-objdump -R libstdc++.so | grep "[^048c] R_MIPS"
>> 00114fe2 R_MIPS_REL32      __gxx_personality_v0
>> 0011598d R_MIPS_REL32      __gxx_personality_v0
>> 00115a96 R_MIPS_REL32      __gxx_personality_v0
>> 001172b9 R_MIPS_REL32      __gxx_personality_v0
>> 0011731a R_MIPS_REL32      __gxx_personality_v0
>> 0011d525 R_MIPS_REL32      __gxx_personality_v0
>> 0011d5ae R_MIPS_REL32      __gxx_personality_v0
>> 00124be1 R_MIPS_REL32      __gxx_personality_v0
>> 00124c42 R_MIPS_REL32      __gxx_personality_v0
>> 0012507d R_MIPS_REL32      __gxx_personality_v0
>> 001250fe R_MIPS_REL32      __gxx_personality_v0
>> 00125149 R_MIPS_REL32      __gxx_personality_v0
>> 001251a2 R_MIPS_REL32      __gxx_personality_v0
>> 001253d1 R_MIPS_REL32      __gxx_personality_v0
>> 00125456 R_MIPS_REL32      __gxx_personality_v0
>> 001254ed R_MIPS_REL32      __gxx_personality_v0
>> 001259e2 R_MIPS_REL32      __gxx_personality_v0
>>  
>> This seems to be a problem to me? and it doesn't happen on an x86 compile...
>
> I've seen this kind of misaligned access too.  While I haven't
> investigated it fully, I believe the fix is to add this to
> config/mips/mips.h:
>
> #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
>   (flag_pic ? DW_EH_PE_aligned : DW_EH_PE_absptr)
>
> You might want to see if there is a bug report in
> http://gcc.gnu.org/bugzilla/ about this.

I don't think this is a good idea.  The current situation is deliberate.
Dynamic R_MIPS_REL32 relocations don't have to be against aligned
addresses, and we get more compact unwind info by allowing the EH
data to include unaligned pointer entries.  libgcc's own unwind
routines are prepared to cope with this and will use unaligned
loads where appropriate (e.g. lwl/lwr instead of lw).  glibc's
routines are too.

As for the unaligned accesses at load time: I think glibc has had
direct support for unaligned relocations since:

2003-03-14  Alexandre Oliva  <aoliva@redhat.com>

	[...]
	* sysdeps/mips/dl-machine.h: Include sys/asm.h.
	(elf_machine_matches_host): Prevent linking of o32 and n32
	together.
	(elf_machine_dynamic): Document assumption on $gp.
	(STRINGXP, STRINGXV, STRINGV_): New macros.
	(elf_machine_load_address): Use them to stringize PTR_LA and
	PTR_SUBU.
	(ELF_DL_FRAME_SIZE, ELF_DL_SAVE_ARG_REGS,
	ELF_DL_RESTORE_ARG_REGS, IFABIO32): New macros used in...
	(_dl_runtime_resolve): Adjust it for all 3 ABIs.
	(__dl_runtime_resolve): Cast the symtab initializer to the
	right type.
	(RTLD_START): Use it.  Adjust it for all 3 ABIs.
	(elf_machine_rel): Mark as always_inline in RTLD_BOOTSTRAP.
	Handle 64-bit R_MIPS_REL composite relocation and accept
	R_MIPS_64 relocations to shift addend size to 64 bits.
	Document assumption regarding local GOT entries.  Document
	backward-compatibility departing from the ABI behavior in
	applying relocations that reference section symbols, no longer
	used.  Support relocations to mis-aligned offsets.

but that patch was too late for glibc 2.3.2.  If the use of unaligned
accesses at load time is bugging you, I'd suggest upgrading to a newer
version of glibc.  IMO, recent versions are much better for MIPS,
but YMMV of course.

Richard