Re: Objective C and STRUCTURE_SIZE_BOUNDARY

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Nick Clifton]

Hi Ovidiu,

: How is the value for arm_structure_size_bound computed? Could you point me to
: the code please?

In the file gcc/config/arm/arm.c there is a function called
arm_override_options and in this function there is  this piece of
code:

  if (structure_size_string != NULL)
    {
      int size = strtol (structure_size_string, NULL, 0);
      
      if (size == 8 || size == 32)
	arm_structure_size_boundary = size;
      else
	warning ("Structure size boundary can only be set to 8 or 32");
    }
  

Cheers
	Nick

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Ovidiu Predescu]

Hi Nick,

Hm, so basically the structure boundary is passed as a compile time option.
Does this mean that on ARM all the files linked in a program should be compiled
with the same structure boundary size? How this works? Is there a way to find
out at runtime what was the option passed to the compiler at the build time?

Greetings,
Ovidiu

On Fri, 28 May 1999 08:30:07 -0700, Nick Clifton <nickc@cygnus.com> wrote:

> Hi Ovidiu,
> 
> : How is the value for arm_structure_size_bound computed? Could you point me to
> : the code please?
> 
> In the file gcc/config/arm/arm.c there is a function called
> arm_override_options and in this function there is  this piece of
> code:
> 
>   if (structure_size_string != NULL)
>     {
>       int size = strtol (structure_size_string, NULL, 0);
>       
>       if (size == 8 || size == 32)
> 	arm_structure_size_boundary = size;
>       else
> 	warning ("Structure size boundary can only be set to 8 or 32");
>     }
>   
> 
> Cheers
> 	Nick
> 

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Philip Blundell]

>with the same structure boundary size? How this works? Is there a way to find
>out at runtime what was the option passed to the compiler at the build time?

No.  What I was thinking we could do to fix this was introduce a new constant, 
call it MAX_STRUCTURE_SIZE_BOUNDARY, that is set to the upper bound you can 
have on STRUCTURE_SIZE_BOUNDARY.  I think this should cause Objective C to 
always use the more cautious alignment (ie align to 32-bit boundaries) which 
will work regardless of what user code is doing.

p.

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Ovidiu Predescu]

On Fri, 28 May 1999 17:45:17 +0100, Philip Blundell <pb@nexus.co.uk> wrote:

> >with the same structure boundary size? How this works? Is there a way to find
> >out at runtime what was the option passed to the compiler at the build time?
> 
> No.  What I was thinking we could do to fix this was introduce a new constant, 
> call it MAX_STRUCTURE_SIZE_BOUNDARY, that is set to the upper bound you can 
> have on STRUCTURE_SIZE_BOUNDARY.  I think this should cause Objective C to 
> always use the more cautious alignment (ie align to 32-bit boundaries) which 
> will work regardless of what user code is doing.

I'm not sure I understand your statement. The Objective-C runtime library uses
that value to determine how to dynamically access structure members. If such a
structure is part of another structure then depending on the compiler option,
the ObjC runtime could try to access it aligned at either 8 or 32 bits. If we
use a 32-bit boundary, we could be wrong when the user code is compiled with a
8-bit boundary.

Ovidiu

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Ovidiu Predescu]

Hi Nick,

Hm, so basically the structure boundary is passed as a compile time option.
Does this mean that on ARM all the files linked in a program should be compiled
with the same structure boundary size? How this works? Is there a way to find
out at runtime what was the option passed to the compiler at the build time?

Greetings,
Ovidiu

On Fri, 28 May 1999 08:30:07 -0700, Nick Clifton <nickc@cygnus.com> wrote:

> Hi Ovidiu,
> 
> : How is the value for arm_structure_size_bound computed? Could you point me to
> : the code please?
> 
> In the file gcc/config/arm/arm.c there is a function called
> arm_override_options and in this function there is  this piece of
> code:
> 
>   if (structure_size_string != NULL)
>     {
>       int size = strtol (structure_size_string, NULL, 0);
>       
>       if (size == 8 || size == 32)
> 	arm_structure_size_boundary = size;
>       else
> 	warning ("Structure size boundary can only be set to 8 or 32");
>     }
>   
> 
> Cheers
> 	Nick
> 

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Nick Clifton]

Hi Ovidiu,

: How is the value for arm_structure_size_bound computed? Could you point me to
: the code please?

