Re: .comm size problem

[Nick Clifton <nickc at redhat dot com>]

Hi Svein,

> The .comm pseudo-op allocates n-bytes common area. The problem is
> that I dont want it to allocate n-bytes, but I want to allocate
> n-lwords (because of target specific reasons). What is the best
> approach to fix this:
> 
> a) Write my own custom, target specific .comm handler, which simply
> replicates the s_comm function, only multiplying its size by 4 --  
> storing the common symbols value with 4 times its original value in
> the object file.
> 
> b) Patch ld/ldlang.c (lang_one_common) to allocate times 4 bytes when
> it encounters a common symbol.

Does the tic4x port of gcc support the notion of an 8-bit object ?
Ie is "sizeof (char) == 8" ?  If so, then gcc is going to want to
create common objects in multiples of 8-bits, and you ought to allow
.comm to continue to take a multiple-of-8-bits argument.  In this case
I would recommend something like your option a) except that you should
create a new pseudo op called something like ".tic4x_comm" or
".octet_comm", which takes an number-of-octets argument, and just
change .comm so that it rounds its size up to the nearest whole number
of octets.

Note - there is no need to replicate the functionality of s_comm().
You can just change the size parameter as necessary in your own .comm
or .octet_comm implementation and then call s_comm() directly.

If you do not ever need to support 8-bit .comm directives then option
a) when it just overrides the standard .comm behavior should be OK.


I agree that option b) appears to be more aesthetically pleasing, but
it sounds as though underneath everything is still being handled in
terms of 8-bit quantities and you are just concealing this fact when
reporting information to the user.  I think a better solution would be
to admit that data is still measured in 8-bit units, even if the
target requires that *all* data sizes be a multiple of 32-bits.


> But I didnt find a "LD_DEFS" hook in configure.in to place this
> target specific definition on :(

That's because there isn't one.  There isn't one because until now
there has never been a need for one.  In general if we can keep target
specific customizations out of the linker code, it will be for the
best.

Cheers
        Nick