This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: What are the differences between HP's COMMON and ANSI_COMMON?


> I am currently working on ia64-hp-hpux* linker. So far I've already managed to compile GCC
> 4.3.3, but Dave Korn noticed, that there might be a problem in LD that it does not handle
> ANSI_COMMON symbols correctly. That is why they appear in *ABS* section.
>
> So I wanted to ask anybody to explain me, what is the difference between these two symbols in HP and what should I expect on output?

I answered this briefly in another thread.

In K&R C, a tentative declaration such as "int i;" is typically
treated as a common symbol, using the special section type SHN_COMMON.
A normal common symbol would not cause the linker to include an
archive member from a library just to satisfy an unsatisfied reference
to that symbol (although the linker would silently upgrade the
unsatisfied symbol to a common definition in that case).

When ANSI C came along, the declaration "int i;" was supposed to be
treated exactly the same as "int i = 0;" -- in other words, as a
definition, rather than a tentative definition. We found that doing
that caused too many link-time complaints about multiple definitions,
and decided that it would be better to treat such symbols as common
symbols, just like in K&R C. That ran afoul of ANSI C rules, however,
when it came to searching archive libraries -- the common symbol needs
to behave like a regular definition and trigger the inclusion of the
object file containing it. Hence, SHN_ANSI_COMMON. In all other
respects, common and ANSI common symbols should behave the same.

Bottom line, we could have just done away with tentative definitions,
and required users to correct their sources when upgrading to ANSI C.
We saw too many multiple definition errors, however, so we added this
feature as a backward compatibility measure.

(You'll see the same distinction if you look at the SOM format for
32-bit PA-RISC.)

-cary (who was to blame for all this while at HP)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]