In the file gcc/config/arm/arm.c there is a function called
arm_override_options and in this function there is  this piece of
code:

  if (structure_size_string != NULL)
    {
      int size = strtol (structure_size_string, NULL, 0);
      
      if (size == 8 || size == 32)
	arm_structure_size_boundary = size;
      else
	warning ("Structure size boundary can only be set to 8 or 32");
    }
  

Cheers
	Nick

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Philip Blundell]

>with the same structure boundary size? How this works? Is there a way to find
>out at runtime what was the option passed to the compiler at the build time?

No.  What I was thinking we could do to fix this was introduce a new constant, 
call it MAX_STRUCTURE_SIZE_BOUNDARY, that is set to the upper bound you can 
have on STRUCTURE_SIZE_BOUNDARY.  I think this should cause Objective C to 
always use the more cautious alignment (ie align to 32-bit boundaries) which 
will work regardless of what user code is doing.

p.

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Ovidiu Predescu]

On Fri, 28 May 1999 17:45:17 +0100, Philip Blundell <pb@nexus.co.uk> wrote:

> >with the same structure boundary size? How this works? Is there a way to find
> >out at runtime what was the option passed to the compiler at the build time?
> 
> No.  What I was thinking we could do to fix this was introduce a new constant, 
> call it MAX_STRUCTURE_SIZE_BOUNDARY, that is set to the upper bound you can 
> have on STRUCTURE_SIZE_BOUNDARY.  I think this should cause Objective C to 
> always use the more cautious alignment (ie align to 32-bit boundaries) which 
> will work regardless of what user code is doing.

I'm not sure I understand your statement. The Objective-C runtime library uses
that value to determine how to dynamically access structure members. If such a
structure is part of another structure then depending on the compiler option,
the ObjC runtime could try to access it aligned at either 8 or 32 bits. If we
use a 32-bit boundary, we could be wrong when the user code is compiled with a
8-bit boundary.

Ovidiu

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Ovidiu Predescu]

That's a good idea, but what we actually need is a way to have the value
assigned to a variable inside the ObjC runtime library. Since the library is
compiled once, when you build EGCS, we need a way to change that variable in
the library depending on how the user program is compiled.

Ovidiu

On Fri, 28 May 1999 17:37:56 +0100 (BST), Joern Rennecke <amylaar@cygnus.co.uk>
 wrote:

> > : Is there a way to find out at runtime what was the option passed to
> > : the compiler at the build time?
> > 
> > Sadly no.  This feature was never really intended for widespread use.
> > Some people have found that changing the default boundary (from 32 to
> > 8) produces better code *under certain circumstances*.  The best way
> > to use this feature is to use the default value whenever possible, and
> > to only use the non-default value when speed is critical and access to
> > the affected structures can be localised to user controlled source
> > files.
> 
> Assuming you only support -mstructure_size_boundary=8 to set it to
> eight (i.e. no whitespace, zeroes, other number bases or trailing junk),
> you can do:
> #define STRUCTURE_SIZE_BOUNDARY __ARM_STRUCTURE_SIZE_BOUNDARY__
> 
> #undef __ARM_STRUCTURE_SIZE_BOUNDARY__ /* Just in caers we build a native... */
> #define __ARM_STRUCTURE_SIZE_BOUNDARY__ arm_structure_size_boundary
> 
> and in CPP_SPECS:
> 
> %{structure_size_boundary=8:!-D__ARM_STRUCTURE_SIZE_BOUNDARY__=8} \
> %{!structure_size_boundary=8:!-D__ARM_STRUCTURE_SIZE_BOUNDARY__=32} \
> 

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Ovidiu Predescu]

How is the value for arm_structure_size_bound computed? Could you point me to
the code please?

Thanks,
Ovidiu

On Fri, 28 May 1999 13:58:25 +0100, Philip Blundell <pb@nexus.co.uk> wrote:

> The function objc_layout_structure (in libobjc/encoding.c) uses 
> STRUCTURE_SIZE_BOUNDARY when deciding what the alignment of an object should 
> be.  Unfortunately on the ARM port, under some circumstances 
> STRUCTURE_SIZE_BOUNDARY is actually a variable rather than a constant.  This 
> causes any Objective C program to fail to build with errors like:
> 
> Executing on host: /localhome/build/gcc-2.95/gcc/xgcc -B/localhome/build/gcc-2.95/gcc/ /home/pb/c
> ygnus/gcc-2.95/gcc/testsuite/objc/execute/bf-1.m  -w  -O  -I/home/pb/cygnus/gcc-2.95/gcc/testsuit
> e/../../libobjc -L/localhome/build/gcc-2.95/armv4l-unknown-linux-gnu/libobjc -lobjc  -lm   -o /lo
> calhome/build/gcc-2.95/gcc/testsuite/bf-1.x
> compiler exited with status 1
> output is:
> /localhome/build/gcc-2.95/armv4l-unknown-linux-gnu/libobjc/libobjc.a(encoding.o): In function `ob
> jc_layout_structure':
> /home/pb/cygnus/gcc-2.95/libobjc/encoding.c:730: undefined reference to `arm_structure_size_bound
> ary'
> 
> I'm not sure what the right solution to this is.  Any suggestions?
> 
> p.
> 
> 
> 

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Richard Earnshaw]

