[Linux-ia64] do me a favor

[Linux-ia64] do me a favor

[Qiu HongBing]

Hi,

I'm Qiu HongBing. Now I process some project from IA32 to IA64 on Linux. Now
I have one question. If someone know it why and have spare time, Please help
me.Thanks a lot.

My problem is as follows:

struct aa{
unsigned short a;
unsigned short b;
unsigned short c;
unsigned short d;
unsigned int e;
unsigned int f;
unsigned int g;
unsigned int h;
unsigned short i;
}
...
struct aa *a1;
...

fun1(char *,unsigned int *,char *,char *,unsigned int * temp,unsigned int *)
{
...
*temp\x10;
...
}
...

fun1(a,b,c,d,&a1->b,e);
...

On IA64 Linux RedHat 7.1(2.4.3-3), when the program run to
fun1(a,b,c,d,&a1->b,e), the kernel write into syslog some message which is
"Nov  5 10:12:02 sdv2 kernel: ESMmlx(7837): unaligned access to
0x600000000001684c, ip=0x2000000000624370".

But if I modify the source as follows and it is OK. I dont know why. So I
want to get some help to solve the real cause.

...
{
    unsigned int tt;
    tt¡->b;

    fun1(a,b,c,d,&a1->b,e);

    a1->b=tt;
}
...

    That's all.

Re: [Linux-ia64] do me a favor

[Dan Pop]

On Tue, 13 Nov 2001, Qiu HongBing wrote:

> My problem is as follows:
> 
> struct aa{
> unsigned short a;
> unsigned short b;
> unsigned short c;
> unsigned short d;
> unsigned int e;
> unsigned int f;
> unsigned int g;
> unsigned int h;
> unsigned short i;
> }
> ...
> struct aa *a1;
> ...
> 
> fun1(char *,unsigned int *,char *,char *,unsigned int * temp,unsigned int *)
> {
> ...
> *temp\x10;
> ...
> }
> ...
> 
> fun1(a,b,c,d,&a1->b,e);
> ...
> 
> On IA64 Linux RedHat 7.1(2.4.3-3), when the program run to
> fun1(a,b,c,d,&a1->b,e), the kernel write into syslog some message which is
> "Nov  5 10:12:02 sdv2 kernel: ESMmlx(7837): unaligned access to
> 0x600000000001684c, ip=0x2000000000624370".

The reason is obvious: fun1 expects temp to be a pointer to unsigned
int, but you're passing it &a1->b, which is a pointer to unsigned
short.  The compiler should have actually warned you about that.

> But if I modify the source as follows and it is OK. I dont know why. So I
> want to get some help to solve the real cause.

Then, either define the b member as unsigned int, or the temp
parameter as pointer to unsigned short.

Dan

Re: [Linux-ia64] do me a favor

[Qiu HongBing]

But next example happened same.

...
newtComponent newtEntry(int left, int top, const char* initialValue, int
width, char** resultPtr,int flags);
...

char d[20][20];
...
entry[2]=newtEntry(-1,-1,d[2],10,(char**)&d[11],NEWT_ENTRY_SCROLL);--->>outp
ut the unaligned access
...
entry[3]=newtEntry(-1,-1,d[7],10,(char**)&d[16],NEWT_ENTRY_SCROLL);
...


but , If I changed it to as follows and it is OK.

...
newtComponent newtEntry9int left, int top, const char* initialValue, int
width, char** resultPtr,int flags);
...

char d[20][20];
...
{
char temp[20];
sprintf(temp,"%s",d[11]);
entry[2]=newtEntry(-1,-1,d[2],10,(char**)&temp/*&d[11]*/,NEWT_ENTRY_SCROLL);
sprintf(d[11],"%s",temp);
}
...
entry[3]=newtEntry(-1,-1,d[7],10,(char**)&d[16],NEWT_ENTRY_SCROLL);
...

I want to know why.
That's all.
Thanks.

        --Qiu HongBing


