🚀 go-pugleaf

In article 2474@sophia.inria.fr, Theodore Papadopoulo <papadop@sophia.inria.fr> writes:
>... I understand very well too that object's
>implementation may vary form one compiler to an another so that the
>objects (.o) produced by different compilers should be uncompatible. But
>why having chosen to make this incompatibility through different
>mangling schemes... Wouldn't have it be much more easy to say that in
>each (.o) file is introduced an undefined symbol containing an
>identification of the compiler and of the version of the mangling scheme
>(something like __G++_MANGLING_2.3 or __ARM_MANGLING_1.4). The
>definition being provided in the compilation unit providing the main.
>To me, this would have two benefits:
>
>+ Easier to understand the linker messages when mixing object comming
>from two different compilers.
>+ Provided that the stab mechanism gives a good description of the
>objects layout, there would be a better orthogonality between debugger
>and compiler devlopments. This raises the question whether there has
>been any effort made for standardizing the information contained in the
>stabs specifically for C++. To be clear, I do not want a formalization
>of the encoding (this would be great but is out of the scope here) but
>of the minimum information that should be present for a debugger to be
>used transparently (i.e. with no more a priori knowledge of the compiler
>than it needs for a typical C compiler).

What you are asking is completely beyond the scope of the C++ standard.

The standard does not address name mangling at all, because it is not
part of the language, nor is it required. A "smart" object format or
linker would not use name mangling at all. Implementations which
use name mangling typically provide automatic demangling; if your
implemenation does not, complain to the vendor.

The standard does not try to address object file format or contents. There
is no requirement that an identifiable compiler, linker, debugger, or
object file exist, for one thing. An interactive interpreter could be a
valid implementation, for example. 

Next, requiring some unique identifier for each compiler (or whatever)
also requires some name repository and an organization to manage the
names and any conflicts that may arise. (For example, Industrial
Boolean Mechanisms might conflict with another company having the
same initials.)

Finally, I don't understand what you mean by a debugger that requires
"no more a priori knowledge of the compiler than it needs for a typical
C compiler".

If a platform has an ABI, compilers and debuggers would be presumed to
comply with the ABI. No other information in the object file would be
required. The ABI would specify everything.

If a platform has no ABI, or at least none which is adhered to, no
simple description will be adequate. Consider Intel x86 platforms,
many of which have no ABI:
	type int has 16 or 32 bits
	pointers have 16 or 32 bits, or both
	integers and pointers are unaligned, have alignment 2, or alignment 4
	enums vary in size or are fixed at 2 or 4 bytes
	floating-point numbers are IEEE or some special format
	caller or callee pops the stack
	caller or callee copies a struct passed by value
	how are function arguments passed, and in what order?
Plus other variations too numerous to list, and we are still talking only
about C, not C++. I don't see how to cover all the combinations by placing
one or several identifiers in the object file. A standard that attempted
to provide a list would undoubtedly miss some combination used by some compiler.

---
Steve Clamage, stephen.clamage@eng.sun.com



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]