ovidiu@cup.hp.com said:
> That's a good idea, but what we actually need is a way to have the
> value assigned to a variable inside the ObjC runtime library. Since
> the library is compiled once, when you build EGCS, we need a way to
> change that variable in the library depending on how the user program
> is compiled.


Strictly speaking this should be "multilibbed".  Yuck, another one.

I'm of the opinion that ABIs should pick a value and stick to it.  Playing 
with this dynamically is like playing with fire; you will get burnt 
eventually.

Richard.

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Nick Clifton]

Hi Ovidiu,

: Hm, so basically the structure boundary is passed as a compile time
: option.  Does this mean that on ARM all the files linked in a
: program should be compiled with the same structure boundary size?

Yes and no.  Stricly speaking yes, all files and libraries ought to be
compiled with the same structure boundary.  Practically speaking it
only makes a difference if a file accesses a structure which is not
local to that file, and whoes packing would be altered by this compile
time option.

: Is there a way to find out at runtime what was the option passed to
: the compiler at the build time?

Sadly no.  This feature was never really intended for widespread use.
Some people have found that changing the default boundary (from 32 to
8) produces better code *under certain circumstances*.  The best way
to use this feature is to use the default value whenever possible, and
to only use the non-default value when speed is critical and access to
the affected structures can be localised to user controlled source
files.

Cheers
	Nick

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Joern Rennecke]

> That's a good idea, but what we actually need is a way to have the value
> assigned to a variable inside the ObjC runtime library. Since the library is
> compiled once, when you build EGCS, we need a way to change that variable in
> the library depending on how the user program is compiled.

As Nick said, only small pieces of the program are supposd to be compiled
with this option, and they shouldn't be using any library functions or
other parts of the program that use structures with differing layout
in their interface.

If you really want to compile the entire program with a structure size
boundary of 8, you should build all libraries first to match the user code.

Objective C and STRUCTURE_SIZE_BOUNDARY

[Philip Blundell]

The function objc_layout_structure (in libobjc/encoding.c) uses 
STRUCTURE_SIZE_BOUNDARY when deciding what the alignment of an object should 
be.  Unfortunately on the ARM port, under some circumstances 
STRUCTURE_SIZE_BOUNDARY is actually a variable rather than a constant.  This 
causes any Objective C program to fail to build with errors like:

Executing on host: /localhome/build/gcc-2.95/gcc/xgcc -B/localhome/build/gcc-2.95/gcc/ /home/pb/cygnus/gcc-2.95/gcc/testsuite/objc/execute/bf-1.m  -w  -O  -I/home/pb/cygnus/gcc-2.95/gcc/testsuite/../../libobjc -L/localhome/build/gcc-2.95/armv4l-unknown-linux-gnu/libobjc -lobjc  -lm   -o /localhome/build/gcc-2.95/gcc/testsuite/bf-1.x
compiler exited with status 1
output is:
/localhome/build/gcc-2.95/armv4l-unknown-linux-gnu/libobjc/libobjc.a(encoding.o): In function `objc_layout_structure':
/home/pb/cygnus/gcc-2.95/libobjc/encoding.c:730: undefined reference to `arm_structure_size_boundary'

I'm not sure what the right solution to this is.  Any suggestions?

p.

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Jeffrey A Law]

  > I'm of the opinion that ABIs should pick a value and stick to it.  Playing 
  > with this dynamically is like playing with fire; you will get burnt 
  > eventually.
I couldn't agree more. 

jeff

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Joern Rennecke]

> : Is there a way to find out at runtime what was the option passed to
> : the compiler at the build time?
> 
> Sadly no.  This feature was never really intended for widespread use.
> Some people have found that changing the default boundary (from 32 to
> 8) produces better code *under certain circumstances*.  The best way
> to use this feature is to use the default value whenever possible, and
> to only use the non-default value when speed is critical and access to
> the affected structures can be localised to user controlled source
> files.

