Bug 29242 - system headers lack a distinct default calling convention
Summary: system headers lack a distinct default calling convention
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.1.1
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-26 20:27 UTC by Albert Cahalan
Modified: 2021-08-29 21:33 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Albert Cahalan 2006-09-26 20:27:32 UTC
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 $
Comment 1 Andrew Pinski 2006-09-26 20:32:44 UTC
Yes those change the ABI which means don't use them unless you know what you are doing.
Comment 2 Albert Cahalan 2006-09-27 00:15:49 UTC
(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.
Comment 3 Andrew Pinski 2006-09-27 00:32:19 UTC
(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.
Comment 4 Albert Cahalan 2006-09-27 02:19:38 UTC
(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.
Comment 5 Andrew Pinski 2006-09-27 02:33:36 UTC
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.
Comment 6 Andrew Pinski 2006-09-27 02:34:47 UTC
(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.
Comment 7 Danny Smith 2006-09-27 03:23:29 UTC
(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

Comment 8 Albert Cahalan 2006-09-27 03:47:48 UTC
(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.)
Comment 9 Andrew Pinski 2006-09-27 04:01:06 UTC
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

Comment 10 Daniel Jacobowitz 2006-09-28 01:31:02 UTC
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.
Comment 11 Andrew Pinski 2006-09-28 01:50:05 UTC
> 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.