[Bug default/30363] New: Location of return type not tracked in ABI model.

[Bug default/30363] New: Location of return type not tracked in ABI model.

[woodard at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30363

            Bug ID: 30363
           Summary: Location of return type not tracked in ABI model.
           Product: libabigail
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: woodard at redhat dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

There are cases where the calling convention is different depending on the
return type of a function for example when you have an array of a vector type,
if it is annotated with the vector attribute, it will be passed by value rather
than as a pointer pushed on the stack.

This is further complicated by specific rules about the size of a vector as
presented in the source language in relation to the size of the vector
registers. When this happens it can change the calling convention for the type. 

Unfortunately, compilers do not always get this exactly right:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027 So you can't just rely on
the faithful implementation of the calling convention within the compiler to
ensure that the vector is stored in the correct location. 

Right now there is no real way, short of binary analysis to determine where the
return type of a subprogram is going to be located. Therefore we cannot detect
these kinds of failures. There is a DWARF issue on this,
https://dwarfstd.org/issues/221105.1.html When this is implemented we should
make use of the location attribute for a subprogram to ensure that the compiler
is putting the return time in the correct place.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/30363] Location of return type not tracked in ABI model.

[woodard at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30363

--- Comment #1 from Ben Woodard <woodard at redhat dot com> ---
I know one of the founding principles of libabigail is that it assumes the
compiler implements the calling convention correctly. I do not think that this
is entirely sufficient. I think that there are several cases where we should
also verify parameter and return type locations.

1) Compiler bugs such as this one
2) Compilation options, for example if the same library with the same defined
types were compiled without SSE support then the compiler may choose a
different version of the calling convention which passed the vector array type
by pointer reference rather than as a value in a vector register. This one is
really subtle and may be the source of several problems that we have here in
HPC.
3) Inter compiler variation, there are subtle cases where differences in the
interpretation of the calling convention could lead to differences in the
allocation of registers and stack. In theory, this should not happen but it
actually does and this has been a problem that has led to the entire HPC
community creating vertical software stacks with every compiler.

Therefore, I believe that we need to include the location of the parameters and
the return value in our ABI model to catch these problems.

-- 
You are receiving this mail because:
You are on the CC list for the bug.