unaligned accesses in apply_relocate_add

unaligned accesses in apply_relocate_add

[Artem Alimarine]

[-- 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

Re: unaligned accesses in apply_relocate_add

[Kyle McMartin]

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

Re: unaligned accesses in apply_relocate_add

[Artem Alimarine]

[-- 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

Re: unaligned accesses in apply_relocate_add

[Grant Grundler]

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

Re: unaligned accesses in apply_relocate_add

[John David Anglin]

> 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)

Re: unaligned accesses in apply_relocate_add

[Artem Alimarine]

[-- 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