.comm size problem

[Svein E. Seldal]

Hello,

I'm a bit fresh binutils programmer, so you'll all excuse me for asking 
many questions...

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.

(BTW! All this applies to the tic4x target only.)

I like b) best, despite its global impacts compared to a), because when 
someone dumps an object file with nm, they will expect to get the same 
literal number listed on the common symbol as they have used in the 
source file. Another significant reason to do is this way, is because 
all binutils tools, e.g. objdump -h, dumps section sizes and such in 
terms of lwords, not bytes.

I planned on using a -DCOMMON_OCTETS_PER_BYTE definition for the tic4x 
target to override the default def, similar to the OBJDUMP_DEFS path I 
recently have committed. But I didnt find a "LD_DEFS" hook in 
configure.in to place this target specific definition on :( -- I was 
hoping things were done similar both places - but no. Can someone help 
me out with this? Where and how is the prefered method of placing this 
target specific compile definition in ld?

I have attached a possible solution, yet still incomplete. And I am 
*very* open to suggestions and comments.


Thanks
Svein
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ld_fix.diff
URL: <https://sourceware.org/pipermail/binutils/attachments/20021023/cd5f147f/attachment.ksh>