[Bug c/29242] New: system headers lack a distinct default calling convention

[Bug c/29242] New: system headers lack a distinct default calling convention

[acahalan at gmail dot com]

A number of options, -mregparm=3 and -mrtd for example, change the calling
convention in ways that would be incompatible with normal system header files.
These options are thus useless outside of freestanding code. Distinct settings
should be available for the app itself and for other stuff.

Ideally, "other stuff" would also be split with distinct settings for system
headers and for the libgcc-like things that the compiler may itself generate
calls to. This would require that gcc distinguish between memcpy used via
system header and memcpy used to implement struct copy.

For more direct control, perhaps this is reasonable:

#include <stdlib.h> __attribute__((regparm(0)))

An example showing this unawareness follows:

////////////////////////////////////////////////////////
foo 0 $ cat atoi.c
#include <stdlib.h> // a SYSTEM header
int a2i(const char *s){
        return atoi(s);
}
foo 0 $ gcc -W -Wall -std=gnu99 -m32 -Os -fomit-frame-pointer -S atoi.c
foo 0 $ cat atoi.s
        .file   "atoi.c"
        .text
.globl a2i
        .type   a2i, @function
a2i:
        jmp     atoi
        .size   a2i, .-a2i
        .ident  "GCC: (GNU) 4.1.1 20060828 (Red Hat 4.1.1-20)"
        .section        .note.GNU-stack,"",@progbits
foo 0 $ gcc -W -Wall -std=gnu99 -m32 -Os -fomit-frame-pointer -mregparm=3 -S
atoi.c
foo 0 $ cat atoi.s
        .file   "atoi.c"
        .text
.globl a2i
        .type   a2i, @function
a2i:
        jmp     atoi
        .size   a2i, .-a2i
        .ident  "GCC: (GNU) 4.1.1 20060828 (Red Hat 4.1.1-20)"
        .section        .note.GNU-stack,"",@progbits
foo 0 $ gcc -W -Wall -std=gnu99 -m32 -Os -fomit-frame-pointer -mrtd -S atoi.c
foo 0 $ cat atoi.s
        .file   "atoi.c"
        .text
.globl a2i
        .type   a2i, @function
a2i:
        jmp     atoi
        .size   a2i, .-a2i
        .ident  "GCC: (GNU) 4.1.1 20060828 (Red Hat 4.1.1-20)"
        .section        .note.GNU-stack,"",@progbits
foo 0 $


-- 
           Summary: system headers lack a distinct default calling
                    convention
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: acahalan at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29242

[Bug c/29242] system headers lack a distinct default calling convention

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-09-26 20:32 -------
Yes those change the ABI which means don't use them unless you know what you
are doing.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29242

[Bug c/29242] system headers lack a distinct default calling convention

[acahalan at gmail dot com]

