Problem about gcc 4.1 + binutil 2.16.92 + glibc 2.4 + ARM EABI

Problem about gcc 4.1 + binutil 2.16.92 + glibc 2.4 + ARM EABI

[Fengwei Yin]

Hi,
When enable the gcc 4.1 with EABI support for ARM, I met such situation about
the alignment.

Here is my test case:

#include <stdio.h>
#include <stdlib.h>

struct test {
	char c1;
	long long  n;
	char c2;
};

int my_temp(void)
{
	int i;
	int j;
	char str[2];
	long long l1;
	long long l2;
	char str2;

	printf("%s:\tj address:         0x%08x, str address:    0x%08x\n",
__func__, &j, str);
	printf("%s:\tl1 address:        0x%08x, l2 address:     0x%08x\n",
__func__, &l1, &l2);
	printf("%s:\tstr2 address:      0x%08x\n", __func__, &str2);
	return 0;
}

main()
{
	struct test t;

	my_temp();

	printf("%s:\ttest.c1 address:   0x%08x\n", __func__, &(t.c1));
	printf("%s:\ttest.n address:    0x%08x\n", __func__, &(t.n));
	printf("%s:\ttest.c2 address:   0x%08x\n", __func__, &(t.c2));
}

With the gcc 4.1 + EABI for ARM(build optioni: -mabi=aapcs-linux -O2),
I get following output:

[root@Linux /test]#./test.gnu.eabi
my_temp:        j address:      0xbea85ac0, str address:        0xbea85abe
my_temp:        l1 address:     0xbea85ab0, l2 address:         0xbea85aa8
my_temp:        str2 address:   0xbea85aa7
main:   test.c1 address:        0xbea85ad8
main:   test.n address:         0xbea85ae0
main:   test.c2 address:        0xbea85ae8

With the gcc 3.4.3 without EABI(build option: -O2), I get following output:
[root@Linux /test]#./test.gnu
my_temp:        j address:      0xbeb69bf8, str address:        0xbeb69bf0
my_temp:        l1 address:     0xbeb69be8, l2 address:         0xbeb69be0
my_temp:        str2 address:   0xbeb69bdf
main:   test.c1 address:        0xbeb69c10
main:   test.n address:         0xbeb69c18
main:   test.c2 address:        0xbeb69c20

Please notice the address of the str and j. there IS NO memory hole
between therm
when using gcc 3.4.3 and there IS memory hole when using gcc 4.1. My question
is: Why there is difference there. And what is the root cause of the
difference (EABI
 or gcc update)? Is there any gcc option to make them align?


Thanks & Regards
Yin, Fengwei

Re: Problem about gcc 4.1 + binutil 2.16.92 + glibc 2.4 + ARM EABI

[Richard Earnshaw]

On Wed, 2006-05-31 at 07:58, Fengwei Yin wrote:

> int my_temp(void)
> {
> 	int i;
> 	int j;
> 	char str[2];

> 
> Please notice the address of the str and j. there IS NO memory hole
> between therm
> when using gcc 3.4.3 and there IS memory hole when using gcc 4.1. My question
> is: Why there is difference there. And what is the root cause of the
> difference (EABI
>  or gcc update)? Is there any gcc option to make them align?

This has nothing to do with the EABI.  Local variables are not laid out
on the stack in any particular order (and in many cases will never go on
the stack since they will live entirely in registers).

Please direct any follow-ups to gcc-help@gcc.gnu.org.  This is off-topic
for this list.

R.
-- 
Richard Earnshaw             Email: Richard.Earnshaw@arm.com
ARM Ltd                      Phone: +44 1223 400569 (Direct + VoiceMail)
110 Fulbourn Road            Switchboard: +44 1223 400400
Cherry Hinton                Fax: +44 1223 400410
Cambridge CB1 9NJ            Web: http://www.arm.com/
UK

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

Re: Problem about gcc 4.1 + binutil 2.16.92 + glibc 2.4 + ARM EABI

[Fengwei Yin]

Hi Richard,
Thanks for your information. I will ask for help on gcc-help@gcc.gnu.org.

But I still have question about gcc here:
The Local variables layout will impact my development. Consider
following C code:
my_test()
{
       int i;
       int j;
       char c[7];
       int *tmp;

      tmp = (int *) c;
      *tmp = j;
      ....
}
I don't think the local variables will be in register. So the code
"*tmp = j;" cause the
align exception in some situation if use the 4.1 toolchain. If I am
wrong, please
correct me. Thanks a lot.


Regards
Yin, Fengwei

On 5/31/06, Richard Earnshaw <Richard.Earnshaw@arm.com> wrote:
> On Wed, 2006-05-31 at 07:58, Fengwei Yin wrote:
>
> > int my_temp(void)
> > {
> >       int i;
> >       int j;
> >       char str[2];
>
> >
> > Please notice the address of the str and j. there IS NO memory hole
> > between therm
> > when using gcc 3.4.3 and there IS memory hole when using gcc 4.1. My question
> > is: Why there is difference there. And what is the root cause of the
> > difference (EABI
> >  or gcc update)? Is there any gcc option to make them align?
>
> This has nothing to do with the EABI.  Local variables are not laid out
> on the stack in any particular order (and in many cases will never go on
> the stack since they will live entirely in registers).
>
> Please direct any follow-ups to gcc-help@gcc.gnu.org.  This is off-topic
> for this list.
>
> R.
> --
> Richard Earnshaw             Email: Richard.Earnshaw@arm.com
> ARM Ltd                      Phone: +44 1223 400569 (Direct + VoiceMail)
> 110 Fulbourn Road            Switchboard: +44 1223 400400
> Cherry Hinton                Fax: +44 1223 400410
> Cambridge CB1 9NJ            Web: http://www.arm.com/
> UK
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
>
>
>

Re: Problem about gcc 4.1 + binutil 2.16.92 + glibc 2.4 + ARM EABI

[Joe Buck]

On Thu, Jun 01, 2006 at 09:29:08AM +0800, Fengwei Yin wrote:
> Hi Richard,
> Thanks for your information. I will ask for help on gcc-help@gcc.gnu.org.

OK, great.

> But I still have question about gcc here:

Um, you're still here?  Please don't ask more questions here.
Your questions reveal that you are a beginning C programmer with
fundamental misunderstandings about the language.  It's not appropriate to
take up time on the compiler developers' list so people take time away
from developing the compiler to teach you the C language.