Problem creating COMMON section with ELF
Brought to you by:
japheth
Menu
▾
▴
#34 Problem creating COMMON section with ELF
Perhaps I just cant figure out how to do this, but I have some code I'm porting that contains the following:
_End segment dword common '_pli_End' ; Label variable for exit0020718
_PLI_End equ $ ; 20020718
; dd 0 ; 20020718
; dd 0 ; 20020718
org _pli_End+8
_End ends ; 20020718
(Tried as shown, and also without the org but with the two DD's uncommented and got the same results. ) In either case the symbol _pli_End is defined with local rather than global visibility, and isn't flagged as 'COMMON'. The 'readelf' output is attached.
This is a working program that I'm trying to port to Linux. It was originally compiled with IBM's 'ALP' assembler for OS/2 (MASM compatible). I've been playing around with the output of my PL/I compiler that thi is supposed to interface with, and think I've finally cot COMMON figured out if I can get past this problem.
readelf output
Hi,
the section combine-type 'COMMON' is pretty tightly bound to the OMF output format. If -coff is set, Masm ignores this attribute. JWasm does similar - for both COFF and ELF.
One could try to translate the 'COMMON' combine-type to something vaguely similar in COFF (using COFF's COMDAT attribute), and perhaps there's also something which can be used in ELF for this purpose. However, I'd prefer the way which Masm v8 has taken: to extend the SEGMENT syntax with keywords specific to COFF / ELF. This isn't done yet.
About _pli_End: if you want to make this symbol global, you'll have to add a PUBLIC directive for it.
japheth
I guess I can work around it; I don't have that much assembler to bother about anyway. You're right - elf (or maybe ld) does a terrible job handling common.
I spent over a week on this, and what I finely wound up doing was creating an elf section for the segment, PROGBITS if initialized, NOBITS if uninitialized, where the 'class' from the segment directive is the section name. Then I create a global object of the same name and length as 'SHN_COMMON'. This *seems* to be working: ld is commoning the sections correctly, and resolving the references to the symbol to the common data. So far, the only oddity I see is that if the common data is initialized in multiple programs, ld stores multiple copies of the data but only actually uses one of them to resolve all references.
Getting back to JWASM, I guess I can just declare (unitialized) common data as 'extern' and ld will resolve it correctly. I need to do more testing to verify that this works. I don't think I can use initialized data declared 'public' because this won't be commoned with other declarations of the data. The optional assembler the compiler generates won't be usable with JWASM.
I should take a look at what wlink is doing with elf and Linux. Maybe they do a better job than ld.
After a lot of research, I found out that ld now has an '--allow-multiple-definition' switch. Finally everything is working using EXTERN in my assembler code By the way, I checked out wlink for elf. It has an option "op red" that allows redefinitions of symbols, but unfortunately it keeps both (separate).
BTW, my previous note wasn't quite correct. I generate the name as a common symbol in all cases, and also as a global object if it is initialized.
JWASM is a very handy tool! Thanks for your work. The Watcom code is so interwoven that I have trouble making heads or tails out of it.