Assuming you only support -mstructure_size_boundary=8 to set it to
eight (i.e. no whitespace, zeroes, other number bases or trailing junk),
you can do:
#define STRUCTURE_SIZE_BOUNDARY __ARM_STRUCTURE_SIZE_BOUNDARY__

#undef __ARM_STRUCTURE_SIZE_BOUNDARY__ /* Just in caers we build a native... */
#define __ARM_STRUCTURE_SIZE_BOUNDARY__ arm_structure_size_boundary

and in CPP_SPECS:

%{structure_size_boundary=8:!-D__ARM_STRUCTURE_SIZE_BOUNDARY__=8} \
%{!structure_size_boundary=8:!-D__ARM_STRUCTURE_SIZE_BOUNDARY__=32} \

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Jeffrey A Law]

  > I'm of the opinion that ABIs should pick a value and stick to it.  Playing 
  > with this dynamically is like playing with fire; you will get burnt 
  > eventually.
I couldn't agree more. 

jeff

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Richard Earnshaw]

ovidiu@cup.hp.com said:
> That's a good idea, but what we actually need is a way to have the
> value assigned to a variable inside the ObjC runtime library. Since
> the library is compiled once, when you build EGCS, we need a way to
> change that variable in the library depending on how the user program
> is compiled.


Strictly speaking this should be "multilibbed".  Yuck, another one.

I'm of the opinion that ABIs should pick a value and stick to it.  Playing 
with this dynamically is like playing with fire; you will get burnt 
eventually.

Richard.

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Joern Rennecke]

> That's a good idea, but what we actually need is a way to have the value
> assigned to a variable inside the ObjC runtime library. Since the library is
> compiled once, when you build EGCS, we need a way to change that variable in
> the library depending on how the user program is compiled.

As Nick said, only small pieces of the program are supposd to be compiled
with this option, and they shouldn't be using any library functions or
other parts of the program that use structures with differing layout
in their interface.

If you really want to compile the entire program with a structure size
boundary of 8, you should build all libraries first to match the user code.

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Ovidiu Predescu]

That's a good idea, but what we actually need is a way to have the value
assigned to a variable inside the ObjC runtime library. Since the library is
compiled once, when you build EGCS, we need a way to change that variable in
the library depending on how the user program is compiled.

Ovidiu

On Fri, 28 May 1999 17:37:56 +0100 (BST), Joern Rennecke <amylaar@cygnus.co.uk>
 wrote:

> > : Is there a way to find out at runtime what was the option passed to
> > : the compiler at the build time?
> > 
> > Sadly no.  This feature was never really intended for widespread use.
> > Some people have found that changing the default boundary (from 32 to
> > 8) produces better code *under certain circumstances*.  The best way
> > to use this feature is to use the default value whenever possible, and
> > to only use the non-default value when speed is critical and access to
> > the affected structures can be localised to user controlled source
> > files.
> 
> Assuming you only support -mstructure_size_boundary=8 to set it to
> eight (i.e. no whitespace, zeroes, other number bases or trailing junk),
> you can do:
> #define STRUCTURE_SIZE_BOUNDARY __ARM_STRUCTURE_SIZE_BOUNDARY__
> 
> #undef __ARM_STRUCTURE_SIZE_BOUNDARY__ /* Just in caers we build a native... */
> #define __ARM_STRUCTURE_SIZE_BOUNDARY__ arm_structure_size_boundary
> 
> and in CPP_SPECS:
> 
> %{structure_size_boundary=8:!-D__ARM_STRUCTURE_SIZE_BOUNDARY__=8} \
> %{!structure_size_boundary=8:!-D__ARM_STRUCTURE_SIZE_BOUNDARY__=32} \
> 

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Joern Rennecke]

> : Is there a way to find out at runtime what was the option passed to
> : the compiler at the build time?
> 
> Sadly no.  This feature was never really intended for widespread use.
> Some people have found that changing the default boundary (from 32 to
> 8) produces better code *under certain circumstances*.  The best way
> to use this feature is to use the default value whenever possible, and
> to only use the non-default value when speed is critical and access to
> the affected structures can be localised to user controlled source
> files.

Assuming you only support -mstructure_size_boundary=8 to set it to
eight (i.e. no whitespace, zeroes, other number bases or trailing junk),
you can do:
#define STRUCTURE_SIZE_BOUNDARY __ARM_STRUCTURE_SIZE_BOUNDARY__

