[Dwarf-Discuss] compilers generating ABI non-compliant function calls?

[Metzger, Markus T]

AFAIK the main reason to annotate a subprogram with a calling convention
is so that a debugger can manufacture a call correctly, in response to a
user command.

Right - and generally the debugger would expect to call this function using the ABI - except that with internalized functions (either static CU-local functions, or with any function that LTO optimizations can internalize - everything other than the specified entry points (in the worst case, only "main")) the ABI may be violated (because the compiler can see the implementation of the function and all its callers - well, it thinks it can see all the callers, but it doesn't know about the debugger making calls).

So, for instance, the internalized function may use callee save registers without restoring them - if a debugger then tried to call this function expecting it to conform to the ABI and restore those registers before returning, the debugger may malfunction/break as the register values would not be restored. I think?

Wouldn?t debuggers rather restore the entire register state after such an inferior call?

The issue is rather that the debugger might place arguments in the wrong location so the called function would interpret garbage as arguments.

Markus.

From: Dwarf-Discuss <dwarf-discuss-bounces@lists.dwarfstd.org> On Behalf Of David Blaikie via Dwarf-Discuss
Sent: Mittwoch, 10. M?rz 2021 00:28
To: Paul Robinson <paul.robinson at sony.com>
Cc: DWARF Discuss <dwarf-discuss at lists.dwarfstd.org>
Subject: Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?



On Tue, Mar 9, 2021 at 1:28 PM Paul Robinson via Dwarf-Discuss <dwarf-discuss at lists.dwarfstd.org<mailto:dwarf-discuss at lists.dwarfstd.org>> wrote:
(re-sending because outlook omitted the group address)

> -----Original Message-----
> From: Dwarf-Discuss <dwarf-discuss-bounces at lists.dwarfstd.org<mailto:dwarf-discuss-bounces at lists.dwarfstd.org>> On Behalf
> Of Jakub Jelinek via Dwarf-Discuss
> Sent: Tuesday, March 9, 2021 10:16 AM
> To: Andrew Cagney <andrew.cagney at gmail.com<mailto:andrew.cagney at gmail.com>>
> Cc: DWARF Discussion <dwarf-discuss at lists.dwarfstd.org<mailto:dwarf-discuss at lists.dwarfstd.org>>
> Subject: Re: [Dwarf-Discuss] compilers generating ABI non-compliant
> function calls?
>
> On Tue, Mar 09, 2021 at 10:05:04AM -0500, Andrew Cagney via Dwarf-Discuss
> wrote:
> > Is anyone aware of a compiler doing this (I figure with LTO there's a
> > strong incentive)?  And if so, how is this described to the debugger.
> > The ABI / calling-convention is no longer on hand for filling in the
> > blanks.
>
> Sure, GCC does that.  On many architectures, IPA-RA might keep data
> live across a function call even in registers that are per the ABI
> officially call clobbered (if it can prove the particular callee does not
> clobber it).  This isn't expressed in DWARF I believe.


DWARF doesn't describe clobbering or non-clobbering; it describes where
values live.

Right - but that lack of knowledge may be problematic in some situations I'm trying to describe. (ie: a "gap" where  current DWARF encoding + ABI knowledge is insufficient for a consumer to behave correctly)

If something gets clobbered by a call, the location list
should reflect that the location changes (or doesn't exist) as of the
instruction after the call; if it doesn't get clobbered, the location
range should correctly span the call instruction.  The debugger does not
need to know the ABI in order to trust that location lists are correct.

Agreed that the debugger doesn't need to know the clobber/callee save/caller save ABI to use a location list correctly.

The producer is responsible for emitting correct location lists that
don't depend on ABI knowledge by the consumer.

AFAIK the main reason to annotate a subprogram with a calling convention
is so that a debugger can manufacture a call correctly, in response to a
user command.

Right - and generally the debugger would expect to call this function using the ABI - except that with internalized functions (either static CU-local functions, or with any function that LTO optimizations can internalize - everything other than the specified entry points (in the worst case, only "main")) the ABI may be violated (because the compiler can see the implementation of the function and all its callers - well, it thinks it can see all the callers, but it doesn't know about the debugger making calls).

So, for instance, the internalized function may use callee save registers without restoring them - if a debugger then tried to call this function expecting it to conform to the ABI and restore those registers before returning, the debugger may malfunction/break as the register values would not be restored. I think?


- Dave

It might also be necessary to identify the location of the return value,
as someone else mentioned.
--paulr

>
> On x86, GCC can use different register calling conventions for local
> functions (basically automatic regparm and/or sseregparm calling
> conventions
> when possible).  I think this is reflected in the debug info, the
> DW_TAG_formal_parameter locations should match those.
>
>       Jakub
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org<mailto:Dwarf-Discuss at lists.dwarfstd.org>
> https://urldefense.com/v3/__http://lists.dwarfstd.org/listinfo.cgi/dwarf-<https://urldefense.com/v3/__http:/lists.dwarfstd.org/listinfo.cgi/dwarf->
> discuss-
> dwarfstd.org__;!!JmoZiZGBv3RvKRSx!saJXjJCyJzGPm7PNYMIYGGdh4Ox2WiUfnoR9uFea
> -PrVPbcUNCuNYk9zgwlQJrcZ9Q$
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss at lists.dwarfstd.org<mailto:Dwarf-Discuss at lists.dwarfstd.org>
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20210310/60dc412a/attachment-0001.html>