-/* Create a fundamental C type using default reasonable for the current
- target machine.
-
- Some object/debugging file formats (DWARF version 1, COFF, etc) do not
- define fundamental types such as "int" or "double". Others (stabs or
- DWARF version 2, etc) do define fundamental types. For the formats which
- don't provide fundamental types, gdb can create such types using this
- function.
-
- FIXME: Some compilers distinguish explicitly signed integral types
- (signed short, signed int, signed long) from "regular" integral types
- (short, int, long) in the debugging information. There is some dis-
- agreement as to how useful this feature is. In particular, gcc does
- not support this. Also, only some debugging formats allow the
- distinction to be passed on to a debugger. For now, we always just
- use "short", "int", or "long" as the type name, for both the implicit
- and explicitly signed types. This also makes life easier for the
- gdb test suite since we don't have to account for the differences
- in output depending upon what the compiler and debugging format
- support. We will probably have to re-examine the issue when gdb
- starts taking it's fundamental type information directly from the
- debugging information supplied by the compiler. fnf@cygnus.com */
+/* Create a fundamental C type using default reasonable for the
+ current target.
+
+ Some object/debugging file formats (DWARF version 1, COFF, etc) do
+ not define fundamental types such as "int" or "double". Others
+ (stabs or DWARF version 2, etc) do define fundamental types. For
+ the formats which don't provide fundamental types, gdb can create
+ such types using this function.
+
+ FIXME: Some compilers distinguish explicitly signed integral types
+ (signed short, signed int, signed long) from "regular" integral
+ types (short, int, long) in the debugging information. There is
+ some disagreement as to how useful this feature is. In particular,
+ gcc does not support this. Also, only some debugging formats allow
+ the distinction to be passed on to a debugger. For now, we always
+ just use "short", "int", or "long" as the type name, for both the
+ implicit and explicitly signed types. This also makes life easier
+ for the gdb test suite since we don't have to account for the
+ differences in output depending upon what the compiler and
+ debugging format support. We will probably have to re-examine the
+ issue when gdb starts taking it's fundamental type information
+ directly from the debugging information supplied by the compiler.
+ fnf@cygnus.com */