public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/108849] New: __declspec(code_seg("segname")) does not work
@ 2023-02-19 20:50 pali at kernel dot org
2024-01-07 10:00 ` [Bug target/108849] " arsen at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: pali at kernel dot org @ 2023-02-19 20:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849
Bug ID: 108849
Summary: __declspec(code_seg("segname")) does not work
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pali at kernel dot org
Target Milestone: ---
Originally reported on: https://sourceware.org/bugzilla/show_bug.cgi?id=30005
GCC/LD does not support __declspec(code_seg("segname")) declarator for
specifying name of PE/COFF segment name.
Instead GCC/LD supports different and custom syntax
__declspec(section("segname")) incompatible with other compilers, like MSVC.
Please add support for de-facto standard "code_seg" declarator into the PE/COFF
__declspec keyword and not custom declarator. It does not bring any value, just
make code incompatible with gcc.
Test case on Debian sid:
$ x86_64-w64-mingw32-ld -v
GNU ld (GNU Binutils) 2.39.90.20230110
$
$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/12-win32/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr
--includedir='/usr/include' --mandir='/usr/share/man'
--infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
--libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu'
--disable-maintainer-mode --disable-dependency-tracking --prefix=/usr
--enable-shared --enable-static --disable-multilib --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib
--enable-libstdcxx-time=yes --with-tune=generic --with-headers
--enable-version-specific-runtime-libs --enable-fully-dynamic-string
--enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto
--enable-threads=win32 --program-suffix=-win32
--program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32
--with-as=/usr/bin/x86_64-w64-mingw32-as
--with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic
--enable-libstdcxx-filesystem-ts=yes --enable-dependency-tracking SED=/bin/sed
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 12-win32 (GCC)
$
$ cat test-code-seg.c
__declspec(code_seg("segname"))
int test(void) { return 0; }
$
$ x86_64-w64-mingw32-gcc -c test-code-seg.c -o test-code-seg.o
test-code-seg.c:2:1: warning: 'code_seg' attribute directive ignored
[-Wattributes]
2 | int test(void) { return 0; }
| ^~~
$
$ x86_64-w64-mingw32-objdump -h test-code-seg.o | grep segname
$
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug target/108849] __declspec(code_seg("segname")) does not work
2023-02-19 20:50 [Bug c/108849] New: __declspec(code_seg("segname")) does not work pali at kernel dot org
@ 2024-01-07 10:00 ` arsen at gcc dot gnu.org
2024-01-07 12:31 ` pali at kernel dot org
2024-03-13 21:40 ` pali at kernel dot org
2 siblings, 0 replies; 4+ messages in thread
From: arsen at gcc dot gnu.org @ 2024-01-07 10:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849
Arsen Arsenović <arsen at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |arsen at gcc dot gnu.org
--- Comment #1 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
I think that declspec is currently simply an alias to attribute, IIUC (though,
I've not used or written code for w32 in many years):
/* Support the __declspec keyword by turning them into attributes.
Note that the current way we do this may result in a collision
with predefined attributes later on. This can be solved by using
one attribute, say __declspec__, and passing args to it. The
problem with that approach is that args are not accumulated: each
new appearance would clobber any existing args. */
if (TARGET_DECLSPEC)
builtin_define ("__declspec(x)=__attribute__((x))");
GCC currently does not assign code_seg to any attribute, so perhaps it could be
aliased on TARGET_DECLSPEC platforms to `section'? I'm not sure if that is
correct, I've never looked at the PE spec either.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug target/108849] __declspec(code_seg("segname")) does not work
2023-02-19 20:50 [Bug c/108849] New: __declspec(code_seg("segname")) does not work pali at kernel dot org
2024-01-07 10:00 ` [Bug target/108849] " arsen at gcc dot gnu.org
@ 2024-01-07 12:31 ` pali at kernel dot org
2024-03-13 21:40 ` pali at kernel dot org
2 siblings, 0 replies; 4+ messages in thread
From: pali at kernel dot org @ 2024-01-07 12:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849
--- Comment #2 from Pali Rohár <pali at kernel dot org> ---
`section` is the best option. MS says about it:
https://learn.microsoft.com/en-us/cpp/cpp/code-seg-declspec
> The code_seg declaration attribute names an executable text segment in the .obj file in which the object code for the function or class member functions is stored.
> A segment is a named block of data in an .obj file that is loaded into memory as a unit. A text segment is a segment that contains executable code. The term section is often used interchangeably with segment.
> By default, when no code_seg is specified, object code is put in a segment named .text.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug target/108849] __declspec(code_seg("segname")) does not work
2023-02-19 20:50 [Bug c/108849] New: __declspec(code_seg("segname")) does not work pali at kernel dot org
2024-01-07 10:00 ` [Bug target/108849] " arsen at gcc dot gnu.org
2024-01-07 12:31 ` pali at kernel dot org
@ 2024-03-13 21:40 ` pali at kernel dot org
2 siblings, 0 replies; 4+ messages in thread
From: pali at kernel dot org @ 2024-03-13 21:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849
--- Comment #3 from Pali Rohár <pali at kernel dot org> ---
Arsen, so based on my understooding (please correct me if I'm wrong), gcc's
"section" can be used on both code (functions) and data (global variables). And
ms's "code_seg" can be used only on code (functions).
So if gcc adds __declspec(code_seg("segname")) as alias to
__declspec(section("segname")) for TARGET_DECLSPEC then it should be OK for
valid source code. However it does not throws an compile error if
__declspec(code_seg("segname")) is specified on data. But I think it is
acceptable. Primary motivation is support for compiling valid source code.
Are you able to add this alias?
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-03-13 21:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-19 20:50 [Bug c/108849] New: __declspec(code_seg("segname")) does not work pali at kernel dot org
2024-01-07 10:00 ` [Bug target/108849] " arsen at gcc dot gnu.org
2024-01-07 12:31 ` pali at kernel dot org
2024-03-13 21:40 ` pali at kernel dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).