[Bug c/111769] New: Annotate function definitions and calls to facilitate link-time checking

[Bug c/111769] New: Annotate function definitions and calls to facilitate link-time checking

[david at westcontrol dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111769

            Bug ID: 111769
           Summary: Annotate function definitions and calls to facilitate
                    link-time checking
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: david at westcontrol dot com
  Target Milestone: ---

This is an enhancement idea, rather than a bug, and would require linker
support as well as compiler support.

In C, it is possible to define a function with one set of parameters (number
and type) in one translation unit, and declare and use it with a different set
in a different translation unit.  This is undefined behaviour, and generally a
really bad idea, but it can't be spotted by the toolchain unless you use LTO.

In C++, you don't see the same effect as different name mangling would result
in linker failures.

Would it be possible for the C compiler, when emitting an external linkage
function definition and the use (or possibly declaration) of a function (for
calling or taking its address), to add a directive or debug info section entry
giving the function type in active use?  These could then be checked at link
time, even without LTO, to catch mismatches.

My suggestion would be to use the existing C++ name-mangling scheme to encode
the function types.  Thus the declaration and definition of "int square(int
num)" would be annotated with a note that the function "square" has signature
"_Z6squarei".

[Bug c/111769] Annotate function definitions and calls to facilitate link-time checking

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111769

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
If you compile with debug info enabled the info should be already there, just
nothing looks at this (and mismatches) at link time.

[Bug c/111769] Annotate function definitions and calls to facilitate link-time checking

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111769

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
IIRC there was a bug about this specific thing which was closed as fixed with
the use of LTO ...

[Bug c/111769] Annotate function definitions and calls to facilitate link-time checking

[david at westcontrol dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111769

--- Comment #3 from David Brown <david at westcontrol dot com> ---
(In reply to Andrew Pinski from comment #2)
> IIRC there was a bug about this specific thing which was closed as fixed
> with the use of LTO ...

Certainly if you use LTO, then this is not necessary.  But LTO use is far from
universal, and there can be good reasons not to use it.  (It is rarely seen in
small embedded systems, for various reasons - some good, some less good.)  The
thought here is for a very low cost (for users) enhancement - the check could
be introduced without any change to the users' existing build process, code, or
linker scripts.

[Bug c/111769] Annotate function definitions and calls to facilitate link-time checking

[david at westcontrol dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111769

--- Comment #4 from David Brown <david at westcontrol dot com> ---
(In reply to Richard Biener from comment #1)
> If you compile with debug info enabled the info should be already there,
> just nothing looks at this (and mismatches) at link time.

Perhaps I should file this as an enhancement request for binutils?  If there is
enough information already generated by gcc, then only the linker part needs to
be implemented.  (It could also be checked by an external program, but that
would be a lot more inconvenient for the user.)

Will the binutils folk be familiar with the debug information and its layout,
or is there a document I can point them to?  I assume this kind of information
will be stable and documented, because gdb will need it.  (I can read through
the material for the details, but a rough pointer to get me started would
help.)