----- Original Message -----
From: "Dan Pop" <Dan.Pop@cern.ch>
To: "Qiu HongBing" <qiuhb@necas.nec.co.jp>
Cc: <linux-ia64@linuxia64.org>
Sent: Tuesday, November 13, 2001 9:20 AM
Subject: Re: [Linux-ia64] do me a favor


>
>
> On Tue, 13 Nov 2001, Qiu HongBing wrote:
>
> > My problem is as follows:
> >
> > struct aa{
> > unsigned short a;
> > unsigned short b;
> > unsigned short c;
> > unsigned short d;
> > unsigned int e;
> > unsigned int f;
> > unsigned int g;
> > unsigned int h;
> > unsigned short i;
> > }
> > ...
> > struct aa *a1;
> > ...
> >
> > fun1(char *,unsigned int *,char *,char *,unsigned int * temp,unsigned
int *)
> > {
> > ...
> > *temp\x10;
> > ...
> > }
> > ...
> >
> > fun1(a,b,c,d,&a1->b,e);
> > ...
> >
> > On IA64 Linux RedHat 7.1(2.4.3-3), when the program run to
> > fun1(a,b,c,d,&a1->b,e), the kernel write into syslog some message which
is
> > "Nov  5 10:12:02 sdv2 kernel: ESMmlx(7837): unaligned access to
> > 0x600000000001684c, ip=0x2000000000624370".
>
> The reason is obvious: fun1 expects temp to be a pointer to unsigned
> int, but you're passing it &a1->b, which is a pointer to unsigned
> short.  The compiler should have actually warned you about that.
>
> > But if I modify the source as follows and it is OK. I dont know why. So
I
> > want to get some help to solve the real cause.
>
> Then, either define the b member as unsigned int, or the temp
> parameter as pointer to unsigned short.
>
> Dan
>
>

RE: [Linux-ia64] do me a favor

[Tom King]

temp will be aligned when storage is allocated for it
d[16] just happens to work because it is aligned
any address that is not divisible by 8 can be considered unaligned

Tom

-----Original Message-----
From: Qiu HongBing [mailto:qiuhb@necas.nec.co.jp]
Sent: Tuesday, November 13, 2001 12:59 PM
To: Dan Pop
Cc: linux-ia64@linuxia64.org
Subject: Re: [Linux-ia64] do me a favor


But next example happened same.

...
newtComponent newtEntry(int left, int top, const char* initialValue, int
width, char** resultPtr,int flags);
...

char d[20][20];
...
entry[2]=newtEntry(-1,-1,d[2],10,(char**)&d[11],NEWT_ENTRY_SCROLL);--->>outp
ut the unaligned access
...
entry[3]=newtEntry(-1,-1,d[7],10,(char**)&d[16],NEWT_ENTRY_SCROLL);
...


but , If I changed it to as follows and it is OK.

...
newtComponent newtEntry9int left, int top, const char* initialValue, int
width, char** resultPtr,int flags);
...

char d[20][20];
...
{
char temp[20];
sprintf(temp,"%s",d[11]);
entry[2]=newtEntry(-1,-1,d[2],10,(char**)&temp/*&d[11]*/,NEWT_ENTRY_SCROLL);
sprintf(d[11],"%s",temp);
}
...
entry[3]=newtEntry(-1,-1,d[7],10,(char**)&d[16],NEWT_ENTRY_SCROLL);
...

I want to know why.
That's all.
Thanks.

        --Qiu HongBing


----- Original Message -----
From: "Dan Pop" <Dan.Pop@cern.ch>
To: "Qiu HongBing" <qiuhb@necas.nec.co.jp>
Cc: <linux-ia64@linuxia64.org>
Sent: Tuesday, November 13, 2001 9:20 AM
Subject: Re: [Linux-ia64] do me a favor