#undef __ARM_STRUCTURE_SIZE_BOUNDARY__ /* Just in caers we build a native... */
#define __ARM_STRUCTURE_SIZE_BOUNDARY__ arm_structure_size_boundary

and in CPP_SPECS:

%{structure_size_boundary=8:!-D__ARM_STRUCTURE_SIZE_BOUNDARY__=8} \
%{!structure_size_boundary=8:!-D__ARM_STRUCTURE_SIZE_BOUNDARY__=32} \

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Nick Clifton]

Hi Ovidiu,

: Hm, so basically the structure boundary is passed as a compile time
: option.  Does this mean that on ARM all the files linked in a
: program should be compiled with the same structure boundary size?

Yes and no.  Stricly speaking yes, all files and libraries ought to be
compiled with the same structure boundary.  Practically speaking it
only makes a difference if a file accesses a structure which is not
local to that file, and whoes packing would be altered by this compile
time option.

: Is there a way to find out at runtime what was the option passed to
: the compiler at the build time?

Sadly no.  This feature was never really intended for widespread use.
Some people have found that changing the default boundary (from 32 to
8) produces better code *under certain circumstances*.  The best way
to use this feature is to use the default value whenever possible, and
to only use the non-default value when speed is critical and access to
the affected structures can be localised to user controlled source
files.

Cheers
	Nick

Re: Objective C and STRUCTURE_SIZE_BOUNDARY

[Ovidiu Predescu]

How is the value for arm_structure_size_bound computed? Could you point me to
the code please?

Thanks,
Ovidiu

On Fri, 28 May 1999 13:58:25 +0100, Philip Blundell <pb@nexus.co.uk> wrote:

> The function objc_layout_structure (in libobjc/encoding.c) uses 
> STRUCTURE_SIZE_BOUNDARY when deciding what the alignment of an object should 
> be.  Unfortunately on the ARM port, under some circumstances 
> STRUCTURE_SIZE_BOUNDARY is actually a variable rather than a constant.  This 
> causes any Objective C program to fail to build with errors like:
> 
> Executing on host: /localhome/build/gcc-2.95/gcc/xgcc -B/localhome/build/gcc-2.95/gcc/ /home/pb/c
> ygnus/gcc-2.95/gcc/testsuite/objc/execute/bf-1.m  -w  -O  -I/home/pb/cygnus/gcc-2.95/gcc/testsuit
> e/../../libobjc -L/localhome/build/gcc-2.95/armv4l-unknown-linux-gnu/libobjc -lobjc  -lm   -o /lo
> calhome/build/gcc-2.95/gcc/testsuite/bf-1.x
> compiler exited with status 1
> output is:
> /localhome/build/gcc-2.95/armv4l-unknown-linux-gnu/libobjc/libobjc.a(encoding.o): In function `ob
> jc_layout_structure':
> /home/pb/cygnus/gcc-2.95/libobjc/encoding.c:730: undefined reference to `arm_structure_size_bound
> ary'
> 
> I'm not sure what the right solution to this is.  Any suggestions?
> 
> p.
> 
> 
> 

Objective C and STRUCTURE_SIZE_BOUNDARY

[Philip Blundell]

The function objc_layout_structure (in libobjc/encoding.c) uses 
STRUCTURE_SIZE_BOUNDARY when deciding what the alignment of an object should 
be.  Unfortunately on the ARM port, under some circumstances 
STRUCTURE_SIZE_BOUNDARY is actually a variable rather than a constant.  This 
causes any Objective C program to fail to build with errors like:

Executing on host: /localhome/build/gcc-2.95/gcc/xgcc -B/localhome/build/gcc-2.95/gcc/ /home/pb/cygnus/gcc-2.95/gcc/testsuite/objc/execute/bf-1.m  -w  -O  -I/home/pb/cygnus/gcc-2.95/gcc/testsuite/../../libobjc -L/localhome/build/gcc-2.95/armv4l-unknown-linux-gnu/libobjc -lobjc  -lm   -o /localhome/build/gcc-2.95/gcc/testsuite/bf-1.x
compiler exited with status 1
output is:
/localhome/build/gcc-2.95/armv4l-unknown-linux-gnu/libobjc/libobjc.a(encoding.o): In function `objc_layout_structure':
/home/pb/cygnus/gcc-2.95/libobjc/encoding.c:730: undefined reference to `arm_structure_size_boundary'

I'm not sure what the right solution to this is.  Any suggestions?

p.