Ian Lance Taylor <ian@xxxxxxxx> writes: > "Charles Hardin" <chardin@xxxxxxxxx> 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@xxxxxxxxxx> [...] * 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