>
>
> On Tue, 13 Nov 2001, Qiu HongBing wrote:
>
> > My problem is as follows:
> >
> > struct aa{
> > unsigned short a;
> > unsigned short b;
> > unsigned short c;
> > unsigned short d;
> > unsigned int e;
> > unsigned int f;
> > unsigned int g;
> > unsigned int h;
> > unsigned short i;
> > }
> > ...
> > struct aa *a1;
> > ...
> >
> > fun1(char *,unsigned int *,char *,char *,unsigned int * temp,unsigned
int *)
> > {
> > ...
> > *temp\x10;
> > ...
> > }
> > ...
> >
> > fun1(a,b,c,d,&a1->b,e);
> > ...
> >
> > On IA64 Linux RedHat 7.1(2.4.3-3), when the program run to
> > fun1(a,b,c,d,&a1->b,e), the kernel write into syslog some message which
is
> > "Nov  5 10:12:02 sdv2 kernel: ESMmlx(7837): unaligned access to
> > 0x600000000001684c, ip=0x2000000000624370".
>
> The reason is obvious: fun1 expects temp to be a pointer to unsigned
> int, but you're passing it &a1->b, which is a pointer to unsigned
> short.  The compiler should have actually warned you about that.
>
> > But if I modify the source as follows and it is OK. I dont know why. So
I
> > want to get some help to solve the real cause.
>
> Then, either define the b member as unsigned int, or the temp
> parameter as pointer to unsigned short.
>
> Dan
>
>



_______________________________________________
Linux-IA64 mailing list
Linux-IA64@linuxia64.org
http://lists.linuxia64.org/lists/listinfo/linux-ia64

Re: [Linux-ia64] do me a favor

[Qiu HongBing]

Excuse me,
But I want to avoid this problem. How to do?
Thanks.

    --Qiu HongBing


> temp will be aligned when storage is allocated for it
> d[16] just happens to work because it is aligned
> any address that is not divisible by 8 can be considered unaligned
>
> But next example happened same.
>
> char d[20][20];
> ...
>
entry[2]=newtEntry(-1,-1,d[2],10,(char**)&d[11],NEWT_ENTRY_SCROLL);--->>outp
> ut the unaligned access
>
> but , If I changed it to as follows and it is OK.
>
>
> char d[20][20];
> ...
> {
> char temp[20];
> sprintf(temp,"%s",d[11]);
>
entry[2]=newtEntry(-1,-1,d[2],10,(char**)&temp/*&d[11]*/,NEWT_ENTRY_SCROLL);
> sprintf(d[11],"%s",temp);
> }
> ...
>
> I want to know why.
> That's all.
> Thanks.
>
> >
> > > My problem is as follows:
> > >
> > > struct aa{
> > > unsigned short a;
> > > unsigned short b;
> > > unsigned short c;
> > > unsigned short d;
> > > unsigned int e;
> > > unsigned int f;
> > > unsigned int g;
> > > unsigned int h;
> > > unsigned short i;
> > > }
> > > ...
> > > struct aa *a1;
> > > ...
> > >
> > > fun1(char *,unsigned int *,char *,char *,unsigned int * temp,unsigned
> int *)
> > > {
> > > ...
> > > *temp\x10;
> > > ...
> > > }
> > > ...
> > >
> > > fun1(a,b,c,d,&a1->b,e);
> > > ...
> > >
> > > On IA64 Linux RedHat 7.1(2.4.3-3), when the program run to
> > > fun1(a,b,c,d,&a1->b,e), the kernel write into syslog some message
which
> is
> > > "Nov  5 10:12:02 sdv2 kernel: ESMmlx(7837): unaligned access to
> > > 0x600000000001684c, ip=0x2000000000624370".
> >
> > The reason is obvious: fun1 expects temp to be a pointer to unsigned
> > int, but you're passing it &a1->b, which is a pointer to unsigned
> > short.  The compiler should have actually warned you about that.
> >
> > > But if I modify the source as follows and it is OK. I dont know why.
So
> I
> > > want to get some help to solve the real cause.
> >
> > Then, either define the b member as unsigned int, or the temp
> > parameter as pointer to unsigned short.
> >
> > Dan
> >
> >

Re: [Linux-ia64] do me a favor

[Andreas Schwab]

"Qiu HongBing" <qiuhb@necas.nec.co.jp> writes:

|> Excuse me,
|> But I want to avoid this problem. How to do?