------- Comment #2 from acahalan at gmail dot com  2006-09-27 00:15 -------
(In reply to comment #1)
> Yes those change the ABI which means don't use them unless you know what you
> are doing.

I damn well do know what I want to do, and gcc does not support it.

What, you expect me to edit the system header files to add
__attribute__((regparm(0))) and such all over the place? This is not practical.
Adding __attribute__((regparm(3))) all over the app is not good either.

For other reasons, gcc already distinguishes between system header files and
non-system header files. If this distinction were used for ABI-related issues,
-mregparm=3 and similar would be practical for normal app code.

As far as I can tell, that would only leave the problem of callback functions
such as the fourth qsort() argument and main(). Probably main() should be
handled automatically.


-- 

acahalan at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29242

[Bug other/29242] system headers lack a distinct default calling convention

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-09-27 00:32 -------
(In reply to comment #2)
First you should not be using options that change the ABI if you don't know
what you are doing. because they change the ABI. Second, none of options you
gave are really options because some people actually use the options correctly
in that they want the ABI to change with all the header files and you are no
longer doing it correct.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
          Component|c                           |other
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29242

[Bug other/29242] system headers lack a distinct default calling convention

[acahalan at gmail dot com]

------- Comment #4 from acahalan at gmail dot com  2006-09-27 02:19 -------
(In reply to comment #3)
> (In reply to comment #2)
> First you should not be using options that change the ABI if you don't know
> what you are doing. because they change the ABI. Second, none of options you
> gave are really options because some people actually use the options correctly
> in that they want the ABI to change with all the header files and you are no
> longer doing it correct.

I tend to think that these people are NOT using the options correctly.
They should have built their compiler to use a different ABI if that
is what the interfaces in their system header files require.

Another way to make things work:

gcc -mregparm-app=3 ...

That is, add new options which change the ABI only for local files.
The interfaces declared in the system headers would not be affected.

Imagine building gcc itself with regparm 3. You probably don't want
to mark up the gcc source to enable this, but marking up the system
header files is definitely not an option.


-- 

acahalan at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29242

[Bug other/29242] system headers lack a distinct default calling convention

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2006-09-27 02:33 -------
Did you read the documention?
Warning: if you use this switch, and num is nonzero, then you must build all
modules with the same value, including any libraries. This includes the system
libraries and startup modules. 

Warning: this calling convention is incompatible with the one normally used on
Unix, so you cannot use it if you need to call libraries compiled with the Unix
compiler.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29242

[Bug other/29242] system headers lack a distinct default calling convention

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-09-27 02:34 -------
(In reply to comment #4)
> Imagine building gcc itself with regparm 3. You probably don't want
> to mark up the gcc source to enable this, but marking up the system
> header files is definitely not an option.
Or even better letting GCC do it automatically which it already does for local
functions and with LTO it can do with functions that don't escape.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29242

[Bug other/29242] system headers lack a distinct default calling convention

[dannysmith at users dot sourceforge dot net]

------- Comment #7 from dannysmith at users dot sourceforge dot net  2006-09-27 03:23 -------
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)

> Imagine building gcc itself with regparm 3. You probably don't want
> to mark up the gcc source to enable this, but marking up the system
> header files is definitely not an option.

Actually, om mingw32, the system headers are marked up (explicitly) with
calling convention (__cdecl, __stdcall, __fastcall), to avoid the -mrtd
problem. So it is an option.  I think that MSVC headers also do this.

Danny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29242

[Bug other/29242] system headers lack a distinct default calling convention

[acahalan at gmail dot com]

------- Comment #8 from acahalan at gmail dot com  2006-09-27 03:47 -------
(In reply to comment #5)
> Did you read the documention?
> Warning: if you use this switch, and num is nonzero, then you must build all
> modules with the same value, including any libraries. This includes the system
> libraries and startup modules. 
> 
> Warning: this calling convention is incompatible with the one normally used on
> Unix, so you cannot use it if you need to call libraries compiled with the Unix
> compiler.

I sure as heck did read this. It is the problem.
Every time I read that, I am annoyed that gcc
does not take advantage of the "system headers"
concept to make things work OK.

The mingw32 example in Comment #7 has a defect. System headers do not
always come from one single supplier. On a typical Linux system, there
are header files from numerous packages installed in /usr/include.
There is no reasonable way to get them all marked up with the ABI.

This would be a fine interface:

gcc -mregparm-app-only=3 ...

(likewise for -mrtd as -mrtd-app-only, etc.)


-- 

acahalan at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29242

[Bug other/29242] system headers lack a distinct default calling convention

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-09-27 04:01 -------
Why do you think this is a bug?  Again the options should not act this way at
all, it is a bit crazy to treat system headers different than normal headers. 
In fact you can get different behavior when you do:
#include <stdio.h>
and you also have -iquote /usr/include


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29242

[Bug other/29242] system headers lack a distinct default calling convention

[drow at gcc dot gnu dot org]

------- Comment #10 from drow at gcc dot gnu dot org  2006-09-28 01:31 -------
Andrew, stop closing this bug.

If necessary I will ask the SC for a statement preventing you from closing bugs
as invalid when the submitter disagrees, since you haven't shown a willingness
to listen to what they are saying.

I don't think that keying this off system headers would be a good idea - it's
very dangerous because of the number of ways it can silently break, e.g.
-iquote, manually prototyping a function, callbacks.  However, some more
general mechanism for setting the default ABI of a header might be useful.  I'm
thinking something like #pragma GCC visibility here.


-- 

drow at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29242

[Bug other/29242] system headers lack a distinct default calling convention

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2006-09-28 01:50 -------
> However, some more
> general mechanism for setting the default ABI of a header might be useful.  I'm
> thinking something like #pragma GCC visibility here.

Which is PR 15892 by the way.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29242