* unaligned accesses in apply_relocate_add @ 2009-08-26 8:37 Artem Alimarine 2009-08-26 13:17 ` Kyle McMartin 0 siblings, 1 reply; 6+ messages in thread From: Artem Alimarine @ 2009-08-26 8:37 UTC (permalink / raw) To: linux-parisc [-- Attachment #1: Type: text/plain, Size: 196 bytes --] Hi guys, I see unaligned access happening in apply_relocate_add. Is this normal expected behavior? Kernel 2.6.26.2, single CPU (Standard Debian 5.0.2). Address 0x4011f968. Best regards, Artem [-- Attachment #2: artem_alimarine.vcf --] [-- Type: text/x-vcard, Size: 283 bytes --] begin:vcard fn:dr. Artem Alimarine n:Alimarine;Artem org:STROMASYS SA adr:;;De Zaale 11;Eindhoven;;5612AJ;The Netherlands email;internet:artem.alimarine@stromasys.com title:Software Architect tel;work:+31-40-2390863 tel;fax:+31-40-2390800 x-mozilla-html:FALSE version:2.1 end:vcard ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: unaligned accesses in apply_relocate_add 2009-08-26 8:37 unaligned accesses in apply_relocate_add Artem Alimarine @ 2009-08-26 13:17 ` Kyle McMartin 2009-08-26 14:41 ` Artem Alimarine 0 siblings, 1 reply; 6+ messages in thread From: Kyle McMartin @ 2009-08-26 13:17 UTC (permalink / raw) To: Artem Alimarine; +Cc: linux-parisc On Wed, Aug 26, 2009 at 10:37:13AM +0200, Artem Alimarine wrote: > Hi guys, > > I see unaligned access happening in apply_relocate_add. Is this normal > expected behavior? > > Kernel 2.6.26.2, single CPU (Standard Debian 5.0.2). Address 0x4011f968. > No, definitely not. relocations are applied to instructions, which should always be instruction-width (4 bytes) aligned... Since we do modify-replace on placeholders, it should never be using anything other than a store-word to do it... do you have any more data on this? regards, Kyle ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: unaligned accesses in apply_relocate_add 2009-08-26 13:17 ` Kyle McMartin @ 2009-08-26 14:41 ` Artem Alimarine 2009-08-28 18:42 ` Grant Grundler 0 siblings, 1 reply; 6+ messages in thread From: Artem Alimarine @ 2009-08-26 14:41 UTC (permalink / raw) To: Kyle McMartin; +Cc: linux-parisc [-- Attachment #1: Type: text/plain, Size: 2418 bytes --] One point is that in the function apply_relocate_add a 4-byte aligned address is created: 627 dot = (Elf64_Addr)loc & ~0x03; 628 loc64 = (Elf64_Xword *)loc; and used as a 64-bit location 711 case R_PARISC_DIR64: 712 /* 64-bit effective address */ 713 *loc64 = val + addend; 714 break; So, 8-byte word is read with a 4-byte alignment. I am busy building a parisc hardware emulator. It boots Linux, but it is unstable yet. There are unaligned accesses in the emulation trace. I was wandering whether it is normal behavior or caused by a bug in the emulation. The emulation trace gives a lot of accesses like this: 0-4011f968: translate_virtual_write unaligned_trap, va=0:416a20c pa=1db1820c 0-4011f968: translate_virtual_write unaligned_trap, va=0:416a21c pa=1db1821c 0-4011f968: translate_virtual_write unaligned_trap, va=0:416a224 pa=1db18224 They are indeed 4-byte aligned. The PC address matches apply_relocate_add in the kernel map. Thanks, Artem Kyle McMartin wrote: > On Wed, Aug 26, 2009 at 10:37:13AM +0200, Artem Alimarine wrote: > >> Hi guys, >> >> I see unaligned access happening in apply_relocate_add. Is this >> normal expected behavior? >> >> Kernel 2.6.26.2, single CPU (Standard Debian 5.0.2). Address 0x4011f968. >> >> > > No, definitely not. relocations are applied to instructions, which > should always be instruction-width (4 bytes) aligned... Since we do > modify-replace on placeholders, it should never be using anything other > than a store-word to do it... do you have any more data on this? > > regards, Kyle > > dr. Artem Alimarine <artem.alimarine@stromasys.com <mailto:artem.alimarine@stromasys.com>> Software Architect STROMASYS SA Kyle McMartin wrote: > On Wed, Aug 26, 2009 at 10:37:13AM +0200, Artem Alimarine wrote: > >> Hi guys, >> >> I see unaligned access happening in apply_relocate_add. Is this normal >> expected behavior? >> >> Kernel 2.6.26.2, single CPU (Standard Debian 5.0.2). Address 0x4011f968. >> >> > > No, definitely not. relocations are applied to instructions, which > should always be instruction-width (4 bytes) aligned... Since we do > modify-replace on placeholders, it should never be using anything other > than a store-word to do it... do you have any more data on this? > > regards, Kyle > > [-- Attachment #2: artem_alimarine.vcf --] [-- Type: text/x-vcard, Size: 283 bytes --] begin:vcard fn:dr. Artem Alimarine n:Alimarine;Artem org:STROMASYS SA adr:;;De Zaale 11;Eindhoven;;5612AJ;The Netherlands email;internet:artem.alimarine@stromasys.com title:Software Architect tel;work:+31-40-2390863 tel;fax:+31-40-2390800 x-mozilla-html:FALSE version:2.1 end:vcard ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: unaligned accesses in apply_relocate_add 2009-08-26 14:41 ` Artem Alimarine @ 2009-08-28 18:42 ` Grant Grundler 2009-08-28 18:58 ` John David Anglin 2009-09-04 22:37 ` Artem Alimarine 0 siblings, 2 replies; 6+ messages in thread From: Grant Grundler @ 2009-08-28 18:42 UTC (permalink / raw) To: Artem Alimarine; +Cc: Kyle McMartin, linux-parisc On Wed, Aug 26, 2009 at 04:41:20PM +0200, Artem Alimarine wrote: > One point is that in the function apply_relocate_add a 4-byte aligned > address is created: > > 627 dot = (Elf64_Addr)loc & ~0x03; > 628 loc64 = (Elf64_Xword *)loc; > > and used as a 64-bit location > > 711 case R_PARISC_DIR64: > 712 /* 64-bit effective address */ > 713 *loc64 = val + addend; > 714 break; > > So, 8-byte word is read with a 4-byte alignment. Perhaps this is expected to be an 8byte address pointing at a 4-byte word? (and it's a bug that ist's not) > I am busy building a parisc hardware emulator. It boots Linux, but it is > unstable yet. There are unaligned accesses in the emulation trace. I was > wandering whether it is normal behavior or caused by a bug in the > emulation. HP has such an emulator. I've even tried to boot parisc-linux on it (failed) ~8 years ago. Any chance someone from HP could publish it? You might also look at Aries PA-RISC emulator (on ia64): http://www.princeton.edu/~rblee/ELE572Papers/PARISCtoIA64.htm > The emulation trace gives a lot of accesses like this: > 0-4011f968: translate_virtual_write unaligned_trap, va=0:416a20c > pa=1db1820c > 0-4011f968: translate_virtual_write unaligned_trap, va=0:416a21c > pa=1db1821c > 0-4011f968: translate_virtual_write unaligned_trap, va=0:416a224 > pa=1db18224 > > They are indeed 4-byte aligned. The PC address matches > apply_relocate_add in the kernel map. *nod* thanks, grant ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: unaligned accesses in apply_relocate_add 2009-08-28 18:42 ` Grant Grundler @ 2009-08-28 18:58 ` John David Anglin 2009-09-04 22:37 ` Artem Alimarine 1 sibling, 0 replies; 6+ messages in thread From: John David Anglin @ 2009-08-28 18:58 UTC (permalink / raw) To: Grant Grundler; +Cc: artem.alimarine, kyle, linux-parisc > On Wed, Aug 26, 2009 at 04:41:20PM +0200, Artem Alimarine wrote: > > One point is that in the function apply_relocate_add a 4-byte aligned > > address is created: > > > > 627 dot = (Elf64_Addr)loc & ~0x03; > > 628 loc64 = (Elf64_Xword *)loc; > > > > and used as a 64-bit location > > > > 711 case R_PARISC_DIR64: > > 712 /* 64-bit effective address */ > > 713 *loc64 = val + addend; > > 714 break; > > > > So, 8-byte word is read with a 4-byte alignment. > > Perhaps this is expected to be an 8byte address pointing at a 4-byte word? > (and it's a bug that ist's not) No, R_PARISC_DIR64 is a 64-bit reloacation. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: unaligned accesses in apply_relocate_add 2009-08-28 18:42 ` Grant Grundler 2009-08-28 18:58 ` John David Anglin @ 2009-09-04 22:37 ` Artem Alimarine 1 sibling, 0 replies; 6+ messages in thread From: Artem Alimarine @ 2009-09-04 22:37 UTC (permalink / raw) To: linux-parisc [-- Attachment #1: Type: text/plain, Size: 597 bytes --] > You might also look at Aries PA-RISC emulator (on ia64): > http://www.princeton.edu/~rblee/ELE572Papers/PARISCtoIA64.htm > Thanks for the reference. There is also a HPPA version of QEMU. Unlike them we emulate the whole system hardware. At this moment it is an rp24xx system including the ASTRO/ELROY stuff and the NCR SCSI controller. We will also add a DE500 ethernet. This means that you can install Linux from an ISO image in the emulator like you normally install your system from a CD. The goal is to run MPE eventually. Our emulator runs on PC x64 in Windows (shame on me). [-- Attachment #2: artem_alimarine.vcf --] [-- Type: text/x-vcard, Size: 283 bytes --] begin:vcard fn:dr. Artem Alimarine n:Alimarine;Artem org:STROMASYS SA adr:;;De Zaale 11;Eindhoven;;5612AJ;The Netherlands email;internet:artem.alimarine@stromasys.com title:Software Architect tel;work:+31-40-2390863 tel;fax:+31-40-2390800 x-mozilla-html:FALSE version:2.1 end:vcard ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-09-04 22:37 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-08-26 8:37 unaligned accesses in apply_relocate_add Artem Alimarine 2009-08-26 13:17 ` Kyle McMartin 2009-08-26 14:41 ` Artem Alimarine 2009-08-28 18:42 ` Grant Grundler 2009-08-28 18:58 ` John David Anglin 2009-09-04 22:37 ` Artem Alimarine
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).