Your code has never been portable.  You can't just do that.  FWIW, on a
sparc it will just crash, because unaligned accesses are strictly
forbidden.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: [Linux-ia64] do me a favor

[Qiu HongBing]

But I test on ItaniumTM, It work normally only output unaligned access. I
think it maybe gcc compile options not to use strict-align option. My
environment is ASUZU Machine to NEC.

I only want to know how to avoid to write into syslog that messages.
most of our source finished porting and now we are testing it and found this
problem.
Please help me.

--Qiu HongBing
----- Original Message -----
From: "Andreas Schwab" <schwab@suse.de>
To: "Qiu HongBing" <qiuhb@necas.nec.co.jp>
Cc: "Tom King" <Tom.King@bullant.com>; "Dan Pop" <Dan.Pop@cern.ch>;
<linux-ia64@linuxia64.org>
Sent: Tuesday, November 13, 2001 6:04 PM
Subject: Re: [Linux-ia64] do me a favor


> "Qiu HongBing" <qiuhb@necas.nec.co.jp> writes:
>
> |> Excuse me,
> |> But I want to avoid this problem. How to do?
>
> Your code has never been portable.  You can't just do that.  FWIW, on a
> sparc it will just crash, because unaligned accesses are strictly
> forbidden.
>
> Andreas.
>
> --
> Andreas Schwab                                  "And now for something
> Andreas.Schwab@suse.de completely different."
> SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
>

Re: [Linux-ia64] do me a favor

[Andreas Schwab]

"Qiu HongBing" <qiuhb@necas.nec.co.jp> writes:

|> But I test on ItaniumTM, It work normally only output unaligned access. I
|> think it maybe gcc compile options not to use strict-align option. My
|> environment is ASUZU Machine to NEC.
|> 
|> I only want to know how to avoid to write into syslog that messages.

Align the memory accesses.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: [Linux-ia64] do me a favor

[n0ano]

Qiu-

The fact that your code works does not mean that it is completely
correct, it's not.  Some architectures (IA32) silently allow unaligned
access (although there is a performance penality for doing this),
some architectures (IA64) verbosely allow unaligned accesses (with
a significant performance penality) and other architectures (Sparc)
don't allow unaligned accesses at all.

The way to avoid an unaligned access is actually very simple.  Don't
cast a pointer to one type into a pointer to another type.  For example,
this code:

	{
		int i, *ip;

		ip = &i;
		return(*ip);
	}

will not generate an unaligned access whereas this code:

	{
		short s;
		int *ip;

		ip = (int *)&s;
		return(*ip);
	}

will.  If you analyze your code carefully you'll discover that it's
doing something similar to the second example.

On Tue, Nov 13, 2001 at 06:11:44PM +0800, Qiu HongBing wrote:
> But I test on ItaniumTM, It work normally only output unaligned access. I
> think it maybe gcc compile options not to use strict-align option. My
> environment is ASUZU Machine to NEC.
> 
> I only want to know how to avoid to write into syslog that messages.
> most of our source finished porting and now we are testing it and found this
> problem.
> Please help me.
> 
> --Qiu HongBing
> ----- Original Message -----
> From: "Andreas Schwab" <schwab@suse.de>
> To: "Qiu HongBing" <qiuhb@necas.nec.co.jp>
> Cc: "Tom King" <Tom.King@bullant.com>; "Dan Pop" <Dan.Pop@cern.ch>;
> <linux-ia64@linuxia64.org>
> Sent: Tuesday, November 13, 2001 6:04 PM
> Subject: Re: [Linux-ia64] do me a favor
> 
> 
> > "Qiu HongBing" <qiuhb@necas.nec.co.jp> writes:
> >
> > |> Excuse me,
> > |> But I want to avoid this problem. How to do?
> >
> > Your code has never been portable.  You can't just do that.  FWIW, on a
> > sparc it will just crash, because unaligned accesses are strictly
> > forbidden.
> >
> > Andreas.
> >
> > --
> > Andreas Schwab                                  "And now for something
> > Andreas.Schwab@suse.de completely different."
> > SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
> > Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> >
> 
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@indstorage.com
Ph: 303/652-0870x117