How should _Decimal64 and _Decimal128 be aligned on stack?
When passing _Decimal64 or _Decimal128 to a function via stack, how should they be aligned? Currently, gcc aligns them at 4byte boundary. Is this desirable? H.J.
Re: Git ChangeLog policy for GCC Testsuite inquiry
On Fri, Jan 24, 2020 at 2:39 PM Paul Smith wrote: > > On Fri, 2020-01-24 at 22:45 +0100, Jakub Jelinek wrote: > > > > In my experience the output of git log is a total mess so cannot > > > > replace ChangeLogs. But we can well decide to drop ChangeLog for > > > > the testsuite. > > > > > > Well, glibc has moved to extracting them from git, building > > > policies and scripts around that. I'm pretty sure other > > > significant projecs are also extracting their ChangeLogs from git. > > > > > > We could do the same, selecting some magic date as the cutover > > > point after which future ChangeLogs are extracted from GIT. In > > > fact, that's precisely what I'd like to see us do. > > > > We don't have a tool that can do it, not even get the boilerplate > > right. Yes, mklog helps, but it very often gets stuff wrong. Not to > > mention that the text what actually changed can't be generated very > > easily. > > I don't know if it counts as a significant project, but GNU make has > been doing this for years. > > What I did was take the existing ChangeLogs and rename them to > ChangeLog.1 or whatever, then started with a new ChangeLog generated > from scratch from Git messages. > > I use the gnulib build-aux/gitlog-to-changelog script to do it. It > requires a little bit of discipline to get right; in particular you > have to remember that the Git commit message will be indented 8 spaces > in the ChangeLog, so you have to be careful that your commit messages > wrap at char 70 (or less) in your Git commit. > > If you have Git hooks you could enforce a bit of formatting; for > example any line not indented by space must be <=70 chars long; this > allows people to use long lines for formatted content if they indent it > with a space or two. > > Otherwise, it's the same as writing the ChangeLog and you only have to > do it once. > > Just to note, the above script simply transcribes the commit message > into ChangeLog format. It does NOT try to auto-generate ChangeLog- > style content (files that changed, functions, etc.) from the Git diff > or whatever. > > There are a few special tokens you can add to your Git commit message > that get reformated to special changelog tokens like "(tiny change)" > etc. > > As mentioned previously, it's very important that the commit message be > provided as part of the code review, and it is very much fair game for > review comments. This is common practice, and a good idea because bad > commit messages are always a bummer, ChangeLog or not. > Libgcrypt includes ChangeLog entries in git commit messages: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git In each patch, commit log starts with ChangeLog entries without leading TABs followed by separator line with -- and then commit message. They have a script to extract ChangeLog for release. -- H.J.
Re: Git question: Rebasing a user branch
On Tue, Feb 4, 2020 at 2:03 PM Bill Schmidt wrote: > > I'm having a little difficulty with my workflow, and I'm hoping someone > can spot the problem. > > I have a user branch set up with the contrib/git-add-user-branch.sh > script. Here are the relevant portions of my .git/config: > > [remote "users/wschmidt"] > url = git+ssh://wschm...@gcc.gnu.org/git/gcc.git > fetch = +refs/users/wschmidt/heads/*:refs/remotes/users/wschmidt/* > fetch = +refs/users/wschmidt/tags/*:refs/tags/users/wschmidt/* > push = refs/heads/wschmidt/*:refs/users/wschmidt/heads/* > [branch "wschmidt/builtins"] > remote = users/wschmidt > merge = refs/users/wschmidt/heads/builtins > > I originally created the branch from master. I then made 15 local > commits, and pushed these upstream. > > I now want to rebase my branch from master, and reflect this state > upstream. My recipe is: > > git checkout master > git pull > git checkout wschmidt/builtins > git rebase master > git push --dry-run users/wschmidt +wschmidt/builtins > > After the rebase step, git status shows: > > On branch wschmidt/builtins > Your branch and 'users/wschmidt/builtins' have diverged, > and have 39 and 15 different commits each, respectively. >(use "git pull" to merge the remote branch into yours) > > nothing to commit, working tree clean > > Looks fine to me, so lets try the force push: > > wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run > users/wschmidt +wschmidt/builtins > To git+ssh://gcc.gnu.org/git/gcc.git > * [new branch] wschmidt/builtins -> wschmidt/builtins > > Well, that's odd, why is it trying to create a new branch? > > If I inadvisedly attempt to push without --dry-run, I am stopped from > creating the new branch: > > remote: *** Shared development branches should be named devel/*, and > should be documented in https://gcc.gnu.org/git.html . > remote: error: hook declined to update refs/heads/wschmidt/builtins > To git+ssh://gcc.gnu.org/git/gcc.git > ! [remote rejected] wschmidt/builtins -> wschmidt/builtins You can use "git push -f" or $ git push origin :yourbranch $ git push -u origin yourbranch Since it is hassle to use 2 commands, I use gitlab.com for my own work. > (hook declined) > error: failed to push some refs to > 'git+ssh://wschm...@gcc.gnu.org/git/gcc.git' > > It seems wrong that it is trying to update refs/head/wschmidt/builtins > (thus creating a new branch). It seems like there may be a missing > "users/" needed someplace. But I am not at all confident that's > correct. I'm a little suspicious of the push spec in my config. > > Can someone with strong git-fu give me any suggestions? > > Best regards, > Bill > -- H.J.
Re: GCC 9.3 Status Report (2020-02-28)
On Fri, Feb 28, 2020 at 5:42 AM Jakub Jelinek wrote: > > Status > == > > GCC 9.2 has been released more than half a year ago and it is time > for another release from the latest stable branch. Many people have > backported their fixes to 9 branch recently already, often together > with backports for 8.4. Now that 8.4-rc1 is out, I'd like to do > a 9.3-rc1 on Thursday, March 5th and the release most likely a week > after that. Please get your remaining 9.3 fixes into the branch > before that. > > > Quality Data > > > Priority # Change from last report > --- --- > P10 > P2 243 + 45 > P3 35 - 16 > P4 169 + 28 > P5 23 - 1 > --- --- > Total P1-P3 278 + 29 > Total 470 + 56 > > > Previous Report > === > > https://gcc.gnu.org/ml/gcc/2019-08/msg00093.html > handle_lto_debug_sections failed to copy .note.gnu.property section which caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93966 I am testing diff --git a/libiberty/simple-object.c b/libiberty/simple-object.c index d9c648af717..e6c466ab767 100644 --- a/libiberty/simple-object.c +++ b/libiberty/simple-object.c @@ -293,6 +293,9 @@ handle_lto_debug_sections (const char *name, int rename) /* Copy over .note.GNU-stack section under the same name if present. */ else if (strcmp (name, ".note.GNU-stack") == 0) return strcpy (newname, name); + /* Copy over .note.gnu.property section under the same name if present. */ + else if (strcmp (name, ".note.gnu.property") == 0) +return strcpy (newname, name); /* Copy over .comment section under the same name if present. Solaris ld uses them to relax its checking of ELF gABI access rules for COMDAT sections in objects produced by GCC. */ I'd like to backport it to GCC 9 if possible. -- H.J.
Re: Second GCC 8.4 Release Candidate available from gcc.gnu.org
On Mon, Mar 2, 2020 at 2:46 AM Jakub Jelinek wrote: > > The second release candidate for GCC 8.4 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/8.4.0-RC-20200302/ > ftp://gcc.gnu.org/pub/gcc/snapshots/8.4.0-RC-20200302/ > > and shortly its mirrors. It has been generated from git commit > r8-10102-g0afd41f8e6530b13421679801cf73cb6bef3. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux and i686-linux. Please test it and report any issues to > bugzilla. > > If all goes well, I'd still like to release 8.4 on Wednesday, March 4th. > I'd like to backport: commit r10-6965-g577350603a657590c4b54a4a966cb49497e2514c Author: H.J. Lu Date: Mon Mar 2 03:08:57 2020 -0800 lto: Also copy .note.gnu.property section When generating the separate file with LTO debug sections, we should also copy .note.gnu.property section. PR lto/93966 * simple-object.c (handle_lto_debug_sections): Also copy .note.gnu.property section. to GCC 8. Is it OK? Thanks. -- H.J.
Re: Second GCC 8.4 Release Candidate available from gcc.gnu.org
On Mon, Mar 2, 2020 at 3:46 AM Jakub Jelinek wrote: > > On Mon, Mar 02, 2020 at 03:41:06AM -0800, H.J. Lu wrote: > > On Mon, Mar 2, 2020 at 2:46 AM Jakub Jelinek wrote: > > > > > > The second release candidate for GCC 8.4 is available from > > > > > > https://gcc.gnu.org/pub/gcc/snapshots/8.4.0-RC-20200302/ > > > ftp://gcc.gnu.org/pub/gcc/snapshots/8.4.0-RC-20200302/ > > > > > > and shortly its mirrors. It has been generated from git commit > > > r8-10102-g0afd41f8e6530b13421679801cf73cb6bef3. > > > > > > I have so far bootstrapped and tested the release candidate on > > > x86_64-linux and i686-linux. Please test it and report any issues to > > > bugzilla. > > > > > > If all goes well, I'd still like to release 8.4 on Wednesday, March 4th. > > > > > > > I'd like to backport: > > > > commit r10-6965-g577350603a657590c4b54a4a966cb49497e2514c > > Author: H.J. Lu > > Date: Mon Mar 2 03:08:57 2020 -0800 > > > > lto: Also copy .note.gnu.property section > > > > When generating the separate file with LTO debug sections, we should > > also copy .note.gnu.property section. > > > > PR lto/93966 > > * simple-object.c (handle_lto_debug_sections): Also copy > > .note.gnu.property section. > > > > to GCC 8. Is it OK? > > Richi said on IRC that GCC 8 is unaffected and does copy all sections. GCC 8 is affected. > Also, I've made GCC 8.4-rc2 already and would strongly prefer not to do > another one, so if it is needed even for GCC 8, my preference would be > defer til 8.5 (i.e. commit after Wednesday). I will do it for Wednesday. -- H.J.
Re: GCC 8.5 Status Report (2020-03-04)
On Wed, Mar 4, 2020 at 2:30 AM Jakub Jelinek wrote: > > Status > == > > GCC 8.4 has been released and the branch is again open for regression > and documentation fixes. History makes us expect a GCC 8.5 release > in fall of this year and it will be the last release from the GCC 8 > series. > > > Quality Data > > > Priority # Change from last report > --- --- > P11 + 1 > P2 259 + 1 > P3 34 - 2 > P4 155 > P5 22 > --- --- > Total P1-P3 294 - 30 > Total 471 > > > Previous Report > === > > https://gcc.gnu.org/ml/gcc/2020-02/msg00212.html > I saw these new failures on Fedora 31: FAIL: 22_locale/numpunct/members/char/3.cc execution test FAIL: 22_locale/time_get/get_time/char/2.cc execution test FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution test FAIL: 22_locale/time_get/get_time/wchar_t/2.cc execution test FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_env.cc execution test FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test Are they expected? -- H.J.
Re: GCC 8.5 Status Report (2020-03-04)
On Wed, Mar 4, 2020 at 5:01 AM Jakub Jelinek wrote: > > On Wed, Mar 04, 2020 at 04:52:20AM -0800, H.J. Lu wrote: > > I saw these new failures on Fedora 31: > > > > FAIL: 22_locale/numpunct/members/char/3.cc execution test > > FAIL: 22_locale/time_get/get_time/char/2.cc execution test > > FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test > > FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution test > > FAIL: 22_locale/time_get/get_time/wchar_t/2.cc execution test > > FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_env.cc execution test > > FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test > > As with all 22_locale tests, if something in glibc changes (usually some > locale data), some tests can fail. > Though e.g. the first test hasn't really changed since late 2018, does it > work on the trunk for you? No, they fail on all branches. > E.g. for the first test, seems glibc fefa21790b5081e5d04662a240e2efd18603ef86 > changed: > diff --git a/localedata/locales/nl_NL b/localedata/locales/nl_NL > index d0ba6c7283..20652a9939 100644 > --- a/localedata/locales/nl_NL > +++ b/localedata/locales/nl_NL > @@ -74,7 +74,7 @@ LC_MONETARY > int_curr_symbol "EUR " > currency_symbol "" > mon_decimal_point "," > -mon_thousands_sep "" > +mon_thousands_sep "." > mon_grouping 3;3 > positive_sign "" > negative_sign "-" > @@ -90,8 +90,8 @@ END LC_MONETARY > > LC_NUMERIC > decimal_point "," > -thousands_sep "" > -grouping 0;0 > +thousands_sep "." > +grouping 3;3 > END LC_NUMERIC > > LC_TIME > > The test says: > // nl_NL chosen because it has no thousands separator (at this time). > locale loc_it = locale(ISO_8859(15,nl_NL)); > so no wonder that it FAILs if nl_NL now has thousands separator. > Maybe it is time for libstdc++ testsuite to create its own artificial > locales and test against them. > > Jakub > -- H.J.
X86 GCC automated testers are back online
X86 GCC automated testers are back online. They bootstrap and run testsuite for master branch and the current 2 release branches on Linux/x86-64 and Linux/i686: https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/555912.html https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/555909.html https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/37.html https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/35.html https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/555787.html https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/555793.html Regressions, new failures as well as new passes, are also reported: https://gcc.gnu.org/pipermail/gcc-regression/2020-March/072492.html https://gcc.gnu.org/pipermail/gcc-regression/2020-March/072495.html -- H.J.
Re: Code size issues on FP-emulation on libgcc compared to LLVM's compiler_rt
On Tue, Jun 30, 2015 at 4:33 AM, Zinovy Nis wrote:
> Hi.
>
>
> I'm building libgcc for a "iamcu" target (Pentium-like but with
> soft-fp emulation, the only x86 with SoftFP I know) with
> --enable-target-optspace.
Support for i?86*-*-elfiamcu target has been checked in as of
revision 225199.
>
> It works properly but I noticed that code the size for many arithmetic
> functions is much more larger than for soft-fp emulation provided by
> LLVM's compiler_rt library.
>
> For example addsf3 (addition of 2 floats) is 0.5K in compiler_rt and 1K in
> gcc!
>
>
> I double-checked compiler options and they are correct: -Os.
>
>
> Is it because of
>
>a) compiler_rt doesn't perform some checks (FP exception for example) or
>
>b) compiler_rt is incorrect in some corner cases or
>
>c) inefficient implementation in libgcc?
>
>
> Did anyone face with this problem?
>
> How to reproduce:
>
> First you need to build gcc for iamcu:
>
> INSTALL=
>
> TARGET=i586-intel-elfiamcu
>
> ./configure --host=x86_64-unknown-linux-gnu --enable-target-optspace
> --target=${TARGET} --prefix=${INSTALL} --with-demangler-in-ld
> --enable-languages=c MAKEINFO=missing --disable-multilib
> --disable-libitm --disable-libatomic --disable-libssp
> --disable-libquadmath --with-newlib && make -j $(nproc) && make
> install
>
>
> libgcc
>
> Let's get size of two float addition operation:
>
> nm -S -t dec --defined-only
> $(INSTALL)/lib/gcc/i586-intel-elfiamcu/4.9.3/libgcc.a | grep _addsf3
>
> I get:
>
> 1039 T __addsf3
>
> So the size is ~1K
>
> compiler_rt
>
> svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt
>
> cd compiler_rt/lib/builtins
>
> Compile: $(INSTALL)/bin/i586-intel-elfiamcu-gcc -Os addsf3.c -c
>
> Check function size: nm -S -t dec addsf3.o
>
> I get:
>
> 0522 T __addsf3
>
> So the size is ~0.5K.
>
> Why so large difference in libgcc and compiler_rt for the same functionality?
>
The size difference comes from soft-fp implementation, not from compiler
codegen. Does soft-fp have higher accuracy and more features?
--
H.J.
Re: Code size issues on FP-emulation on libgcc compared to LLVM's compiler_rt
On Tue, Jun 30, 2015 at 10:44 AM, Joseph Myers wrote: > On Tue, 30 Jun 2015, Zinovy Nis wrote: > >> It works properly but I noticed that code the size for many arithmetic >> functions is much more larger than for soft-fp emulation provided by >> LLVM's compiler_rt library. > > Code size is discussed in the paper about soft-fp in the 2006 Summit > proceedings. In general, soft-fp is optimized for speed (having > completely separate "if" cases for addition and subtraction, both of which > appear in both __addsf3 and __subsf3, for example) and for generality > (it's used in the Linux kernel for floating-point emulation, where you > want to follow the same choice of NaN etc. as a particular processor even > where IEEE semantics don't specify a particular choice, and it has > optional support for floating-point exceptions and rounding modes - note > that __float128 support in libgcc uses the hardware exceptions and > rounding modes when available), not for size (and generality takes > precedence over speed where they conflict, hence being a bit slower than > ieeelib even after the 2006 optimization work). > > soft-fp is expected to be used on 32-bit and 64-bit systems for which a > few kB code size is insignificant. Size is very important for IA MCU. Would it be acceptable to update soft-fp to optimize for size with #ifdef __OPTIMIZE_SIZE__ #else #endif -- H.J.
RFC: Add R_X86_64_INDBR_GOTPCREL and R_386_INDBR_GOT32
To avoid indirect branch to locally defined functions, I am proposing to add a new relocation, R_X86_64_INDBR_GOTPCREL, to x86-64 psABI: 1. When branching to an external function, foo, toolchain generates call/jmp *foo@GOTPCREL(%rip) with R_X86_64_INDBR_GOTPCREL relocation, instead of call/jmp foo[@PLT] 2. When function foo is locally defined, linker converts call/jmp *foo@GOTPCREL(%rip) to nop call/jmp foo 3. Otherwise, linker treats R_X86_64_INDBR_GOTPCREL the same way as R_X86_64_GOTPCREL. For i386 psABI, we add R_386_INDBR_GOT32: 1. When branching to an external function, foo, in non-PIC mode, toolchain generates call/jmp *foo@GOT with R_386_INDBR_GOT32 relocation, instead of call/jmp foo and in PIC mode call/jmp *foo@GOT(%reg) with R_386_INDBR_GOT32 relocation and REG holds the address of GOT, instead of call/jmp foo@PLT 2. When function foo is locally defined, linker converts call/jmp *foo@GOT[(%reg)] to nop call/jmp foo 3. Otherwise, a. In PIC mode, linker treats R_386_INDBR_GOT32 the same way as R_386_GOT32 and "call/jmp *foo@GOT" is unsupported. b. In no-PIC mode, linker computes its relocation value as relocation value of R_386_GOT32 plus the address of GOT and converts call/jmp *foo@GOT(%reg) to call/jmp *foo@GOT if needed. This new relocation effectively turns off lazy binding on function, foo. For i386, compiler is free to choose any register to hold the address of GOT and there is no need to make EBX a fixed register when branching to an external function in PIC mode. With this new relocation, only a one-byte NOP prefix overhead is added when function, foo, which compiler determines is external, turns out to be local at link-time, because of -Bsymbolic or a definition in another input object file which compiler has no knowledge of. The new -fno-plt GCC option can use R_X86_64_INDBR_GOTPCREL and R_386_INDBR_GOT32 relocations if linker supports them to avoid indirect branch to internal functions. For x86-64 GCC, it is implemented in assembler and linker. Assembler should generate R_X86_64_INDBR_GOTPCREL relocation, instead of R_X86_64_GOTPCREL relocation for “call/jmp *foo@GOTPCREL(%rip)” For i386 GCC, most is implemented in assembler and linker. Assembler should generate R_386_INDBR_GOT32 relocation, instead of R_386_GOT32 relocation, for “call/jmp *foo@GOT(%reg)”. GCC also needs to modify to generate “call/jmp *foo@GOT” in non-PIC mode. H.J.
Re: Question about DRAP register and reserving hard registers
On Thu, Jul 9, 2015 at 9:31 AM, Steve Ellcey wrote: > On Mon, 2015-06-29 at 11:10 +0100, Richard Henderson wrote: > >> > OK, I think I have this part of the code working on MIPS but >> > crtl->drap_reg is used in the epilogue as well as the prologue even if >> > it is not 'live' in between. If I understand the code correctly the x86 >> > prologue pushes the drap register on to the stack so that the epilogue >> > can pop it off and use it to restore the stack pointer. Is my >> > understanding correct? >> >> Yes. Although that saved copy is also used by unwind info. > > Do you know how and where this saved copy is used by the unwind info? > I don't see any indication that the unwind library knows if a stack has > been dynamically realigned and I don't see where unwind makes use of > this value. This is a very old patch for DRAP unwind with stack alignment: https://gcc.gnu.org/ml/gcc-patches/2008-07/msg00651.html You can also grep drap_reg in dwarf2out.c. -- H.J.
Re: configure.{in -> ac} rename (commit 35eafcc71b) broke in-tree binutils building of gcc
On Tue, Jul 14, 2015 at 10:03 AM, Jim Wilson wrote: > On 07/14/2015 02:13 AM, Jan Beulich wrote: >> I was quite surprised for my gcc 4.9.3 build (using binutils 2.25 instead >> of 2.24 as I had in use with 4.9.2) to fail in rather obscure ways. > > in-tree/combined-tree builds aren't recommended anymore, and hence > aren't well maintained anymore. That is an anachronism from the old > Cygnus days. I still find it useful to drop newlib into gcc so it can > be built like the other gcc libs, but otherwise I wouldn't recommend > combining anything. Combined tree is useful when the latest binutils is needed by GCC. -- H.J.
Re: configure.{in -> ac} rename (commit 35eafcc71b) broke in-tree binutils building of gcc
On Tue, Jul 14, 2015 at 7:00 PM, wrote: > > > >> On Jul 15, 2015, at 9:20 AM, Alan Modra wrote: >> >>> On Tue, Jul 14, 2015 at 10:13:06AM +0100, Jan Beulich wrote: >>> Alan, gcc maintainers, >>> >>> I was quite surprised for my gcc 4.9.3 build (using binutils 2.25 instead >>> of 2.24 as I had in use with 4.9.2) to fail in rather obscure ways. Quite >>> a bit of digging resulted in me finding that gcc/configure.ac looks for >>> configure.in in a number of binutils subtrees. >> >> I haven't used combined tree builds of binutils+gcc for a very long >> time, so this issue wasn't on my radar at all, sorry. >> >>> Globally replacing >>> configure.in by configure.[ai][cn] appears to address this, but I'm not >>> sure whether that would be an acceptable change >> >> Certainly sounds reasonable. >> >>> (there doesn't seem >>> to be a fix for this in gcc trunk either, which I originally expected I >>> could >>> simply backport). >> >> The configure.in->configure.ac rename happened over a year ago so I >> guess this shows that not too many people use combined binutils+gcc >> builds nowadays. I've always found combined binutils+gcc builds not >> worth the bother compared to simply building and installing binutils >> first, as Jim suggests. > > > Combined builds are very useful for doing Candian crosses. Though it might > just because my build script has been doing a combined build now for 5 years. > Also I noticed it was broken and ignored it as my script did not break, only > when I did a native build did it break. > We should fix gcc/configure.ac. -- H.J.
PATCH: Also check configure.ac in binutils source tree
On Tue, Jul 14, 2015 at 7:06 PM, H.J. Lu wrote:
> On Tue, Jul 14, 2015 at 7:00 PM, wrote:
>>
>>
>>
>>> On Jul 15, 2015, at 9:20 AM, Alan Modra wrote:
>>>
>>>> On Tue, Jul 14, 2015 at 10:13:06AM +0100, Jan Beulich wrote:
>>>> Alan, gcc maintainers,
>>>>
>>>> I was quite surprised for my gcc 4.9.3 build (using binutils 2.25 instead
>>>> of 2.24 as I had in use with 4.9.2) to fail in rather obscure ways. Quite
>>>> a bit of digging resulted in me finding that gcc/configure.ac looks for
>>>> configure.in in a number of binutils subtrees.
>>>
>>> I haven't used combined tree builds of binutils+gcc for a very long
>>> time, so this issue wasn't on my radar at all, sorry.
>>>
>>>> Globally replacing
>>>> configure.in by configure.[ai][cn] appears to address this, but I'm not
>>>> sure whether that would be an acceptable change
>>>
>>> Certainly sounds reasonable.
>>>
>>>> (there doesn't seem
>>>> to be a fix for this in gcc trunk either, which I originally expected I
>>>> could
>>>> simply backport).
>>>
>>> The configure.in->configure.ac rename happened over a year ago so I
>>> guess this shows that not too many people use combined binutils+gcc
>>> builds nowadays. I've always found combined binutils+gcc builds not
>>> worth the bother compared to simply building and installing binutils
>>> first, as Jim suggests.
>>
>>
>> Combined builds are very useful for doing Candian crosses. Though it might
>> just because my build script has been doing a combined build now for 5
>> years. Also I noticed it was broken and ignored it as my script did not
>> break, only when I did a native build did it break.
>>
>
> We should fix gcc/configure.ac.
>
Here is a patch. Tested on Linux/x86-64 with native GCC as well as
cross-toolchain.
Any comments, feedbacks, objections?
Thanks.
--
H.J.
---
The configure.in files in binutils source tree have been renamed to
configure.ac. This patch checks both configure.in and configure.ac in
binutils source tree.
* configure.ac (gcc_cv_as_gas_configure): New. Set if
configure.in or configure.ac exist.
(gcc_cv_ld_gld_configure): Likewise.
(gcc_cv_binutils_configure): Likewise.
(gcc_cv_as): Check $gcc_cv_as_gas_configure instead of
$gcc_cv_as_gas_srcdir/configure.in.
(gcc_cv_ld): Check $gcc_cv_ld_gld_configure instead of
$gcc_cv_ld_gld_srcdir/configure.in.
(gcc_cv_nm): Check $gcc_cv_binutils_configure instead of
$gcc_cv_binutils_srcdir/configure.in.
(gcc_cv_objdump): Likewise.
(gcc_cv_readelf): Likewise.
* configure: Regenerated.
From ff4cfec084398aa5603c44896c7f583bc6a01045 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Wed, 15 Jul 2015 08:07:04 -0700
Subject: [PATCH] Also check configure.ac in binutils source tree
The configure.in files in binutils source tree have been renamed to
configure.ac. This patch checks both configure.in and configure.ac in
binutils source tree.
* configure.ac (gcc_cv_as_gas_configure): New. Set if
configure.in or configure.ac exist.
(gcc_cv_ld_gld_configure): Likewise.
(gcc_cv_binutils_configure): Likewise.
(gcc_cv_as): Check $gcc_cv_as_gas_configure instead of
$gcc_cv_as_gas_srcdir/configure.in.
(gcc_cv_ld): Check $gcc_cv_ld_gld_configure instead of
$gcc_cv_ld_gld_srcdir/configure.in.
(gcc_cv_nm): Check $gcc_cv_binutils_configure instead of
$gcc_cv_binutils_srcdir/configure.in.
(gcc_cv_objdump): Likewise.
(gcc_cv_readelf): Likewise.
* configure: Regenerated.
---
gcc/configure| 30 --
gcc/configure.ac | 30 --
2 files changed, 48 insertions(+), 12 deletions(-)
diff --git a/gcc/configure b/gcc/configure
index e0755f9..002e6b1 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -21668,6 +21668,12 @@ ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
gcc_cv_gas_major_version=
gcc_cv_gas_minor_version=
gcc_cv_as_gas_srcdir=`echo $srcdir | sed -e 's,/gcc$,,'`/gas
+gcc_cv_as_gas_configure=
+if test -f $gcc_cv_as_gas_srcdir/configure.in; then
+ gcc_cv_as_gas_configure=$gcc_cv_as_gas_srcdir/configure.in;
+elif test -f $gcc_cv_as_gas_srcdir/configure.ac; then
+ gcc_cv_as_gas_configure=$gcc_cv_as_gas_srcdir/configure.ac
+fi
if test "${gcc_cv_as+set}" = set; then :
@@ -21675,7 +21681,7 @@ else
if test -x "$DEFAULT_ASSEMBLER"; then
gcc_cv_as="$DEFAULT_ASSEMBLER"
-elif test -f $gcc_cv_as_gas_srcdir/configure.in \
+elif test -n "$gcc_cv_as_gas_configure" \
&& test -f ../gas/Makefile \
&& test x$build = x$host; then
gcc_cv_as=../gas/as-new$build_exeext
@@ -21826,6 +21832,12 @@ gcc_cv_gld_minor_ve
[PATCH] PR rtl-optimization/67029: gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns
Since ira_implicitly_set_insn_hard_regs may be called outside of
ira-lives.c, it can't use the local variable, preferred_alternatives.
This patch adds an alternative_mask argument to
ira_implicitly_set_insn_hard_regs.
OK for master and 5 branch if there are no regressions on Linux/x86-64?
H.J.
---
gcc/
PR rtl-optimization/67029
* ira-color.c: Include "recog.h" before including "ira-int.h".
* target-globals.c: Likewise.
* ira-lives.c (ira_implicitly_set_insn_hard_regs): Add an
adds an alternative_mask argument and use it instead of
preferred_alternatives.
* ira.h (ira_implicitly_set_insn_hard_regs): Moved to ...
* ira-int.h (ira_implicitly_set_insn_hard_regs): Here.
* sched-deps.c: Include "ira-int.h" after including "ira.h".
(sched_analyze_insn): Update call to
ira_implicitly_set_insn_hard_regs.
* sel-sched.c: Include "ira-int.h" after including "ira.h".
(implicit_clobber_conflict_p): Update call to
ira_implicitly_set_insn_hard_regs.
gcc/testsuite/
PR rtl-optimization/67029
* gcc.dg/pr67029.c: New test.
---
gcc/ira-color.c| 1 +
gcc/ira-int.h | 2 ++
gcc/ira-lives.c| 4 ++--
gcc/ira.h | 1 -
gcc/sched-deps.c | 4 +++-
gcc/sel-sched.c| 4 +++-
gcc/target-globals.c | 1 +
gcc/testsuite/gcc.dg/pr67029.c | 14 ++
8 files changed, 26 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr67029.c
diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index 74d2c2e..c8f33ed 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -46,6 +46,7 @@ along with GCC; see the file COPYING3. If not see
#include "cfgloop.h"
#include "ira.h"
#include "alloc-pool.h"
+#include "recog.h"
#include "ira-int.h"
typedef struct allocno_hard_regs *allocno_hard_regs_t;
diff --git a/gcc/ira-int.h b/gcc/ira-int.h
index a7c0f40..a993dfc 100644
--- a/gcc/ira-int.h
+++ b/gcc/ira-int.h
@@ -1041,6 +1041,8 @@ extern void ira_debug_live_ranges (void);
extern void ira_create_allocno_live_ranges (void);
extern void ira_compress_allocno_live_ranges (void);
extern void ira_finish_allocno_live_ranges (void);
+extern void ira_implicitly_set_insn_hard_regs (HARD_REG_SET *,
+ alternative_mask);
/* ira-conflicts.c */
extern void ira_debug_conflicts (bool);
diff --git a/gcc/ira-lives.c b/gcc/ira-lives.c
index 1cb05c2..011d513 100644
--- a/gcc/ira-lives.c
+++ b/gcc/ira-lives.c
@@ -831,7 +831,8 @@ single_reg_operand_class (int op_num)
might be used by insn reloads because the constraints are too
strict. */
void
-ira_implicitly_set_insn_hard_regs (HARD_REG_SET *set)
+ira_implicitly_set_insn_hard_regs (HARD_REG_SET *set,
+ alternative_mask preferred)
{
int i, c, regno = 0;
enum reg_class cl;
@@ -854,7 +855,6 @@ ira_implicitly_set_insn_hard_regs (HARD_REG_SET *set)
mode = (GET_CODE (op) == SCRATCH
? GET_MODE (op) : PSEUDO_REGNO_MODE (regno));
cl = NO_REGS;
- alternative_mask preferred = preferred_alternatives;
for (; (c = *p); p += CONSTRAINT_LEN (c, p))
if (c == '#')
preferred &= ~ALTERNATIVE_BIT (0);
diff --git a/gcc/ira.h b/gcc/ira.h
index 504b5e6..881674b 100644
--- a/gcc/ira.h
+++ b/gcc/ira.h
@@ -192,7 +192,6 @@ extern void ira_init (void);
extern void ira_setup_eliminable_regset (void);
extern rtx ira_eliminate_regs (rtx, machine_mode);
extern void ira_set_pseudo_classes (bool, FILE *);
-extern void ira_implicitly_set_insn_hard_regs (HARD_REG_SET *);
extern void ira_expand_reg_equiv (void);
extern void ira_update_equiv_info_by_shuffle_insn (int, int, rtx_insn *);
diff --git a/gcc/sched-deps.c b/gcc/sched-deps.c
index 3ac66e8..0a8dcb0 100644
--- a/gcc/sched-deps.c
+++ b/gcc/sched-deps.c
@@ -43,6 +43,7 @@ along with GCC; see the file COPYING3. If not see
#include "alloc-pool.h"
#include "cselib.h"
#include "ira.h"
+#include "ira-int.h"
#include "target.h"
#ifdef INSN_SCHEDULING
@@ -2891,7 +2892,8 @@ sched_analyze_insn (struct deps_desc *deps, rtx x,
rtx_insn *insn)
extract_insn (insn);
preprocess_constraints (insn);
- ira_implicitly_set_insn_hard_regs (&temp);
+ alternative_mask prefrred = get_preferred_alternatives (insn);
+ ira_implicitly_set_insn_hard_regs (&temp, prefrred);
AND_COMPL_HARD_REG_SET (temp, ira_no_alloc_regs);
IOR_HARD_REG_SET (implicit_reg_pending_clobbers, temp);
}
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index ec2ab05..1860444 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -41,6 +41,7 @@ along with GCC; see t
Re: [PATCH] PR rtl-optimization/67029: gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns
On Thu, Aug 6, 2015 at 11:19 AM, Richard Sandiford wrote: > "H.J. Lu" writes: >> Since ira_implicitly_set_insn_hard_regs may be called outside of >> ira-lives.c, it can't use the local variable, preferred_alternatives. >> This patch adds an alternative_mask argument to >> ira_implicitly_set_insn_hard_regs. >> >> OK for master and 5 branch if there are no regressions on Linux/x86-64? > > Thanks for working on this. The patch looks good to me FWIW. > > I think this version is safer than the second one you posted. With that > version we could end up with the same sort of bug, e.g. because a function > passes false to extract_insn without realising that one of the functions > that it calls later needs the preferred alternatives to be set. > Or maybe (as with my patch) a function starts to use preferred_alternatives > and one of its callers gets missed. > > Sorry for the breakage. > I think local variable preferred_alternatives in ira-lives.c is problematic by itself. It is easy to become stale. recog_data_d is the natural place for it. But as you pointed out, it has its own problem. I don't know if we should always call get_preferred_alternatives to initialize it even if it isn't used. Or we can make preferred_alternatives a pointer in recog_data_d. If it isn't initialized, you will get a segfault when you use it. This one indirection. This is just my observation. I will do whatever is approved. Thanks. -- H.J.
Re: Adding static-PIE support to binutils
On Tue, Jun 23, 2015 at 9:18 PM, Rich Felker wrote: > For background on the static PIE model I'm working with, see the > following post to the GCC list: > > https://gcc.gnu.org/ml/gcc/2015-06/msg8.html > > So far, I've been prototyping static PIE support by having GCC pass > the following options to ld instead of -static -pie: > > -static -shared -Bsymbolic > > This partly works, but since ld does not know it's producing a main > executable, it misses important details, including the ability to link > initial-exec and local-exec model TLS code correctly, as well as > various linking optimizations. So I think the right way forward is > making ld accept -static and -pie together to do the right thing. > > In elflink.c, _bfd_elf_link_create_dynamic_sections assumes that > executables should always have a .interp section. > bfd_elf_size_dynamic_sections asserts this assumption again, and the > individual elf??-*.c files also do so in *_elf_size_dynamic_sections > where they set a default interpreter. (Is this even useful? Most of > the names are out of touch with reality, and GCC always passes an > explicit -dynamic-linker anyway, so I think this code should just be > removed.) > > Now I have a working prototype by changing the info->executable > condition to info->executable && info->dynamic, and having lexsup.c > store the value of input_flags.dynamic in link_info.dynamic after > processing the command line, but I'm not sure if this is the right > approach. It is OK to use -static/-Bstatic/-non_shared with -shared and -pie. I think you want --no-dynamic-linker. -- H.J.
Re: Adding static-PIE support to binutils
On Mon, Aug 17, 2015 at 3:43 PM, Rich Felker wrote: > On Mon, Aug 17, 2015 at 02:19:34PM -0700, H.J. Lu wrote: >> On Tue, Jun 23, 2015 at 9:18 PM, Rich Felker wrote: >> > For background on the static PIE model I'm working with, see the >> > following post to the GCC list: >> > >> > https://gcc.gnu.org/ml/gcc/2015-06/msg8.html >> > >> > So far, I've been prototyping static PIE support by having GCC pass >> > the following options to ld instead of -static -pie: >> > >> > -static -shared -Bsymbolic >> > >> > This partly works, but since ld does not know it's producing a main >> > executable, it misses important details, including the ability to link >> > initial-exec and local-exec model TLS code correctly, as well as >> > various linking optimizations. So I think the right way forward is >> > making ld accept -static and -pie together to do the right thing. >> > >> > In elflink.c, _bfd_elf_link_create_dynamic_sections assumes that >> > executables should always have a .interp section. >> > bfd_elf_size_dynamic_sections asserts this assumption again, and the >> > individual elf??-*.c files also do so in *_elf_size_dynamic_sections >> > where they set a default interpreter. (Is this even useful? Most of >> > the names are out of touch with reality, and GCC always passes an >> > explicit -dynamic-linker anyway, so I think this code should just be >> > removed.) >> > >> > Now I have a working prototype by changing the info->executable >> > condition to info->executable && info->dynamic, and having lexsup.c >> > store the value of input_flags.dynamic in link_info.dynamic after >> > processing the command line, but I'm not sure if this is the right >> > approach. >> >> It is OK to use -static/-Bstatic/-non_shared with -shared and -pie. >> I think you want --no-dynamic-linker. > > Yes, I was concerned someone might say that. I could certainly add a > --no-dynamic-linker option, but then how should it work on the gcc > side? Having to use -Wl,--no-dynamic-linker to get static-pie would be > a significant obstacle to actual usage, I think. The gcc specs could > automatically pass --no-dynamic-linker when -static is passed to gcc, > assuming users who want to do weird mixes of static and dynamic > linking would use -Wl,-Bstatic rather than -static. After all, gcc > needs to know it's asking for static-pie anyway in order to use the > right startfile. Does that seem reasonable? I think it is seasonable for gcc to pass --no-dynamic-linker to ld when -static is used if ld supports it. -- H.J.
Re: Adding static-PIE support to binutils
On Mon, Aug 17, 2015 at 8:44 PM, Rich Felker wrote: > On Mon, Aug 17, 2015 at 10:42:56PM -0400, Rich Felker wrote: >> On Mon, Aug 17, 2015 at 02:19:34PM -0700, H.J. Lu wrote: >> > On Tue, Jun 23, 2015 at 9:18 PM, Rich Felker wrote: >> > > For background on the static PIE model I'm working with, see the >> > > following post to the GCC list: >> > > >> > > https://gcc.gnu.org/ml/gcc/2015-06/msg8.html >> > > >> > > So far, I've been prototyping static PIE support by having GCC pass >> > > the following options to ld instead of -static -pie: >> > > >> > > -static -shared -Bsymbolic >> > > >> > > This partly works, but since ld does not know it's producing a main >> > > executable, it misses important details, including the ability to link >> > > initial-exec and local-exec model TLS code correctly, as well as >> > > various linking optimizations. So I think the right way forward is >> > > making ld accept -static and -pie together to do the right thing. >> > > >> > > In elflink.c, _bfd_elf_link_create_dynamic_sections assumes that >> > > executables should always have a .interp section. >> > > bfd_elf_size_dynamic_sections asserts this assumption again, and the >> > > individual elf??-*.c files also do so in *_elf_size_dynamic_sections >> > > where they set a default interpreter. (Is this even useful? Most of >> > > the names are out of touch with reality, and GCC always passes an >> > > explicit -dynamic-linker anyway, so I think this code should just be >> > > removed.) >> > > >> > > Now I have a working prototype by changing the info->executable >> > > condition to info->executable && info->dynamic, and having lexsup.c >> > > store the value of input_flags.dynamic in link_info.dynamic after >> > > processing the command line, but I'm not sure if this is the right >> > > approach. >> > >> > It is OK to use -static/-Bstatic/-non_shared with -shared and -pie. >> > I think you want --no-dynamic-linker. >> >> I see two overall approaches to making the option to omit .interp: >> >> 1. In elflink.c, make the creation of the .interp section conditional >>on a new field in link_info. >> >> 2. In ld code (ldlang.c? elf32.em?), check the command line option and >>remove the .interp section before it can be processed. >> >> I think option 1 is a lot cleaner, but it's also going to be a lot >> more invasive, because every single target arch (elf32-*.c and >> elf64-*.c) has its own ASSERT that the .interp section exists. These >> would also need to be updated to either check the new field in >> link_info, or to replace the ASSERT with a conditional. >> >> Before I spend a lot of time implementing one or the other, do you >> have any feelings on which way would be appropriate? > > I went ahead and did option 1 modulo all the target code except sh > which is where I'm testing it. My work-in-progress patch is attached. > This is obviously not ready to submit but I would appreciate any > feedback that's possible at this stage. + case OPTION_NO_DYNAMIC_LINKER: + command_line.interpreter = NULL; + link_info.nointerp = 1; No need to clear command_line.interpreter and please add a simple testcase to verify it works correctly. H.J. -- H.J.
Re: Adding static-PIE support to binutils
On Tue, Aug 18, 2015 at 9:08 AM, Rich Felker wrote: > On Tue, Aug 18, 2015 at 08:56:00AM -0700, H.J. Lu wrote: >> On Mon, Aug 17, 2015 at 8:44 PM, Rich Felker wrote: >> > On Mon, Aug 17, 2015 at 10:42:56PM -0400, Rich Felker wrote: >> >> On Mon, Aug 17, 2015 at 02:19:34PM -0700, H.J. Lu wrote: >> >> > On Tue, Jun 23, 2015 at 9:18 PM, Rich Felker wrote: >> >> > > For background on the static PIE model I'm working with, see the >> >> > > following post to the GCC list: >> >> > > >> >> > > https://gcc.gnu.org/ml/gcc/2015-06/msg8.html >> >> > > >> >> > > So far, I've been prototyping static PIE support by having GCC pass >> >> > > the following options to ld instead of -static -pie: >> >> > > >> >> > > -static -shared -Bsymbolic >> >> > > >> >> > > This partly works, but since ld does not know it's producing a main >> >> > > executable, it misses important details, including the ability to link >> >> > > initial-exec and local-exec model TLS code correctly, as well as >> >> > > various linking optimizations. So I think the right way forward is >> >> > > making ld accept -static and -pie together to do the right thing. >> >> > > >> >> > > In elflink.c, _bfd_elf_link_create_dynamic_sections assumes that >> >> > > executables should always have a .interp section. >> >> > > bfd_elf_size_dynamic_sections asserts this assumption again, and the >> >> > > individual elf??-*.c files also do so in *_elf_size_dynamic_sections >> >> > > where they set a default interpreter. (Is this even useful? Most of >> >> > > the names are out of touch with reality, and GCC always passes an >> >> > > explicit -dynamic-linker anyway, so I think this code should just be >> >> > > removed.) >> >> > > >> >> > > Now I have a working prototype by changing the info->executable >> >> > > condition to info->executable && info->dynamic, and having lexsup.c >> >> > > store the value of input_flags.dynamic in link_info.dynamic after >> >> > > processing the command line, but I'm not sure if this is the right >> >> > > approach. >> >> > >> >> > It is OK to use -static/-Bstatic/-non_shared with -shared and -pie. >> >> > I think you want --no-dynamic-linker. >> >> >> >> I see two overall approaches to making the option to omit .interp: >> >> >> >> 1. In elflink.c, make the creation of the .interp section conditional >> >>on a new field in link_info. >> >> >> >> 2. In ld code (ldlang.c? elf32.em?), check the command line option and >> >>remove the .interp section before it can be processed. >> >> >> >> I think option 1 is a lot cleaner, but it's also going to be a lot >> >> more invasive, because every single target arch (elf32-*.c and >> >> elf64-*.c) has its own ASSERT that the .interp section exists. These >> >> would also need to be updated to either check the new field in >> >> link_info, or to replace the ASSERT with a conditional. >> >> >> >> Before I spend a lot of time implementing one or the other, do you >> >> have any feelings on which way would be appropriate? >> > >> > I went ahead and did option 1 modulo all the target code except sh >> > which is where I'm testing it. My work-in-progress patch is attached. >> > This is obviously not ready to submit but I would appreciate any >> > feedback that's possible at this stage. >> >> + case OPTION_NO_DYNAMIC_LINKER: >> + command_line.interpreter = NULL; >> + link_info.nointerp = 1; >> >> No need to clear command_line.interpreter and please add a simple >> testcase to verify it works correctly. > > OK. Do I also need to update it to be against the new output_type > stuff you just committed? > That is a good idea. -- H.J.
Re: Adding static-PIE support to binutils
On Tue, Aug 18, 2015 at 5:58 PM, Rich Felker wrote: > On Tue, Aug 18, 2015 at 09:30:56AM -0700, H.J. Lu wrote: >> On Tue, Aug 18, 2015 at 9:08 AM, Rich Felker wrote: >> > On Tue, Aug 18, 2015 at 08:56:00AM -0700, H.J. Lu wrote: >> >> On Mon, Aug 17, 2015 at 8:44 PM, Rich Felker wrote: >> >> > On Mon, Aug 17, 2015 at 10:42:56PM -0400, Rich Felker wrote: >> >> >> On Mon, Aug 17, 2015 at 02:19:34PM -0700, H.J. Lu wrote: >> >> >> > On Tue, Jun 23, 2015 at 9:18 PM, Rich Felker wrote: >> >> >> > > For background on the static PIE model I'm working with, see the >> >> >> > > following post to the GCC list: >> >> >> > > >> >> >> > > https://gcc.gnu.org/ml/gcc/2015-06/msg8.html >> >> >> > > >> >> >> > > So far, I've been prototyping static PIE support by having GCC pass >> >> >> > > the following options to ld instead of -static -pie: >> >> >> > > >> >> >> > > -static -shared -Bsymbolic >> >> >> > > >> >> >> > > This partly works, but since ld does not know it's producing a main >> >> >> > > executable, it misses important details, including the ability to >> >> >> > > link >> >> >> > > initial-exec and local-exec model TLS code correctly, as well as >> >> >> > > various linking optimizations. So I think the right way forward is >> >> >> > > making ld accept -static and -pie together to do the right thing. >> >> >> > > >> >> >> > > In elflink.c, _bfd_elf_link_create_dynamic_sections assumes that >> >> >> > > executables should always have a .interp section. >> >> >> > > bfd_elf_size_dynamic_sections asserts this assumption again, and >> >> >> > > the >> >> >> > > individual elf??-*.c files also do so in >> >> >> > > *_elf_size_dynamic_sections >> >> >> > > where they set a default interpreter. (Is this even useful? Most of >> >> >> > > the names are out of touch with reality, and GCC always passes an >> >> >> > > explicit -dynamic-linker anyway, so I think this code should just >> >> >> > > be >> >> >> > > removed.) >> >> >> > > >> >> >> > > Now I have a working prototype by changing the info->executable >> >> >> > > condition to info->executable && info->dynamic, and having lexsup.c >> >> >> > > store the value of input_flags.dynamic in link_info.dynamic after >> >> >> > > processing the command line, but I'm not sure if this is the right >> >> >> > > approach. >> >> >> > >> >> >> > It is OK to use -static/-Bstatic/-non_shared with -shared and -pie. >> >> >> > I think you want --no-dynamic-linker. >> >> >> >> >> >> I see two overall approaches to making the option to omit .interp: >> >> >> >> >> >> 1. In elflink.c, make the creation of the .interp section conditional >> >> >>on a new field in link_info. >> >> >> >> >> >> 2. In ld code (ldlang.c? elf32.em?), check the command line option and >> >> >>remove the .interp section before it can be processed. >> >> >> >> >> >> I think option 1 is a lot cleaner, but it's also going to be a lot >> >> >> more invasive, because every single target arch (elf32-*.c and >> >> >> elf64-*.c) has its own ASSERT that the .interp section exists. These >> >> >> would also need to be updated to either check the new field in >> >> >> link_info, or to replace the ASSERT with a conditional. >> >> >> >> >> >> Before I spend a lot of time implementing one or the other, do you >> >> >> have any feelings on which way would be appropriate? >> >> > >> >> > I went ahead and did option 1 modulo all the target code except sh >> >> > which is where I'm testing it. My work-in-progress patch is attached. >> >> > This is obviously not ready to submit but I would appreciate any >> >> > feedback that's possible at this stage. >> >> >> >> + case OPTION_NO_DYNAMIC_LINKER: >> >> + command_line.interpreter = NULL; >> >> + link_info.nointerp = 1; >> >> >> >> No need to clear command_line.interpreter and please add a simple >> >> testcase to verify it works correctly. >> > >> > OK. Do I also need to update it to be against the new output_type >> > stuff you just committed? >> > >> >> That is a good idea. > > I've updated the patch to cover the changes needed for all the > elf??-*.c target files (lots of code duplication already there), skip > the clearing of command_line.interpreter, and based it on current git > master with your output_type changes. > > I haven't done a test case yet -- I looked briefly but couldn't find > documentation on how to add one. Is there a guide or template I should > look at? And do I need to open a BZ issue for the feature request, or > can non-bug changes like this skip BZ? > I don't think a new command line option is needed. You add a new bit, nointerp_set: 1. For -static: if nointerp_set is 0; then nointerp = 1. 2. For -Bdynamic" nointerlp_set = 1. -- H.J.
Re: Moving to git
On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan wrote: > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely > wrote: >> On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote: >>>> >>>> Absolutely, a non-fast-forward push is anathema for anything other people >>>> might be working on. The git repository already prohibits this; people >>>> that >>>> want to push-rebase-push their own branches need to delete the branch >>>> before >>>> pushing again. >>> >>> On the FSF trunk and the main release branches - I agree this is a >>> complete no-no. >>> >>> A push-rebase-push development model is possible / may be useful when >>> the developers collaborating on that branch agree on that model. >> >> Teams following a different model could use a separate repo shared by >> those developers, not the gcc.gnu.org one. It's much easier to do that >> with git. > > Yes you are right they sure can, but one of the reasons that teams are > doing their development on a feature branch is so that they can obtain > feedback and collaborate with others in the community. People wanting > to adopt more aggressive uses of git should be allowed to do so in > their private branches as long as they are not able to mess up the > official branches in the repository. > > If there is no way to have some branches in a repo allow rebasing and > others not, that's fine but I'd like to know that's the case. > > Adopting restrictions on the official branches is quite right (list > below not extensive but it sounds like) ... > > a. no rebase / rewriting history > b. no git merges from feature branches. One very frustrating thing for me is "git bisect" doesn't always work. I think cherry-pick is OK, but probably not rebase nor merge. Can we enforce that "git bisect" must work on official branches? -- H.J.
Re: Moving to git
On Fri, Aug 21, 2015 at 6:59 AM, Markus Trippelsdorf wrote: > > BTW while I have your attention: Why are you constantly creating > (rebasing) and deleting branches? Why not simply use a local git tree > for this purpose? I want to share my branches with people who have no access to my local git repo. -- H.J.
Re: Moving to git
On Fri, Aug 21, 2015 at 7:33 AM, Andreas Schwab wrote: > "H.J. Lu" writes: > >> One very frustrating thing for me is "git bisect" doesn't always >> work. I think cherry-pick is OK, but probably not rebase nor merge. >> >> Can we enforce that "git bisect" must work on official branches? > > bisect works fine with merges. > I keep binutils users/hjl/linux/master branch: https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/hjl/linux/master up to date by "git merge origin/master". I never tried "git bisect" on it since I know that commits on that branch aren't consecutive. Also "git bisect" doesn't work on gcc trunk in GCC git mirror for commits around wide-int branch merge. -- H.J.
Re: Moving to git
On Fri, Aug 21, 2015 at 8:39 AM, Andreas Schwab wrote: > "H.J. Lu" writes: > >> up to date by "git merge origin/master". I never tried "git bisect" >> on it since I know that commits on that branch aren't consecutive. > > bisect works with any kind of repository. > >> Also "git bisect" doesn't work on gcc trunk in GCC git mirror >> for commits around wide-int branch merge. "git bisect good"/"git bisect bad" land my tree not on trunk when they are used on commits from wide-int branch merge. Those commits are 205112 205363 205375 205900 205966 205968 205968 205969 205670 205971 206028 206035 206689 209692 209944 -- H.J.
Re: Moving to git
On Fri, Aug 21, 2015 at 9:01 AM, Andreas Schwab wrote: > "H.J. Lu" writes: > >> "git bisect good"/"git bisect bad" land my tree not on trunk when >> they are used on commits from wide-int branch merge. > > Yes, that is bisect working as designed. But this doesn't help me bisect GCC trunk. -- H.J.
RFC: Support x86 interrupt and exception handlers
The interrupt and exception handlers are called by x86 processors. X86
hardware puts information on stack and calls the handler. The
requirements are
1. Both interrupt and exception handlers must use the 'IRET' instruction,
instead of the 'RET' instruction, to return from the handlers.
2. All registers are callee-saved in interrupt and exception handlers.
3. The difference between interrupt and exception handlers is the
exception handler must pop 'ERROR_CODE' off the stack before the 'IRET'
instruction.
The design goals of interrupt and exception handlers for x86 processors
are:
1. No new calling convention in compiler.
2. Support both 32-bit and 64-bit modes.
3. Flexible for compilers to optimize.
4. Easy to use by programmers.
To implement interrupt and exception handlers for x86 processors, a
compiler should support:
1. void * __builtin_ia32_interrupt_data (void)
This function returns a pointer to interrupt or exception data pushed
onto the stack by processor.
The __builtin_frame_address builtin isn't suitable for interrupt and
exception handlers since it returns the stack frame address on the
callee side and compiler may generate a new stack frame for stack
alignment.
2. 'interrupt' attribute
Use this attribute to indicate that the specified void function without
arguments is an interrupt handler. The compiler generates function entry
and exit sequences suitable for use in an interrupt handler when this
attribute is present. The 'IRET' instruction, instead of the
'RET' instruction, is used to return from interrupt handlers. All
registers, except for the EFLAGS register which is restored by the
'IRET' instruction, are preserved by the compiler. The red zone
isn't supported in an interrupt handler; that is an interrupt
handler can't access stack beyond the current stack pointer.
You can use the builtin '__builtin_ia32_interrupt_data' function to access
data pushed onto the stack by processor:
void
f () __attribute__ ((interrupt))
{
void *p = __builtin_ia32_interrupt_data ();
...
}
3. 'exception' attribute
Use 'exception' instead of 'interrupt' for handlers intended to be
used for 'exception' (i.e. those that must pop 'ERROR_CODE' off the
stack before the 'IRET' instruction):
void
f () __attribute__ ((exception))
{
void *p = __builtin_ia32_interrupt_data ();
...
}
Any comments, suggestions?
Thanks.
--
H.J.
Re: RFC: Support x86 interrupt and exception handlers
On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu wrote:
> The interrupt and exception handlers are called by x86 processors. X86
> hardware puts information on stack and calls the handler. The
> requirements are
>
> 1. Both interrupt and exception handlers must use the 'IRET' instruction,
> instead of the 'RET' instruction, to return from the handlers.
> 2. All registers are callee-saved in interrupt and exception handlers.
> 3. The difference between interrupt and exception handlers is the
> exception handler must pop 'ERROR_CODE' off the stack before the 'IRET'
> instruction.
>
> The design goals of interrupt and exception handlers for x86 processors
> are:
>
> 1. No new calling convention in compiler.
> 2. Support both 32-bit and 64-bit modes.
> 3. Flexible for compilers to optimize.
> 4. Easy to use by programmers.
>
> To implement interrupt and exception handlers for x86 processors, a
> compiler should support:
>
> 1. void * __builtin_ia32_interrupt_data (void)
I got a feedback on the name of this builtin function. Since
it also works for 64-bit, we should avoid ia32 in its name.
We'd like to change it to
void * __builtin_interrupt_data (void)
Any comments?
> This function returns a pointer to interrupt or exception data pushed
> onto the stack by processor.
>
> The __builtin_frame_address builtin isn't suitable for interrupt and
> exception handlers since it returns the stack frame address on the
> callee side and compiler may generate a new stack frame for stack
> alignment.
>
> 2. 'interrupt' attribute
>
> Use this attribute to indicate that the specified void function without
> arguments is an interrupt handler. The compiler generates function entry
> and exit sequences suitable for use in an interrupt handler when this
> attribute is present. The 'IRET' instruction, instead of the
> 'RET' instruction, is used to return from interrupt handlers. All
> registers, except for the EFLAGS register which is restored by the
> 'IRET' instruction, are preserved by the compiler. The red zone
> isn't supported in an interrupt handler; that is an interrupt
> handler can't access stack beyond the current stack pointer.
>
> You can use the builtin '__builtin_ia32_interrupt_data' function to access
> data pushed onto the stack by processor:
>
> void
> f () __attribute__ ((interrupt))
> {
> void *p = __builtin_ia32_interrupt_data ();
> ...
> }
>
> 3. 'exception' attribute
>
> Use 'exception' instead of 'interrupt' for handlers intended to be
> used for 'exception' (i.e. those that must pop 'ERROR_CODE' off the
> stack before the 'IRET' instruction):
>
> void
> f () __attribute__ ((exception))
> {
> void *p = __builtin_ia32_interrupt_data ();
> ...
> }
>
> Any comments, suggestions?
>
> Thanks.
>
>
> --
> H.J.
--
H.J.
Re: RFC: Support x86 interrupt and exception handlers
On Tue, Sep 15, 2015 at 2:45 PM, Matthew Fortune
wrote:
> H.J. Lu writes:
>> On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu wrote:
>> > The interrupt and exception handlers are called by x86 processors. X86
>> > hardware puts information on stack and calls the handler. The
>> > requirements are
>> >
>> > 1. Both interrupt and exception handlers must use the 'IRET' instruction,
>> > instead of the 'RET' instruction, to return from the handlers.
>> > 2. All registers are callee-saved in interrupt and exception handlers.
>> > 3. The difference between interrupt and exception handlers is the
>> > exception handler must pop 'ERROR_CODE' off the stack before the 'IRET'
>> > instruction.
>> >
>> > The design goals of interrupt and exception handlers for x86 processors
>> > are:
>> >
>> > 1. No new calling convention in compiler.
>> > 2. Support both 32-bit and 64-bit modes.
>> > 3. Flexible for compilers to optimize.
>> > 4. Easy to use by programmers.
>> >
>> > To implement interrupt and exception handlers for x86 processors, a
>> > compiler should support:
>> >
>> > 1. void * __builtin_ia32_interrupt_data (void)
>>
>> I got a feedback on the name of this builtin function. Since
>> it also works for 64-bit, we should avoid ia32 in its name.
>> We'd like to change it to
>>
>> void * __builtin_interrupt_data (void)
>>
>> Any comments?
>
> For what it's worth, this seems like a good plan to me. I don't know x86
> but how many variations of interrupt and exception handling mechanisms
> are there? If there are lots then you may want to make it clear which
> subset of them you intend to support. I just added a few more variations
> of interrupt handlers to MIPS and it got complicated quite quickly.
>
> I think I remember someone asking about interrupt handler support for
> x86 some time ago and the answer then was that there were too many
> variants to make it useful.
In my proposal, there are only 2 handlers: interrupt and exception.
__builtin_interrupt_data is provided to programmers to implement
different variants of those handlers.
>
>>
>> > This function returns a pointer to interrupt or exception data pushed
>> > onto the stack by processor.
>> >
>> > The __builtin_frame_address builtin isn't suitable for interrupt and
>> > exception handlers since it returns the stack frame address on the
>> > callee side and compiler may generate a new stack frame for stack
>> > alignment.
>> >
>> > 2. 'interrupt' attribute
>> >
>> > Use this attribute to indicate that the specified void function without
>> > arguments is an interrupt handler. The compiler generates function entry
>> > and exit sequences suitable for use in an interrupt handler when this
>> > attribute is present. The 'IRET' instruction, instead of the
>> > 'RET' instruction, is used to return from interrupt handlers. All
>> > registers, except for the EFLAGS register which is restored by the
>> > 'IRET' instruction, are preserved by the compiler. The red zone
>> > isn't supported in an interrupt handler; that is an interrupt
>> > handler can't access stack beyond the current stack pointer.
>> >
>> > You can use the builtin '__builtin_ia32_interrupt_data' function to access
>> > data pushed onto the stack by processor:
>> >
>> > void
>> > f () __attribute__ ((interrupt))
>> > {
>> > void *p = __builtin_ia32_interrupt_data ();
>> > ...
>> > }
>> >
>> > 3. 'exception' attribute
>> >
>> > Use 'exception' instead of 'interrupt' for handlers intended to be
>> > used for 'exception' (i.e. those that must pop 'ERROR_CODE' off the
>> > stack before the 'IRET' instruction):
>> >
>> > void
>> > f () __attribute__ ((exception))
>> > {
>> > void *p = __builtin_ia32_interrupt_data ();
>> > ...
>> > }
>> >
>> > Any comments, suggestions?
>> >
>> > Thanks.
>> >
>> >
>> > --
>> > H.J.
>>
>>
>>
>> --
>> H.J.
--
H.J.
Re: RFC: Support x86 interrupt and exception handlers
On Wed, Sep 16, 2015 at 12:07 AM, Matthew Fortune wrote: > H.J. Lu writes: >> On Tue, Sep 15, 2015 at 2:45 PM, Matthew Fortune >> wrote: >> > H.J. Lu writes: >> >> On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu wrote: >> >> > The interrupt and exception handlers are called by x86 processors. X86 >> >> > hardware puts information on stack and calls the handler. The >> >> > requirements are >> >> > >> >> > 1. Both interrupt and exception handlers must use the 'IRET' >> >> > instruction, >> >> > instead of the 'RET' instruction, to return from the handlers. >> >> > 2. All registers are callee-saved in interrupt and exception handlers. >> >> > 3. The difference between interrupt and exception handlers is the >> >> > exception handler must pop 'ERROR_CODE' off the stack before the 'IRET' >> >> > instruction. >> >> > >> >> > The design goals of interrupt and exception handlers for x86 processors >> >> > are: >> >> > >> >> > 1. No new calling convention in compiler. >> >> > 2. Support both 32-bit and 64-bit modes. >> >> > 3. Flexible for compilers to optimize. >> >> > 4. Easy to use by programmers. >> >> > >> >> > To implement interrupt and exception handlers for x86 processors, a >> >> > compiler should support: >> >> > >> >> > 1. void * __builtin_ia32_interrupt_data (void) >> >> >> >> I got a feedback on the name of this builtin function. Since >> >> it also works for 64-bit, we should avoid ia32 in its name. >> >> We'd like to change it to >> >> >> >> void * __builtin_interrupt_data (void) >> >> >> >> Any comments? >> > >> > For what it's worth, this seems like a good plan to me. I don't know x86 >> > but how many variations of interrupt and exception handling mechanisms >> > are there? If there are lots then you may want to make it clear which >> > subset of them you intend to support. I just added a few more variations >> > of interrupt handlers to MIPS and it got complicated quite quickly. >> > >> > I think I remember someone asking about interrupt handler support for >> > x86 some time ago and the answer then was that there were too many >> > variants to make it useful. >> >> In my proposal, there are only 2 handlers: interrupt and exception. >> __builtin_interrupt_data is provided to programmers to implement >> different variants of those handlers. > > Yes, I realised that but was just curious how many hardware interrupt > handling schemes there are for x86. I.e. How the handlers are glued into > an interrupt vector/how they get routed. Is there a generic piece of > code that could at least hook up/install an exception handler on most > x86 variants? > We only support writing interrupt handler in C. Hookup/install an interrupt handler is up to the programmer. -- H.J.
Re: RFC: Support x86 interrupt and exception handlers
On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu wrote:
>> To implement interrupt and exception handlers for x86 processors, a
>> compiler should support:
>>
>> 1. void * __builtin_ia32_interrupt_data (void)
>
> I got a feedback on the name of this builtin function. Since
> it also works for 64-bit, we should avoid ia32 in its name.
> We'd like to change it to
>
> void * __builtin_interrupt_data (void)
>
Here is the updated spec.
H.J.
---
The interrupt and exception handlers are called by x86 processors. X86
hardware pushes information onto stack and calls the handler. The
requirements are
1. Both interrupt and exception handlers must use the 'IRET' instruction,
instead of the 'RET' instruction, to return from the handlers.
2. All registers are callee-saved in interrupt and exception handlers.
3. The difference between interrupt and exception handlers is the
exception handler must pop 'ERROR_CODE' off the stack before the 'IRET'
instruction.
The design goals of interrupt and exception handlers for x86 processors
are:
1. No new calling convention in compiler.
2. Support both 32-bit and 64-bit modes.
3. Flexible for compilers to optimize.
4. Easy to use by programmers.
To implement interrupt and exception handlers for x86 processors, a
compiler should support:
1. void * __builtin_interrupt_data (void)
This function returns a pointer to interrupt or exception data pushed
onto the stack by processor.
The __builtin_frame_address builtin isn't suitable for interrupt and
exception handlers since it returns the stack frame address on the
callee side and compiler may generate a new stack frame for stack
alignment.
2. 'interrupt' attribute
Use this attribute to indicate that the specified void function without
arguments is an interrupt handler. The compiler generates function entry
and exit sequences suitable for use in an interrupt handler when this
attribute is present. The 'IRET' instruction, instead of the
'RET' instruction, is used to return from interrupt handlers. All
registers, except for the EFLAGS register which is restored by the
'IRET' instruction, are preserved by the compiler. The red zone
isn't supported in an interrupt handler; that is an interrupt
handler can't access stack beyond the current stack pointer.
You can use the builtin '__builtin_interrupt_data' function to access
data pushed onto the stack by processor:
void
f () __attribute__ ((interrupt))
{
void *p = __builtin_interrupt_data ();
...
}
3. 'exception' attribute
Use 'exception' instead of 'interrupt' for handlers intended to be
used for 'exception' (i.e. those that must pop 'ERROR_CODE' off the
stack before the 'IRET' instruction):
void
f () __attribute__ ((exception))
{
void *p = __builtin_interrupt_data ();
...
}
Re: RFC: Support x86 interrupt and exception handlers
On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu wrote:
> On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu wrote:
>>> To implement interrupt and exception handlers for x86 processors, a
>>> compiler should support:
>>>
>>> 1. void * __builtin_ia32_interrupt_data (void)
>>
>> I got a feedback on the name of this builtin function. Since
>> it also works for 64-bit, we should avoid ia32 in its name.
>> We'd like to change it to
>>
>> void * __builtin_interrupt_data (void)
>>
>
> Here is the updated spec.
>
This updated spec adds
unsigned int __builtin_exception_error (void)
unsigned long long int __builtin_exception_error (void)
This function returns the exception error code pushed onto the stack by
processor. Its return value is 64 bits in 64-bit mode and 32 bits in
32-bit mode. This function can only be used in exception handler.
It also changes the definition of
void * __builtin_interrupt_data (void)
so that it returns a pointer to the data layout pushed onto stack
by processor for both interrupt and exception handlers.
--
H.J.
---
The interrupt and exception handlers are called by x86 processors. X86
hardware pushes information onto stack and calls the handler. The
requirements are
1. Both interrupt and exception handlers must use the 'IRET' instruction,
instead of the 'RET' instruction, to return from the handlers.
2. All registers are callee-saved in interrupt and exception handlers.
3. The difference between interrupt and exception handlers is the
exception handler must pop 'ERROR_CODE' off the stack before the 'IRET'
instruction.
The design goals of interrupt and exception handlers for x86 processors
are:
1. No new calling convention in compiler.
2. Support both 32-bit and 64-bit modes.
3. Flexible for compilers to optimize.
4. Easy to use by programmers.
To implement interrupt and exception handlers for x86 processors, a
compiler should support:
1. void * __builtin_interrupt_data (void)
This function returns a pointer to the return address pushed onto the
stack by processor.
The __builtin_frame_address builtin isn't suitable for interrupt and
exception handlers since it returns the stack frame address on the
callee side and compiler may generate a new stack frame for stack
alignment.
2. unsigned int __builtin_exception_error (void)
unsigned long long int __builtin_exception_error (void)
This function returns the exception error code pushed onto the stack by
processor. Its return value is 64 bits in 64-bit mode and 32 bits in
32-bit mode. This function can only be used in exception handler.
3. 'interrupt' attribute
Use this attribute to indicate that the specified void function without
arguments is an interrupt handler. The compiler generates function entry
and exit sequences suitable for use in an interrupt handler when this
attribute is present. The 'IRET' instruction, instead of the
'RET' instruction, is used to return from interrupt handlers. All
registers, except for the EFLAGS register which is restored by the
'IRET' instruction, are preserved by the compiler. The red zone
isn't supported in the interrupted function; that is an interrupt
handler may access stack within 128 bytes of the current stack pointer.
You can use the builtin '__builtin_interrupt_data' function to access
the interrupt data pushed onto the stack by processor:
void
f () __attribute__ ((interrupt))
{
void *p = __builtin_interrupt_data ();
...
}
4. 'exception' attribute
Use 'exception' instead of 'interrupt' for handlers intended to be
used for 'exception' (i.e. those that must pop 'ERROR_CODE' off the
stack before the 'IRET' instruction).
You can use the builtin '__builtin_exception_error' function to
access the exception error code pushed onto the stack by processor
as well as the builtin '__builtin_interrupt_data' function to
access the exception data on stack:
void
f () __attribute__ ((exception))
{
unsigned int error = __builtin_exception_error ();
void *p = __builtin_interrupt_data ();
...
}
Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers
On Mon, Sep 21, 2015 at 11:52 AM, John Criswell wrote: > On 9/21/15 12:27 PM, H.J. Lu via cfe-dev wrote: >> >> On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu wrote: >>> >>> On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu wrote: >>>>> >>>>> To implement interrupt and exception handlers for x86 processors, a >>>>> compiler should support: >>>>> >>>>> 1. void * __builtin_ia32_interrupt_data (void) >>>> >>>> I got a feedback on the name of this builtin function. Since >>>> it also works for 64-bit, we should avoid ia32 in its name. >>>> We'd like to change it to >>>> >>>> void * __builtin_interrupt_data (void) >>>> >>> Here is the updated spec. >>> >> This updated spec adds >> >> unsigned int __builtin_exception_error (void) >> unsigned long long int __builtin_exception_error (void) >> >> This function returns the exception error code pushed onto the stack by >> processor. Its return value is 64 bits in 64-bit mode and 32 bits in >> 32-bit mode. This function can only be used in exception handler. > > > Exception handlers can, in general, call regular functions which, in turn, > might want to access the error code. Given that operating system kernels > are always entered via an interrupt, trap, or system call, there should > always be an error code available (on x86, non-error-code interrupts can > just make up an error code). > >> >> It also changes the definition of >> >> void * __builtin_interrupt_data (void) >> >> so that it returns a pointer to the data layout pushed onto stack >> by processor for both interrupt and exception handlers. >> >> > > You might want to have a look at Secure Virtual Architecture (SVA). One of I believe my x86 interrupt attribute is unrelated to SVA. > If the implementation is useful, SVA is publicly available at > https://github.com/jtcriswell/SVA. > > Finally, to echo Joerg's concerns, it's not clear that having > exception/interrupt handlers declared as a special type is really helpful. > It's not immediately obvious that you get a benefit from doing that vs. > doing what most system software does (having assembly code that saves > processor state and calls a C function). I think you should do some > experiments to demonstrate the benefit that one can get with your method to > see if it is worth adding complexity to the compiler. > The main purpose of x86 interrupt attribute is to allow programmers to write x86 interrupt/exception handlers in C WITHOUT assembly stubs to avoid extra branch from assembly stubs to C functions. I want to keep the number of new intrinsics to minimum without sacrificing handler performance. I leave faking error code in interrupt handler to the programmer. -- H.J.
Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers
On Mon, Sep 21, 2015 at 2:23 PM, John Criswell wrote: > On 9/21/15 4:45 PM, H.J. Lu wrote: >> >> On Mon, Sep 21, 2015 at 11:52 AM, John Criswell >> wrote: >>> >>> On 9/21/15 12:27 PM, H.J. Lu via cfe-dev wrote: >>>> >>>> On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu wrote: >>>>> >>>>> On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu wrote: >>>>>>> >>>>>>> To implement interrupt and exception handlers for x86 processors, a >>>>>>> compiler should support: >>>>>>> >>>>>>> 1. void * __builtin_ia32_interrupt_data (void) >>>>>> >>>>>> I got a feedback on the name of this builtin function. Since >>>>>> it also works for 64-bit, we should avoid ia32 in its name. >>>>>> We'd like to change it to >>>>>> >>>>>> void * __builtin_interrupt_data (void) >>>>>> >>>>> Here is the updated spec. >>>>> >>>> This updated spec adds >>>> >>>> unsigned int __builtin_exception_error (void) >>>> unsigned long long int __builtin_exception_error (void) >>>> >>>> This function returns the exception error code pushed onto the stack by >>>> processor. Its return value is 64 bits in 64-bit mode and 32 bits in >>>> 32-bit mode. This function can only be used in exception handler. >>> >>> >>> Exception handlers can, in general, call regular functions which, in >>> turn, >>> might want to access the error code. Given that operating system kernels >>> are always entered via an interrupt, trap, or system call, there should >>> always be an error code available (on x86, non-error-code interrupts can >>> just make up an error code). >>> >>>> It also changes the definition of >>>> >>>> void * __builtin_interrupt_data (void) >>>> >>>> so that it returns a pointer to the data layout pushed onto stack >>>> by processor for both interrupt and exception handlers. >>>> >>>> >>> You might want to have a look at Secure Virtual Architecture (SVA). One >>> of >> >> I believe my x86 interrupt attribute is unrelated to SVA. > > > Actually, I really think that it is. Part of the SVA work extended the LLVM > IR to support an operating system kernel. Your design for interrupt > handlers and accessing interrupted program state looks very similar to my > first draft of those extensions and has the exact same limitations (plus at > least one limitation that my design did not have). It's pretty clear to me > that you're redesigning a subset of the SVA-OS extensions from scratch; I > find that unfortunate because you are literally reinventing the wheel. > >> >>> If the implementation is useful, SVA is publicly available at >>> https://github.com/jtcriswell/SVA. >>> >>> Finally, to echo Joerg's concerns, it's not clear that having >>> exception/interrupt handlers declared as a special type is really >>> helpful. >>> It's not immediately obvious that you get a benefit from doing that vs. >>> doing what most system software does (having assembly code that saves >>> processor state and calls a C function). I think you should do some >>> experiments to demonstrate the benefit that one can get with your method >>> to >>> see if it is worth adding complexity to the compiler. >>> >> The main purpose of x86 interrupt attribute is to allow programmers >> to write x86 interrupt/exception handlers in C WITHOUT assembly >> stubs to avoid extra branch from assembly stubs to C functions. I >> want to keep the number of new intrinsics to minimum without sacrificing >> handler performance. I leave faking error code in interrupt handler to >> the programmer. >> > > If you want to do that, there is another approach that should work just as > well and will require only localized changes to the compiler. > > Interrupt handlers are typically registered to some interrupt vector number > using a registration function. In FreeBSD, it's setidt(), and in Linux, I > think it's set_gate(). You can write a compiler transform that looks for > these registration functions, determines the function that is registered as > an interrupt handler, and generate the more efficient code for that > interrupt handler function as you describe. > > This solution avoids language exte
Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers
On Mon, Sep 21, 2015 at 3:40 PM, Hal Finkel wrote: > - Original Message - >> From: "H.J. Lu via cfe-dev" >> To: "GCC Development" , cfe-...@lists.llvm.org >> Sent: Monday, September 21, 2015 11:27:18 AM >> Subject: Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers >> >> On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu >> wrote: >> > On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu >> > wrote: >> >>> To implement interrupt and exception handlers for x86 processors, >> >>> a >> >>> compiler should support: >> >>> >> >>> 1. void * __builtin_ia32_interrupt_data (void) >> >> >> >> I got a feedback on the name of this builtin function. Since >> >> it also works for 64-bit, we should avoid ia32 in its name. >> >> We'd like to change it to >> >> >> >> void * __builtin_interrupt_data (void) >> >> >> > >> > Here is the updated spec. >> > >> >> This updated spec adds >> >>unsigned int __builtin_exception_error (void) >>unsigned long long int __builtin_exception_error (void) >> >> This function returns the exception error code pushed onto the stack >> by >> processor. Its return value is 64 bits in 64-bit mode and 32 bits in >> 32-bit mode. This function can only be used in exception handler. >> >> It also changes the definition of >> >> void * __builtin_interrupt_data (void) >> >> so that it returns a pointer to the data layout pushed onto stack >> by processor for both interrupt and exception handlers. >> >> >> -- >> H.J. >> --- >> The interrupt and exception handlers are called by x86 processors. >> X86 >> hardware pushes information onto stack and calls the handler. The >> requirements are >> >> 1. Both interrupt and exception handlers must use the 'IRET' >> instruction, >> instead of the 'RET' instruction, to return from the handlers. >> 2. All registers are callee-saved in interrupt and exception >> handlers. >> 3. The difference between interrupt and exception handlers is the >> exception handler must pop 'ERROR_CODE' off the stack before the >> 'IRET' >> instruction. >> >> The design goals of interrupt and exception handlers for x86 >> processors >> are: >> >> 1. No new calling convention in compiler. >> 2. Support both 32-bit and 64-bit modes. >> 3. Flexible for compilers to optimize. >> 4. Easy to use by programmers. >> >> To implement interrupt and exception handlers for x86 processors, a >> compiler should support: >> >> 1. void * __builtin_interrupt_data (void) >> >> This function returns a pointer to the return address pushed onto the >> stack by processor. >> >> The __builtin_frame_address builtin isn't suitable for interrupt and >> exception handlers since it returns the stack frame address on the >> callee side and compiler may generate a new stack frame for stack >> alignment. >> >> 2. unsigned int __builtin_exception_error (void) >>unsigned long long int __builtin_exception_error (void) >> >> This function returns the exception error code pushed onto the stack >> by >> processor. Its return value is 64 bits in 64-bit mode and 32 bits in >> 32-bit mode. This function can only be used in exception handler. > > Instead of adding more builtins for these, why not simply model this by > giving the handler function a non-trivial signature? So, for example, the > interrupt handler would be: > > void handler(void *); > > and the exception handler would be: > > void handler(size_t); > Since x86 interrupt/exception handlers don't conform to any x86 psABI, you need to modify compiler to generate proper codes for void handler(void *); Please take a look at interrupt/exception handlers section in Intel SDM vol 3. -- H.J.
Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers
On Mon, Sep 21, 2015 at 4:03 PM, Hal Finkel wrote: > - Original Message - >> From: "H.J. Lu" >> To: "Hal Finkel" >> Cc: "GCC Development" , cfe-...@lists.llvm.org >> Sent: Monday, September 21, 2015 5:57:36 PM >> Subject: Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers >> >> On Mon, Sep 21, 2015 at 3:40 PM, Hal Finkel wrote: >> > - Original Message - >> >> From: "H.J. Lu via cfe-dev" >> >> To: "GCC Development" , cfe-...@lists.llvm.org >> >> Sent: Monday, September 21, 2015 11:27:18 AM >> >> Subject: Re: [cfe-dev] RFC: Support x86 interrupt and exception >> >> handlers >> >> >> >> On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu >> >> wrote: >> >> > On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu >> >> > wrote: >> >> >>> To implement interrupt and exception handlers for x86 >> >> >>> processors, >> >> >>> a >> >> >>> compiler should support: >> >> >>> >> >> >>> 1. void * __builtin_ia32_interrupt_data (void) >> >> >> >> >> >> I got a feedback on the name of this builtin function. Since >> >> >> it also works for 64-bit, we should avoid ia32 in its name. >> >> >> We'd like to change it to >> >> >> >> >> >> void * __builtin_interrupt_data (void) >> >> >> >> >> > >> >> > Here is the updated spec. >> >> > >> >> >> >> This updated spec adds >> >> >> >>unsigned int __builtin_exception_error (void) >> >>unsigned long long int __builtin_exception_error (void) >> >> >> >> This function returns the exception error code pushed onto the >> >> stack >> >> by >> >> processor. Its return value is 64 bits in 64-bit mode and 32 bits >> >> in >> >> 32-bit mode. This function can only be used in exception handler. >> >> >> >> It also changes the definition of >> >> >> >> void * __builtin_interrupt_data (void) >> >> >> >> so that it returns a pointer to the data layout pushed onto stack >> >> by processor for both interrupt and exception handlers. >> >> >> >> >> >> -- >> >> H.J. >> >> --- >> >> The interrupt and exception handlers are called by x86 processors. >> >> X86 >> >> hardware pushes information onto stack and calls the handler. The >> >> requirements are >> >> >> >> 1. Both interrupt and exception handlers must use the 'IRET' >> >> instruction, >> >> instead of the 'RET' instruction, to return from the handlers. >> >> 2. All registers are callee-saved in interrupt and exception >> >> handlers. >> >> 3. The difference between interrupt and exception handlers is the >> >> exception handler must pop 'ERROR_CODE' off the stack before the >> >> 'IRET' >> >> instruction. >> >> >> >> The design goals of interrupt and exception handlers for x86 >> >> processors >> >> are: >> >> >> >> 1. No new calling convention in compiler. >> >> 2. Support both 32-bit and 64-bit modes. >> >> 3. Flexible for compilers to optimize. >> >> 4. Easy to use by programmers. >> >> >> >> To implement interrupt and exception handlers for x86 processors, >> >> a >> >> compiler should support: >> >> >> >> 1. void * __builtin_interrupt_data (void) >> >> >> >> This function returns a pointer to the return address pushed onto >> >> the >> >> stack by processor. >> >> >> >> The __builtin_frame_address builtin isn't suitable for interrupt >> >> and >> >> exception handlers since it returns the stack frame address on the >> >> callee side and compiler may generate a new stack frame for stack >> >> alignment. >> >> >> >> 2. unsigned int __builtin_exception_error (void) >> >>unsigned long long int __builtin_exception_error (void) >> >> >> >> This function returns the exception error code pushed onto the >> >> stack >> >> b
Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers
On Tue, Sep 22, 2015 at 1:11 AM, Hal Finkel wrote: > - Original Message - >> From: "H.J. Lu" >> To: "Hal Finkel" >> Cc: "GCC Development" , cfe-...@lists.llvm.org >> Sent: Monday, September 21, 2015 7:17:20 PM >> Subject: Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers >> >> On Mon, Sep 21, 2015 at 4:03 PM, Hal Finkel wrote: >> > - Original Message - >> >> From: "H.J. Lu" >> >> To: "Hal Finkel" >> >> Cc: "GCC Development" , cfe-...@lists.llvm.org >> >> Sent: Monday, September 21, 2015 5:57:36 PM >> >> Subject: Re: [cfe-dev] RFC: Support x86 interrupt and exception >> >> handlers >> >> >> >> On Mon, Sep 21, 2015 at 3:40 PM, Hal Finkel >> >> wrote: >> >> > - Original Message - >> >> >> From: "H.J. Lu via cfe-dev" >> >> >> To: "GCC Development" , cfe-...@lists.llvm.org >> >> >> Sent: Monday, September 21, 2015 11:27:18 AM >> >> >> Subject: Re: [cfe-dev] RFC: Support x86 interrupt and exception >> >> >> handlers >> >> >> >> >> >> On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu >> >> >> wrote: >> >> >> > On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu >> >> >> > >> >> >> > wrote: >> >> >> >>> To implement interrupt and exception handlers for x86 >> >> >> >>> processors, >> >> >> >>> a >> >> >> >>> compiler should support: >> >> >> >>> >> >> >> >>> 1. void * __builtin_ia32_interrupt_data (void) >> >> >> >> >> >> >> >> I got a feedback on the name of this builtin function. >> >> >> >> Since >> >> >> >> it also works for 64-bit, we should avoid ia32 in its name. >> >> >> >> We'd like to change it to >> >> >> >> >> >> >> >> void * __builtin_interrupt_data (void) >> >> >> >> >> >> >> > >> >> >> > Here is the updated spec. >> >> >> > >> >> >> >> >> >> This updated spec adds >> >> >> >> >> >>unsigned int __builtin_exception_error (void) >> >> >>unsigned long long int __builtin_exception_error (void) >> >> >> >> >> >> This function returns the exception error code pushed onto the >> >> >> stack >> >> >> by >> >> >> processor. Its return value is 64 bits in 64-bit mode and 32 >> >> >> bits >> >> >> in >> >> >> 32-bit mode. This function can only be used in exception >> >> >> handler. >> >> >> >> >> >> It also changes the definition of >> >> >> >> >> >> void * __builtin_interrupt_data (void) >> >> >> >> >> >> so that it returns a pointer to the data layout pushed onto >> >> >> stack >> >> >> by processor for both interrupt and exception handlers. >> >> >> >> >> >> >> >> >> -- >> >> >> H.J. >> >> >> --- >> >> >> The interrupt and exception handlers are called by x86 >> >> >> processors. >> >> >> X86 >> >> >> hardware pushes information onto stack and calls the handler. >> >> >> The >> >> >> requirements are >> >> >> >> >> >> 1. Both interrupt and exception handlers must use the 'IRET' >> >> >> instruction, >> >> >> instead of the 'RET' instruction, to return from the handlers. >> >> >> 2. All registers are callee-saved in interrupt and exception >> >> >> handlers. >> >> >> 3. The difference between interrupt and exception handlers is >> >> >> the >> >> >> exception handler must pop 'ERROR_CODE' off the stack before >> >> >> the >> >> >> 'IRET' >> >> >> instruction. >> >> >> >> >> >> The design goals of interrupt and exception
Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers
On Tue, Sep 22, 2015 at 1:41 AM, David Chisnall wrote: > On 21 Sep 2015, at 21:45, H.J. Lu via cfe-dev wrote: >> >> The main purpose of x86 interrupt attribute is to allow programmers >> to write x86 interrupt/exception handlers in C WITHOUT assembly >> stubs to avoid extra branch from assembly stubs to C functions. I >> want to keep the number of new intrinsics to minimum without sacrificing >> handler performance. I leave faking error code in interrupt handler to >> the programmer. > > The assembly stubs have to come from somewhere. You either put them in an > assembly file (most people doing embedded x86 stuff steal the ones from > NetBSD), or you put them in the compiler where they can be inlined. In terms > of user interface, there’s not much difference in complexity. Having written > this kind of code in the past, I can honestly say that using the assembly > stubs was the least difficult part of getting them right. In terms of > compiler complexity, there’s a big difference: in one case the compiler > contains nothing, in the other it contains something special for a single use > case. In terms of performance, the compiler version has the potential to be > faster, but if we’re going to pay for the complexity then I think that we’d > need to see some strong evidence that someone else is getting a noticeable > benefit. I understand your concern. IA MCU users want to write interrupt/exception handlers in C, just like many embedded processors. The goals are to save code space and improve performance. Using builtin functions, instead of adding a new way to pass parameters, makes compiler change much simpler, since __builtin_exception_error () is the same as __builtin_return_address (0) and __builtin_interrupt_data () is address of __builtin_exception_error () + size of register. -- H.J.
Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers
On Tue, Sep 22, 2015 at 4:44 AM, David Chisnall wrote: > On 22 Sep 2015, at 12:39, H.J. Lu via cfe-dev wrote: >> >> The center piece of my proposal is not to change how parameters >> are passed in compiler. As for user experience, the feedbacks on >> my proposal from our users are very positive. > > Implementing the intrinsics for getting the current interrupt requires a lot > of support code for it to actually be useful. For it to be useful, you are > requiring all of the C code to be run with interrupts disabled (and even that > doesn’t work if you get a NMI in the middle). Most implementations use a > small amount of assembly to capture the interrupt cause and the register > state on entry to the handler, then reenable interrupts while the C code > runs. This means that any interrupts (e.g. page faults, illegal instruction > traps, whatever) that happen while the C code is running do not mask the > values. Accessing these values from *existing* C code is simply a matter of > loading a field from a structure. The above applies to with and without intrinsics. > I’m really unconvinced by something that something with such a narrow use > case (and one that encourages writing bad code) belongs in the compiler. > > David -- H.J.
Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers
On Tue, Sep 22, 2015 at 11:13 AM, Richard Henderson wrote:
>
> HJ, I think Hal is right. Providing the data via arguments is vastly superior
> to providing it via builtins. I had actually been thinking the same thing
> myself.
>
> It should be easy to check that the function has the correct signature in the
> hook adding the attribute. It should also be easy to check for the attribute
> at the beginning of ix86_function_arg et al, in order to handle these special
> cases.
>
Thanks for all feedbacks. Here is the updated spec.
--
H.J.
---
The interrupt and exception handlers are called by x86 processors. X86
hardware pushes information onto stack and calls the handler. The
requirements are
1. Both interrupt and exception handlers must use the 'IRET' instruction,
instead of the 'RET' instruction, to return from the handlers.
2. All registers are callee-saved in interrupt and exception handlers.
3. The difference between interrupt and exception handlers is the
exception handler must pop 'ERROR_CODE' off the stack before the 'IRET'
instruction.
The design goals of interrupt and exception handlers for x86 processors
are:
1. Support both 32-bit and 64-bit modes.
2. Flexible for compilers to optimize.
3. Easy to use by programmers.
To implement interrupt and exception handlers for x86 processors, a
compiler should support:
'interrupt' attribute
Use this attribute to indicate that the specified function with
mandatory arguments is an interrupt or exception handler. The compiler
generates function entry and exit sequences suitable for use in an
interrupt handler when this attribute is present. The 'IRET' instruction,
instead of the 'RET' instruction, is used to return from interrupt or
exception handlers. All registers, except for the EFLAGS register which
is restored by the 'IRET' instruction, are preserved by the compiler.
Any interruptible-without-stack-switch code must be compiled with
-mno-red-zone since interrupt handlers can and will, because of the
hardware design, touch the red zone.
1. interrupt handler must be declared with a mandatory argument:
#ifdef __x86_64__
typedef unsigned long long int uword_t;
#else
typedef unsigned int uword_t;
#endif
struct interrupt_frame
{
uword_t ip;
uword_t cs;
uword_t flags;
uword_t sp;
uword_t ss;
};
__attribute__ ((interrupt))
void
f (struct interrupt_frame *frame)
{
...
}
2. exception handler:
The exception handler is very similar to the interrupt handler with
a different mandatory function signature:
__attribute__ ((interrupt))
void
f (struct interrupt_frame *frame, uword_t error_code)
{
...
}
and compiler pops `ERROR_CODE' off stack before the 'IRET' instruction.
The exception handler should only be used for exceptions which push an
error code and all other exceptions must use the interrupt handler.
The system will crash if the wrong handler is used.
Re: different results from objdump for Ubuntu and Windows
On Mon, Sep 28, 2015 at 2:23 PM, Helen Tang wrote: > I built a gcc toolchain on Ubuntu and cygwin on Windows. The results > from objdump are different. Is this normal? Is there a way to make > them the same? It shouldn't happen on the same input file. If it does, please open a bug report. -- H.J.
Re: gold on trunk breaks aarch64- and arm32-linux (Re: [gold][PATCH] PR gold/19119: Gold accepts bogus target emulation)
On Sun, Oct 25, 2015 at 10:37 AM, Matthias Klose wrote: > On 15.10.2015 17:57, Cary Coutant wrote: >>> >>> PR gold/19119 >>> * options.h (General_options): Remove "obsolete" from -m. >> >> >> I'm a little reluctant to remove "obsolete" from the description -- >> maybe "deprecated" instead? >> >>> * parameters.cc (set_parameters_target): Check if input target >>> is compatible with output emulation set by "-m emulation". >> >> >> This is OK. Thanks! > > > hmm, this breaks any released gcc on aarch64-linux-gnu and > arm-linux-gnueabi* > > $ gcc -fuse-ld=gold foo.c > /usr/bin/ld.gold: error: unrecognised output emulation: aarch64linux > collect2: error: ld returned 1 exit status > > $ gcc -fuse-ld=gold foo.c > /usr/bin/ld.gold: error: unrecognised output emulation: armelf_linux_eabi > collect2: error: ld returned 1 exit status > What do ld.bfd -V and ld.gold -V report? They should support the same set of emulations. -- H.J.
Re: gold on trunk breaks powerpc-, aarch64- and arm32-linux (Re: [gold][PATCH] PR gold/19119: Gold accepts bogus target emulation)
On Sun, Oct 25, 2015 at 4:50 PM, Matthias Klose wrote: > On 25.10.2015 18:40, H.J. Lu wrote: >> >> On Sun, Oct 25, 2015 at 10:37 AM, Matthias Klose wrote: >>> >>> On 15.10.2015 17:57, Cary Coutant wrote: >>>>> >>>>> >>>>> PR gold/19119 >>>>> * options.h (General_options): Remove "obsolete" from -m. >>>> >>>> >>>> >>>> I'm a little reluctant to remove "obsolete" from the description -- >>>> maybe "deprecated" instead? >>>> >>>>> * parameters.cc (set_parameters_target): Check if input >>>>> target >>>>> is compatible with output emulation set by "-m emulation". >>>> >>>> >>>> >>>> This is OK. Thanks! >>> >>> >>> >>> hmm, this breaks any released gcc on aarch64-linux-gnu and >>> arm-linux-gnueabi* >>> >>> $ gcc -fuse-ld=gold foo.c >>> /usr/bin/ld.gold: error: unrecognised output emulation: aarch64linux >>> collect2: error: ld returned 1 exit status >>> >>> $ gcc -fuse-ld=gold foo.c >>> /usr/bin/ld.gold: error: unrecognised output emulation: armelf_linux_eabi >>> collect2: error: ld returned 1 exit status >>> >> >> What do ld.bfd -V and ld.gold -V report? They should support the >> same set of emulations. >> > > powerpc-linux-gnu as well: > /usr/bin/ld.gold: error: unrecognised output emulation: elf32ppclinux > > > aarch64-linux:gnu > > gold: supported emulations: aarch64_elf64_le_vec aarch64_elf64_be_vec > aarch64_elf32_le_vec aarch64_elf32_be_vec elf64-tradlittlemips > elf32-tradlittlemips-nacl elf64-tradbigmips elf32-tradlittlemips-nacl > elf32-tradlittlemips elf32-tradlittlemips-nacl elf32-tradbigmips > elf32-tradlittlemips-nacl elf32tilegx_be elf64tilegx_be elf32tilegx > elf64tilegx armelfb armelfb_nacl armelf armelf_nacl elf64lppc elf64ppc > elf32lppc elf32ppc elf64_sparc elf32_sparc elf32_x86_64 elf32_x86_64_nacl > elf_x86_64 elf_x86_64_nacl elf_iamcu elf_i386 elf_i386_nacl > > $ ld -V > GNU ld (GNU Binutils for Ubuntu) 2.25.51.20151022 > Supported emulations: >aarch64linux >aarch64elf >aarch64elf32 >aarch64elf32b >aarch64elfb >armelf >armelfb >aarch64linuxb >aarch64linux32 >aarch64linux32b >armelfb_linux_eabi >armelf_linux_eabi > > > arm-linux-gnueabihf > > gold: supported emulations: aarch64_elf64_le_vec aarch64_elf64_be_vec > aarch64_elf32_le_vec aarch64_elf32_be_vec elf64-tradlittlemips > elf32-tradlittlemips-nacl elf64-tradbigmips elf32-tradlittlemips-nacl > elf32-tradlittlemips elf32-tradlittlemips-nacl elf32-tradbigmips > elf32-tradlittlemips-nacl elf32tilegx_be elf64tilegx_be elf32tilegx > elf64tilegx armelfb armelfb_nacl armelf armelf_nacl elf64lppc elf64ppc > elf32lppc elf32ppc elf64_sparc elf32_sparc elf32_x86_64 elf32_x86_64_nacl > elf_x86_64 elf_x86_64_nacl elf_iamcu elf_i386 elf_i386_nacl > > $ ld -V > GNU ld (GNU Binutils for Ubuntu) 2.25.51.20151022 > Supported emulations: >armelf_linux_eabi >armelfb_linux_eabi > > > powerpc-linux-gnu > > supported emulations: elf64lppc elf64ppc elf32lppc elf32ppc > > $ ld -V > GNU ld (GNU Binutils for Ubuntu) 2.25.1 > Supported emulations: >elf32ppclinux >elf32ppc >elf32ppcsim >elf64ppc > Please open a gold bug with missing emulations. -- H.J.
Updated x86-64 psABI
Hi, The x86-64 psABI has been updated to revision 248. Main changes are 1. Support Intel MPX. 2. Add a chapter for linker optimization. 3. Add 2 new relocations, R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX. MPX supported has been checked into GCC 5 and ld in binutils 2.25. Linker optimization has been added to ld in binutils 2.25 and gold in binutils 2.26. Gold and ld in binutils 2.26 supports new relocations. Ld in binutils 2.26 can optimize new relocations. The psABI PDF files are available at https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI The x86-64 psABI draft 2015-11-18 contains updated MPX spec. -- H.J.
Re: Updated x86-64 psABI
On Wed, Nov 18, 2015 at 1:47 PM, H.J. Lu wrote: > Hi, > > The x86-64 psABI has been updated to revision 248. Main changes are > > 1. Support Intel MPX. > 2. Add a chapter for linker optimization. > 3. Add 2 new relocations, R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX. > > MPX supported has been checked into GCC 5 and ld in binutils 2.25. > Linker optimization has been added to ld in binutils 2.25 and gold > in binutils 2.26. Gold and ld in binutils 2.26 supports new relocations. > Ld in binutils 2.26 can optimize new relocations. > > The psABI PDF files are available at > > https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI > > The x86-64 psABI draft 2015-11-18 contains updated MPX spec. I uploaded x86-64 psABI revision 249, which is equivalent to the x86-64 psABI draft 2015-11-18, PDF file to https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf -- H.J.
[middle-end] How to handle fake register in DECL_INCOMING_RTL?
When implementing interrupt attribute for x86 interrupt handlers, we have a difficult time to access interrupt data passed down by x86 processors. On x86, interrupt handlers are only called by processors which push interrupt data onto stack at the address where the normal return address is. Interrupt handlers must access interrupt data via pointers so that they can update interrupt data. TARGET_FUNCTION_ARG_ADVANCE is skipped by interrupt handlers since they are only called by processors. Since interrupt data is at one word below the normal argument location on stack and must be accessed via pointer, we changed TARGET_FUNCTION_ARG to return a fake hard register for interrupt handlers and updated expander to covert the fake register to its address on stack. However, we run into problems with /* For PARM_DECL, holds an RTL for the stack slot or register where the data was actually passed. */ #define DECL_INCOMING_RTL(NODE) \ (PARM_DECL_CHECK (NODE)->parm_decl.incoming_rtl) >From what I can tell, DECL_INCOMING_RTL is a constant after it is set up. For interrupt handlers, DECL_INCOMING_RTL contains a fake register, which isn't a problem in codegen since it is covered by expander. But DECL_INCOMING_RTL is also used to generate debug information and debug output never expects a fake register in DECL_INCOMING_RTL. To work around it, we changed x86 prologue expander to update DECL_INCOMING_RTL with the fake register in interrupt handlers to its address on stack. We are asking middle-end maintainers, is this a correct solution? If not, what other approaches should we try? -- H.J.
RFC: Intel386 psABI version 1.1 draft
Hi, Here is the Intel386 psABI version 1.1 draft: https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-20151120.pdf Main changes are 1. Add AVX-512 support. 2. Add linker optimization to combine GOTPLT and GOT slots. 3. Add R_386_GOT32X relocation and linker optimization. 4. Add FS/GS Base addresses to DWARF register number mapping. 5. Add Intel MPX support. MPX supported has been checked into GCC 5. Linker optimization has been added to ld in binutils 2.25 and gold in binutils 2.26. Gold and ld in binutils 2.26 supports new relocations. Ld in binutils 2.26 can optimize new relocations. Any comments and feedbacks? Thanks. -- H.J.
Re: RFC: Intel386 psABI version 1.1 draft
On Tue, Nov 24, 2015 at 8:16 AM, H.J. Lu wrote: > Hi, > > Here is the Intel386 psABI version 1.1 draft: > > https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-20151120.pdf > > Main changes are > > 1. Add AVX-512 support. > 2. Add linker optimization to combine GOTPLT and GOT slots. > 3. Add R_386_GOT32X relocation and linker optimization. > 4. Add FS/GS Base addresses to DWARF register number mapping. > 5. Add Intel MPX support. > > MPX supported has been checked into GCC 5. Linker optimization has > been added to ld in binutils 2.25 and gold in binutils 2.26. Gold and ld in > binutils 2.26 supports new relocations. Ld in binutils 2.26 can optimize > new relocations. > > Any comments and feedbacks? > Here is the Intel386 psABI version 1.1: https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-1.1.pdf -- H.J.
Re: x86 interrupt attribute
On Mon, Jan 18, 2016 at 9:39 AM, Wink Saville wrote: > What is the status of the x86 interrupt attribute patch? > > One of the last references I see is here and an attempt to update the > middle-end here. > > -- Wink You can try hjl/interrupt/stage1 branch in git repo, which is queued for GCC 7. -- H.J.
Re: x86 interrupt attribute
On Mon, Jan 18, 2016 at 10:27 AM, Wink Saville wrote: > It looks like it will be awhile before its included, what's your guess > on when stage1 will commence for GCC 7? > > About how often will you be rebasing hjl/interrupt/stage1 onto master? I update hjl/interrupt/stage1 branch about once a week. > On Mon, Jan 18, 2016 at 9:47 AM H.J. Lu wrote: >> >> On Mon, Jan 18, 2016 at 9:39 AM, Wink Saville wrote: >> > What is the status of the x86 interrupt attribute patch? >> > >> > One of the last references I see is here and an attempt to update the >> > middle-end here. >> > >> > -- Wink >> >> You can try hjl/interrupt/stage1 branch in git repo, which is queued for >> GCC 7. >> >> -- >> H.J. -- H.J.
RFA: Add GCC Runtime Library Exception to include/plugin-api.h
include/plugin-api.h defines an ABI between linker and compiler, which can be used to implement linker plug-in by any compilers. I'd like to add GCC Runtime Library Exception to include/plugin-api.h so that the linker plug-in can have non-GPL licenses. Thanks. -- H.J.
Re: Compiling with -m64 using attribute interrupt emits IRET not IRETQ
On Thu, Jan 28, 2016 at 9:06 AM, Wink Saville wrote: > I using hjl/interrupt/gcc-5-branch and my program is crashing when I > issue an INT xx. The problem appears to me to be that using > __attribute__ ((interrupt)) causes the a IRET to be emitted when an > IRETQ should be emitted. Below is my trivial do nothing main.c which I > compile with and then use objdump to view the assembler source. > > I compiled x86_64-unknown-elf- using crosstool-ng, could that be a > problem? I fixed it on hjl/interrupt/gcc-5-branch branch. I will fix it for hjl/interrupt/stage1 soon. Thanks. -- H.J.
Re: Compiling with -m64 using attribute interrupt emits IRET not IRETQ
On Thu, Jan 28, 2016 at 10:26 AM, H.J. Lu wrote: > On Thu, Jan 28, 2016 at 9:06 AM, Wink Saville wrote: >> I using hjl/interrupt/gcc-5-branch and my program is crashing when I >> issue an INT xx. The problem appears to me to be that using >> __attribute__ ((interrupt)) causes the a IRET to be emitted when an >> IRETQ should be emitted. Below is my trivial do nothing main.c which I >> compile with and then use objdump to view the assembler source. >> >> I compiled x86_64-unknown-elf- using crosstool-ng, could that be a >> problem? > > I fixed it on hjl/interrupt/gcc-5-branch branch. I will fix it for > hjl/interrupt/stage1 soon. > > hjl/interrupt/stage1 branch is also fixed. -- H.J.
Re: Compiling with -m64 using attribute interrupt emits IRET not IRETQ
On Thu, Jan 28, 2016 at 11:06 AM, Wink Saville wrote:
> Thanks. How are you testing?
>
>
* { dg-do compile } */
/* { dg-options "-O2 -Wall -g" } */
void
__attribute__((interrupt))
fn (void *frame)
{
}
/* { dg-final { scan-assembler-not "add(l|q)\[\\t \]*\\$\[0-9\]*,\[\\t
\]*%\[re\]?sp" } } */
/* { dg-final { scan-assembler "iret" { target ia32 } } } */
/* { dg-final { scan-assembler "iretq" { target { ! ia32 } } } } */
^^^
The testcase scans for iretq if target isn't 32-bit.
--
H.J.
Re: RFA: Add GCC Runtime Library Exception to include/plugin-api.h
On Tue, Feb 2, 2016 at 1:35 PM, Cary Coutant wrote:
>> include/plugin-api.h defines an ABI between linker and compiler,
>> which can be used to implement linker plug-in by any compilers.
>> I'd like to add GCC Runtime Library Exception to include/plugin-api.h
>> so that the linker plug-in can have non-GPL licenses.
>
> This is OK with me.
>
> -cary
Here is a patch. OK for trunk?
Thanks.
--
H.J.
From 3f8f62505774116d5de233ca36f60e3f8a840516 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Tue, 2 Feb 2016 14:02:03 -0800
Subject: [PATCH] Add GCC Runtime Library Exception to plugin-api.h
* COPYING.RUNTIME: New file.
* plugin-api.h: Add GCC Runtime Library Exception.
---
include/COPYING.RUNTIME | 73 +
include/plugin-api.h| 11 +++-
2 files changed, 83 insertions(+), 1 deletion(-)
create mode 100644 include/COPYING.RUNTIME
diff --git a/include/COPYING.RUNTIME b/include/COPYING.RUNTIME
new file mode 100644
index 000..e1b3c69
--- /dev/null
+++ b/include/COPYING.RUNTIME
@@ -0,0 +1,73 @@
+GCC RUNTIME LIBRARY EXCEPTION
+
+Version 3.1, 31 March 2009
+
+Copyright (C) 2009 Free Software Foundation, Inc. <http://fsf.org/>
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+This GCC Runtime Library Exception ("Exception") is an additional
+permission under section 7 of the GNU General Public License, version
+3 ("GPLv3"). It applies to a given file (the "Runtime Library") that
+bears a notice placed by the copyright holder of the file stating that
+the file is governed by GPLv3 along with this Exception.
+
+When you use GCC to compile a program, GCC may combine portions of
+certain GCC header files and runtime libraries with the compiled
+program. The purpose of this Exception is to allow compilation of
+non-GPL (including proprietary) programs to use, in this way, the
+header files and runtime libraries covered by this Exception.
+
+0. Definitions.
+
+A file is an "Independent Module" if it either requires the Runtime
+Library for execution after a Compilation Process, or makes use of an
+interface provided by the Runtime Library, but is not otherwise based
+on the Runtime Library.
+
+"GCC" means a version of the GNU Compiler Collection, with or without
+modifications, governed by version 3 (or a specified later version) of
+the GNU General Public License (GPL) with the option of using any
+subsequent versions published by the FSF.
+
+"GPL-compatible Software" is software whose conditions of propagation,
+modification and use would permit combination with GCC in accord with
+the license of GCC.
+
+"Target Code" refers to output from any compiler for a real or virtual
+target processor architecture, in executable form or suitable for
+input to an assembler, loader, linker and/or execution
+phase. Notwithstanding that, Target Code does not include data in any
+format that is used as a compiler intermediate representation, or used
+for producing a compiler intermediate representation.
+
+The "Compilation Process" transforms code entirely represented in
+non-intermediate languages designed for human-written code, and/or in
+Java Virtual Machine byte code, into Target Code. Thus, for example,
+use of source code generators and preprocessors need not be considered
+part of the Compilation Process, since the Compilation Process can be
+understood as starting with the output of the generators or
+preprocessors.
+
+A Compilation Process is "Eligible" if it is done using GCC, alone or
+with other GPL-compatible software, or if it is done without using any
+work based on GCC. For example, using non-GPL-compatible Software to
+optimize any GCC intermediate representations would not qualify as an
+Eligible Compilation Process.
+
+1. Grant of Additional Permission.
+
+You have permission to propagate a work of Target Code formed by
+combining the Runtime Library with Independent Modules, even if such
+propagation would otherwise violate the terms of GPLv3, provided that
+all Target Code was generated by Eligible Compilation Processes. You
+may then convey such a combination under terms of your choice,
+consistent with the licensing of the Independent Modules.
+
+2. No Weakening of GCC Copyleft.
+
+The availability of this Exception does not imply any general
+presumption that third-party software is unaffected by the copyleft
+requirements of the license of GCC.
+
diff --git a/include/plugin-api.h b/include/plugin-api.h
index d7f9ee3..46686be 100644
--- a/include/plugin-api.h
+++ b/include/plugin-api.h
@@ -18,7 +18,16 @@
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston,
- MA 02110-1301, USA.
Re: RFA: Add GCC Runtime Library Exception to include/plugin-api.h
On Tue, Feb 2, 2016 at 4:23 PM, David Edelsohn wrote: > On Tue, Feb 2, 2016 at 5:03 PM, H.J. Lu wrote: >> On Tue, Feb 2, 2016 at 1:35 PM, Cary Coutant wrote: >>>> include/plugin-api.h defines an ABI between linker and compiler, >>>> which can be used to implement linker plug-in by any compilers. >>>> I'd like to add GCC Runtime Library Exception to include/plugin-api.h >>>> so that the linker plug-in can have non-GPL licenses. >>> >>> This is OK with me. >>> >>> -cary >> >> Here is a patch. OK for trunk? > > You have not explained why this actually is needed and only the FSF > can agree to license changes. > Here is an example of linker plugin without using GCC: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/testplug.c;h=cec947c51c44e7e4334036ecfe96392eb7c32643;hb=HEAD I'd like to put such plugin under a non-GPL license. As I understand, Cary, as the contributor of include/plugin-api.h, may release it under a different license. Of course, changing license of include/plugin-api.h in GCC source tree may need FSF approval. Should we ask FSF to get an approval? -- H.J.
RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
Empty struct value is passed differently in C and C++ on Intel386 and x86-64. Different compilers use different calling conventions on the same platform: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 The same compiler behaves different on different platforms: https://llvm.org/bugs/show_bug.cgi?id=26337 In some case, empty struct can't be passed in C++ at all: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 I am proposing to update Intel386, x86-64 and IA MCU psABIs to specify how to pass/return empty struct: 1. "collection". A collection is a structure, union or C++ class. 2. "empty collection". An empty collection is: a. A collection without member. Or b. A collection with only empty collections. Or c. An array of empty collections. 3. "empty record". An empty record is Plain Old Data (POD) for the purpose of layout and a. A collection without member. Or b. A collection with only empty collections. 4. No memory slot nor register should be used to pass or return an object of empty collection. The proposed Intel386, x86-64 and IA MCU psABIs are at https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI Any comments? Thanks. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sun, Feb 7, 2016 at 11:31 AM, Florian Weimer wrote: > * H. J. Lu: > >> I am proposing to update Intel386, x86-64 and IA MCU psABIs to specify >> how to pass/return empty struct: >> >> 1. "collection". A collection is a structure, union or C++ class. >> 2. "empty collection". An empty collection is: >>a. A collection without member. Or >>b. A collection with only empty collections. Or >>c. An array of empty collections. >> 3. "empty record". An empty record is Plain Old Data (POD) for the purpose >>of layout and >>a. A collection without member. Or >>b. A collection with only empty collections. >> 4. No memory slot nor register should be used to pass or return an object of >> empty collection. > > “Aggregate” may be the more standard term instead of collection. Aggregate also include array, which is excluded here. > I think you mean “empty record” under 4. Yes. I will fix it. > Any syntactical array argument (at the C level) is should be passed as > a pointer. The language appears to change that. I didn't use aggregate so that array is excluded here. > For 2., static members and non-data members do not count. They do count here. That is why I used "POD for the purpose of layout. > Does the definition of POD vary between C++ standards? Then the > calling convention would vary as well, which is probably not what we > want. I believe that POD for the purpose of layout doesn't change between C++ standards. > How do existing C++ compilers implement empty array members (an > extension)? Does the type of such members affect whether a class is a > standard-layout class? > > Florian Are they "POD for the purpose of layout"? If yes, they are covered here. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sun, Feb 7, 2016 at 11:36 AM, H.J. Lu wrote: > On Sun, Feb 7, 2016 at 11:31 AM, Florian Weimer wrote: >> * H. J. Lu: >> >>> I am proposing to update Intel386, x86-64 and IA MCU psABIs to specify >>> how to pass/return empty struct: >>> >>> 1. "collection". A collection is a structure, union or C++ class. >>> 2. "empty collection". An empty collection is: >>>a. A collection without member. Or >>>b. A collection with only empty collections. Or >>>c. An array of empty collections. >>> 3. "empty record". An empty record is Plain Old Data (POD) for the purpose >>>of layout and >>>a. A collection without member. Or >>>b. A collection with only empty collections. >>> 4. No memory slot nor register should be used to pass or return an object of >>> empty collection. >> >> “Aggregate” may be the more standard term instead of collection. > > Aggregate also include array, which is excluded here. > >> I think you mean “empty record” under 4. > > Yes. I will fix it. This typo isn't in the proposed x86 psABIs: https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI which has "No memory slot nor register should be used to pass or return an object of empty record." H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sun, Feb 7, 2016 at 12:08 PM, Florian Weimer wrote:
> * H. J. Lu:
>
>>> Any syntactical array argument (at the C level) is should be passed as
>>> a pointer. The language appears to change that.
>>
>> I didn't use aggregate so that array is excluded here.
>>
>>> For 2., static members and non-data members do not count.
>>
>> They do count here. That is why I used "POD for the purpose of
>> layout.
>
> Let's see what happens today.
>
> struct s0 {
> s0();
> };
>
> struct s1 {
> static int a;
> };
>
> struct s2 {
> void member();
> };
>
> struct s3 {
> int a[0];
> };
>
> struct s4 {
> s0 a[0];
> };
>
> struct s5 {
> s1 a[1];
> };
>
>
> I tested GCC 5.3.1 and Clang 3.5.0.
>
> GCC Clang
> s0 non-emptynon-empty
> s1 non-emptyempty
> s2 non-emptyempty
> s3 emptyempty
> s4 emptyempty
> s5 non-emptyempty
>
> I believe s3, s4, s5 are non-empty according to your rules. Why put
> both compilers in the wrong? That doesn't make sense to me.
Please try testcases in
https://llvm.org/bugs/show_bug.cgi?id=26337
with clang on both ia32 and x86-64. Clang isn't consistent between
ia32 and x86-64.
> Jason already indicated he intends GCC to move towards more empty
> arguments, not fewer.
>
>>> How do existing C++ compilers implement empty array members (an
>>> extension)? Does the type of such members affect whether a class is a
>>> standard-layout class?
>
>> Are they "POD for the purpose of layout"? If yes, they are covered here.
>
> The C++ standard does not define this.
GCC has
* Nonzero means that this class type is not POD for the purpose of layout
(as defined in the ABI). This is different from the language's POD. */
#define CLASSTYPE_NON_LAYOUT_POD_P(NODE) \
We can use this definition for ia32, x86-64 and IA MCU psABIs.
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sun, Feb 7, 2016 at 12:48 PM, Florian Weimer wrote:
> * H. J. Lu:
>
>>> I tested GCC 5.3.1 and Clang 3.5.0.
>>>
>>> GCC Clang
>>> s0 non-emptynon-empty
>>> s1 non-emptyempty
>>> s2 non-emptyempty
>>> s3 emptyempty
>>> s4 emptyempty
>>> s5 non-emptyempty
>>>
>>> I believe s3, s4, s5 are non-empty according to your rules. Why put
>>> both compilers in the wrong? That doesn't make sense to me.
>>
>> Please try testcases in
>>
>> https://llvm.org/bugs/show_bug.cgi?id=26337
>>
>> with clang on both ia32 and x86-64. Clang isn't consistent between
>> ia32 and x86-64.
>
> Okay, with -m32, I get non-empty passing for s5 from Clang as well.
> But I still don't think it makes sense to change the ABI for s3 and
> s4, and even for s5, the Clang/x86_64 behavior is arguably more
> correct.
Not really. For
struct dummy0 { };
struct dummy { struct dummy0 d[PAD_SIZE]; };
clang changes behavior when PAD_SIZE > 16 on x86-64 and PAD_SIZE > 1
on ia32.
>>> Jason already indicated he intends GCC to move towards more empty
>>> arguments, not fewer.
>>>
>>>>> How do existing C++ compilers implement empty array members (an
>>>>> extension)? Does the type of such members affect whether a class is a
>>>>> standard-layout class?
>>>
>>>> Are they "POD for the purpose of layout"? If yes, they are covered here.
>>>
>>> The C++ standard does not define this.
>>
>> GCC has
>>
>> * Nonzero means that this class type is not POD for the purpose of layout
>>(as defined in the ABI). This is different from the language's POD. */
>> #define CLASSTYPE_NON_LAYOUT_POD_P(NODE) \
>>
>> We can use this definition for ia32, x86-64 and IA MCU psABIs.
>
> It still has to be spelled out in non-GCC terms, IMHO.
Sure. Do you care to propose a wording for "POD for the purpose of layout"?
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote:
> On Sun, Feb 7, 2016 at 12:48 PM, Florian Weimer wrote:
>> * H. J. Lu:
>>
>>>> I tested GCC 5.3.1 and Clang 3.5.0.
>>>>
>>>> GCC Clang
>>>> s0 non-emptynon-empty
>>>> s1 non-emptyempty
>>>> s2 non-emptyempty
>>>> s3 emptyempty
>>>> s4 emptyempty
>>>> s5 non-emptyempty
>>>>
>>>> I believe s3, s4, s5 are non-empty according to your rules. Why put
>>>> both compilers in the wrong? That doesn't make sense to me.
>>>
>>> Please try testcases in
>>>
>>> https://llvm.org/bugs/show_bug.cgi?id=26337
>>>
>>> with clang on both ia32 and x86-64. Clang isn't consistent between
>>> ia32 and x86-64.
>>
>> Okay, with -m32, I get non-empty passing for s5 from Clang as well.
>> But I still don't think it makes sense to change the ABI for s3 and
>> s4, and even for s5, the Clang/x86_64 behavior is arguably more
>> correct.
>
> Not really. For
>
> struct dummy0 { };
> struct dummy { struct dummy0 d[PAD_SIZE]; };
>
> clang changes behavior when PAD_SIZE > 16 on x86-64 and PAD_SIZE > 1
> on ia32.
>
>>>> Jason already indicated he intends GCC to move towards more empty
>>>> arguments, not fewer.
>>>>
>>>>>> How do existing C++ compilers implement empty array members (an
>>>>>> extension)? Does the type of such members affect whether a class is a
>>>>>> standard-layout class?
>>>>
>>>>> Are they "POD for the purpose of layout"? If yes, they are covered here.
>>>>
>>>> The C++ standard does not define this.
>>>
>>> GCC has
>>>
>>> * Nonzero means that this class type is not POD for the purpose of layout
>>>(as defined in the ABI). This is different from the language's POD. */
>>> #define CLASSTYPE_NON_LAYOUT_POD_P(NODE) \
>>>
>>> We can use this definition for ia32, x86-64 and IA MCU psABIs.
>>
>> It still has to be spelled out in non-GCC terms, IMHO.
>
> Sure. Do you care to propose a wording for "POD for the purpose of layout"?
>
The standard-layout POD is well defined:
https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data
Here is the updated proposal for Intel386, x86-64 and IA MCU psABIs:
1. "collection". A collection is a structure, union or C++ class.
2. "empty collection". An empty collection is:
a. A collection without member. Or
b. A collection with only empty collections. Or
c. An array of empty collections.
3. "empty record". An empty record is Plain Old Data (POD) for the purpose
of standard-layout and
a. A collection without member. Or
b. A collection with only empty collections.
4. No memory slot nor register should be used to pass or return an object of
empty record.
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely wrote: > On 8 February 2016 at 13:54, H.J. Lu wrote: >> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote: >> >> The standard-layout POD is well defined: >> >> https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data >> >> Here is the updated proposal for Intel386, x86-64 and IA MCU psABIs: >> >> 1. "collection". A collection is a structure, union or C++ class. > > These are all "class types". Why invent a new term? Because it applies to both C and C++. There is no class in C. >> 2. "empty collection". An empty collection is: >>a. A collection without member. Or > > What about base classes? > > What about bit-fields of length 0? Is a collection with them standard-layout POD type? >>b. A collection with only empty collections. Or > > What does "with" mean? Only members, or bases too? Is "A collection with only members of empty collections" better? >>c. An array of empty collections. >> 3. "empty record". An empty record is Plain Old Data (POD) for the purpose >>of standard-layout and > > "For the purposes of standard-layout" doesn't mean anything. > > A type is a standard-layout type, or it isn't. How about "An empty record is standard-layout Plain Old Data (POD) type and ..."? > Do you mean "An empty record is a standard-layout type and..." > >>a. A collection without member. Or >>b. A collection with only empty collections. > > ? > Is "A collection with only members of empty collections" better? > >> 4. No memory slot nor register should be used to pass or return an object of >> empty record. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely wrote:
> On 8 February 2016 at 15:42, H.J. Lu wrote:
>> On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely
>> wrote:
>>> On 8 February 2016 at 13:54, H.J. Lu wrote:
>>>> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote:
>>>>
>>>> The standard-layout POD is well defined:
>>>>
>>>> https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data
>>>>
>>>> Here is the updated proposal for Intel386, x86-64 and IA MCU psABIs:
>>>>
>>>> 1. "collection". A collection is a structure, union or C++ class.
>>>
>>> These are all "class types". Why invent a new term?
>>
>> Because it applies to both C and C++. There is no class in C.
>
> Then you could use the term "class type" in the ABI, defining it to
> mean structure or union in C, or class type in C++. No need for a new
> term.
I will do it.
>
>>>> 2. "empty collection". An empty collection is:
>>>>a. A collection without member. Or
>>>
>>> What about base classes?
>>>
>>> What about bit-fields of length 0?
>>
>> Is a collection with them standard-layout POD type?
>
> (I'm not sure what the "bit-fields of length 0" part is for, but my
> point is it would be useful to examine similar concepts in the
> standard and align with them, not just make up entirely new
> classifications.)
I am replying on C++ compiler to tell if it is standard-layout
or not.
> For base classes, yes. A standard-layout class can have base classes
> of standard-layout type.
>
> struct A { };
> struct B { };
> struct C : A, B { };
>
> C is a standard-layout type. Is it an empty collection?
My understanding is
A type that is standard-layout means that it orders and packs its
members in a way that is compatible with C.
What is the corresponding compatible type in C?
>>>>b. A collection with only empty collections. Or
>>>
>>> What does "with" mean? Only members, or bases too?
>>
>> Is "A collection with only members of empty collections" better?
>
> Should it mention base classes?
It depends on the answer of my question above.
>
>>>>c. An array of empty collections.
>>>> 3. "empty record". An empty record is Plain Old Data (POD) for the purpose
>>>>of standard-layout and
>>>
>>> "For the purposes of standard-layout" doesn't mean anything.
>>>
>>> A type is a standard-layout type, or it isn't.
>>
>> How about "An empty record is standard-layout Plain Old Data (POD)
>> type and ..."?
>
> That's redundant, all POD types are standard-layout types.
>
I will update it.
Thanks.
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 8:15 AM, Jonathan Wakely wrote:
> On 8 February 2016 at 16:05, H.J. Lu wrote:
>> My understanding is
>>
>> A type that is standard-layout means that it orders and packs its
>> members in a way that is compatible with C.
>>
>> What is the corresponding compatible type in C?
>
> An empty structure, such as struct A.
>
> One of the requirements for standard-layout classes is "has all
> non-static data members and bit-fields in the class and its base
> classes first declared in the same class" so standard layout classes
> are allowed to have base classes, as long as either the base class is
> empty (so doesn't alter layout) or the derived class doesn't add
> members (so has the same layout as the base). If neither the base
> class is an empty record, and the derived class doesn't add any
> non-static data members or bit-fields, then the base class should be
> an empty record too.
if it is the case
struct A { };
struct B { };
struct C : A, B { };
is an empty record.
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely wrote:
>>> A type is a standard-layout type, or it isn't.
>>
>> How about "An empty record is standard-layout Plain Old Data (POD)
>> type and ..."?
>
> That's redundant, all POD types are standard-layout types.
>
Apparently, not all standard-layout types are POD types. GCC has
/* Nonzero means that this class type is not POD for the purpose of layout
(as defined in the ABI). This is different from the language's POD. */
CLASSTYPE_NON_LAYOUT_POD_P
and
/* Nonzero means that this class type is a non-standard-layout class. */
#define CLASSTYPE_NON_STD_LAYOUT
They aren't the same.
struct A { };
struct B { };
struct C : A, B { };
C is a standard-layout type, but not a standard-layout POD type.
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely wrote:
> On 8 February 2016 at 18:26, Jonathan Wakely wrote:
>> On 8 February 2016 at 17:58, H.J. Lu wrote:
>>> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely
>>> wrote:
>>>>>> A type is a standard-layout type, or it isn't.
>>>>>
>>>>> How about "An empty record is standard-layout Plain Old Data (POD)
>>>>> type and ..."?
>>>>
>>>> That's redundant, all POD types are standard-layout types.
>>>>
>>>
>>> Apparently, not all standard-layout types are POD types. GCC has
>>>
>>> /* Nonzero means that this class type is not POD for the purpose of layout
>>>(as defined in the ABI). This is different from the language's POD. */
>>> CLASSTYPE_NON_LAYOUT_POD_P
>>>
>>> and
>>>
>>> /* Nonzero means that this class type is a non-standard-layout class. */
>>> #define CLASSTYPE_NON_STD_LAYOUT
>>>
>>> They aren't the same.
>>>
>>> struct A { };
>>> struct B { };
>>> struct C : A, B { };
>>>
>>> C is a standard-layout type, but not a standard-layout POD type.
>>
>> As the comment says, "POD for the purposes of layout" is different
>> from the language's POD. All standard-layout types are POD types
>> according to the language.
>>
>> So when you previously had "POD for the purposes of layout" that was
>> at least partially clear that you meant something other than what the
>> language means. But as pointed out, using a GCC-specific term is not
>> ideal.
>>
>> When you changed it to "POD for the purpose of standard-layout" that
>> became a completely meaningless term. Where is that defined?
>>
>> Your next suggestion was "standard-layout Plain Old Data (POD)" which
>> is even worse, now you're using two terms defined by the C++ language,
>> but you mean something different.
>>
>> When you mean something that is the same as the language (like "class
>> type") it makes sense to use the same term.
>>
>> When you mean something that is not the same as the language (like
>> "POD") it makes sense to use a different term, or clearly define how
>> you are using it.
>
> To be clear: it's really confusing to take two terms defined by the
> language, "POD" and "standard-layout", and smash them together to mean
> something new.
>
> According to your proposal, struct C is a POD type, and a
> standard-layout type, but not a "standard-layout POD type". That's
> just crazy.
Can you suggest a better wording?
Another issue, if I define
1. "class type". A class type is a structure, union or C++ class.
2. "empty class type". An empty class type is:
a. A class type without member. Or
b. A class type with only members of empty class types. Or
c. An array of empty class types.
^
Will it confuse people?
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 10:46 AM, Jonathan Wakely wrote:
> On 8 February 2016 at 18:31, H.J. Lu wrote:
>> On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely
>> wrote:
>>> On 8 February 2016 at 18:26, Jonathan Wakely wrote:
>>>> On 8 February 2016 at 17:58, H.J. Lu wrote:
>>>>> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely
>>>>> wrote:
>>>>>>>> A type is a standard-layout type, or it isn't.
>>>>>>>
>>>>>>> How about "An empty record is standard-layout Plain Old Data (POD)
>>>>>>> type and ..."?
>>>>>>
>>>>>> That's redundant, all POD types are standard-layout types.
>>>>>>
>>>>>
>>>>> Apparently, not all standard-layout types are POD types. GCC has
>>>>>
>>>>> /* Nonzero means that this class type is not POD for the purpose of layout
>>>>>(as defined in the ABI). This is different from the language's POD.
>>>>> */
>>>>> CLASSTYPE_NON_LAYOUT_POD_P
>>>>>
>>>>> and
>>>>>
>>>>> /* Nonzero means that this class type is a non-standard-layout class. */
>>>>> #define CLASSTYPE_NON_STD_LAYOUT
>>>>>
>>>>> They aren't the same.
>>>>>
>>>>> struct A { };
>>>>> struct B { };
>>>>> struct C : A, B { };
>>>>>
>>>>> C is a standard-layout type, but not a standard-layout POD type.
>>>>
>>>> As the comment says, "POD for the purposes of layout" is different
>>>> from the language's POD. All standard-layout types are POD types
>>>> according to the language.
>>>>
>>>> So when you previously had "POD for the purposes of layout" that was
>>>> at least partially clear that you meant something other than what the
>>>> language means. But as pointed out, using a GCC-specific term is not
>>>> ideal.
>>>>
>>>> When you changed it to "POD for the purpose of standard-layout" that
>>>> became a completely meaningless term. Where is that defined?
>>>>
>>>> Your next suggestion was "standard-layout Plain Old Data (POD)" which
>>>> is even worse, now you're using two terms defined by the C++ language,
>>>> but you mean something different.
>>>>
>>>> When you mean something that is the same as the language (like "class
>>>> type") it makes sense to use the same term.
>>>>
>>>> When you mean something that is not the same as the language (like
>>>> "POD") it makes sense to use a different term, or clearly define how
>>>> you are using it.
>>>
>>> To be clear: it's really confusing to take two terms defined by the
>>> language, "POD" and "standard-layout", and smash them together to mean
>>> something new.
>>>
>>> According to your proposal, struct C is a POD type, and a
>>> standard-layout type, but not a "standard-layout POD type". That's
>>> just crazy.
>>
>> Can you suggest a better wording?
>
> I don't know what the definition of "POD for the purposes of layout"
> is, but if I was trying to define a better name for it I would start
> by trying to understand how it is specified, instead of just throwing
> existing terms together.
>
>
>> Another issue, if I define
>>
>> 1. "class type". A class type is a structure, union or C++ class.
>> 2. "empty class type". An empty class type is:
>>a. A class type without member. Or
>>b. A class type with only members of empty class types. Or
>>c. An array of empty class types.
>> ^
>>
>> Will it confuse people?
>
> Yes :-)
>
> But that was already confusing when you called it an "empty
> collection" because an array isn't a collection.
>
> If I understand correctly, your proposal says that given:
>
> struct A { }; // empty class type
> typedef A A2[2]; // array of empty class types
>
> struct B { A a[2]; }; // empty record?
>
> struct B is an empty record ... is that right?
Yes, struct B is an empty record. And also in
struct A { };
struct B { };
struct C : A, B { };
C isn't an empty record.
--
H.J.
Linux-abi group
Hi, I created a mailing list to discuss Linux specific,.processor independent modification and extension of generic System V Application Binary Interface: https://groups.google.com/d/forum/linux-abi I will start to document existing Linux extensions, like STT_GNU_IFUNC. I will propose some new extensions soon. -- H.J.
Re: Linux-abi group
On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer wrote: > * H. J. Lu: > >> I created a mailing list to discuss Linux specific,.processor independent >> modification and extension of generic System V Application Binary Interface: >> >> https://groups.google.com/d/forum/linux-abi >> >> I will start to document existing Linux extensions, like STT_GNU_IFUNC. >> I will propose some new extensions soon. > > Why can't you use the existing C++ ABI list? Is there no overlap at > all? > : I wasn't referring to empty class https://gcc.gnu.org/ml/gcc/2016-02/msg00057.html I was referring to program properties: https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8 -- H.J.
Re: Linux-abi group
On Mon, Feb 8, 2016 at 11:33 AM, Szabolcs Nagy wrote: > * H.J. Lu [2016-02-08 11:24:53 -0800]: >> I created a mailing list to discuss Linux specific,.processor independent >> modification and extension of generic System V Application Binary Interface: >> >> https://groups.google.com/d/forum/linux-abi >> >> I will start to document existing Linux extensions, like STT_GNU_IFUNC. >> I will propose some new extensions soon. >> > > seems to require a registered email address at google. > (and the archive does not work from any console based browser > or using direct http get tools.) Do you want me to add you? > the kernel seems to have a lot of mailing lists, may be > they can handle this list too? > > thanks It is used to discuss more tool-oriented extensions than the kernel-oriented ones, like STT_GNU_IFUNC which has nothing to do with kernel. -- H.J.
Re: Linux-abi group
On Mon, Feb 8, 2016 at 11:44 AM, Florian Weimer wrote: > * H. J. Lu: > >> On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer wrote: >>> * H. J. Lu: >>> >>>> I created a mailing list to discuss Linux specific,.processor independent >>>> modification and extension of generic System V Application Binary >>>> Interface: >>>> >>>> https://groups.google.com/d/forum/linux-abi >>>> >>>> I will start to document existing Linux extensions, like STT_GNU_IFUNC. >>>> I will propose some new extensions soon. >>> >>> Why can't you use the existing C++ ABI list? Is there no overlap at >>> all? >>> >> : >> I wasn't referring to empty class >> >> https://gcc.gnu.org/ml/gcc/2016-02/msg00057.html > > But still there is going to be some overlap? I was told that it didn't belong to C++ ABI. Please free feel to raise the this issue with C++ ABI group. >> I was referring to program properties: >> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8 > > This looks more like an ELF topic to me, not really ABI. > > Please discuss this on a GNU project list because it affects the > entire GNU project. > gABI is ELF and affects all users, including GNU project, of gABI. Linux-abi discusses Linux-specific extensions to gABI. It is for tools like compilers, assembler, linker and run-time. It isn't appropriate for any GNU project list. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely wrote: > On 8 February 2016 at 19:23, Richard Smith wrote: >> "POD for the purpose of layout" is defined in the Itanium C++ ABI here: >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions > > Thanks. So there's no problem using "POD for the purposes of layout", > and the change to "POD for the purpose of standard-layout" was > unnecessary and just confused things. Here is the revised proposal: 1. "class type". A class type is a structure, union or C++ class. 2. "empty class type". An empty class type is: a. A class type without member. Or b. A class type with only members of empty class types. Or c. An array of empty class types. 3. "empty record". An empty record is Plain Old Data (POD) for the purposes of layout and a. A class type without member. Or b. A class type with only members of empty class types. 4. No memory slot nor register should be used to pass or return an object of empty record. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >> wrote: >> > On 8 February 2016 at 19:23, Richard Smith wrote: >> >> "POD for the purpose of layout" is defined in the Itanium C++ ABI here: >> >> >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions >> > >> > Thanks. So there's no problem using "POD for the purposes of layout", >> > and the change to "POD for the purpose of standard-layout" was >> > unnecessary and just confused things. >> >> Here is the revised proposal: >> >> 1. "class type". A class type is a structure, union or C++ class. >> 2. "empty class type". An empty class type is: >>a. A class type without member. Or >>b. A class type with only members of empty class types. Or > > > (a) is a special case of (b). > >>c. An array of empty class types. > > > It seems confusing to call an array a class type. Instead, how about: > > 2. An empty type is either an array of empty types or a class type where > every member is of empty type. > >> 3. "empty record". An empty record is Plain Old Data (POD) for the >>purposes of layout and >>a. A class type without member. Or >>b. A class type with only members of empty class types. > > > (a) is a special case of (b). > >> 4. No memory slot nor register should be used to pass or return an object >> of empty record. > > > Objects of array type are never passed or returned (but if through some > language extension they were, we'd want this rule to apply). So you don't > need rule 3 and this can be just: > > 3. No memory slot nor register should be used to pass or return an object > of empty type. Thanks very much for your inputs. Here is the proposal: 1. "class type". A class type is a structure, union or C++ class. 2. "empty type". An empty type is either an array of empty types or a class type where every member is of empty type. 3. No memory slot nor register should be used to pass or return an object of empty type. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: >> >> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith wrote: >> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >> >> >> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >> >> wrote: >> >> > On 8 February 2016 at 19:23, Richard Smith wrote: >> >> >> "POD for the purpose of layout" is defined in the Itanium C++ ABI here: >> >> >> >> >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions >> >> > >> >> > Thanks. So there's no problem using "POD for the purposes of layout", >> >> > and the change to "POD for the purpose of standard-layout" was >> >> > unnecessary and just confused things. >> >> >> >> Here is the revised proposal: >> >> >> >> 1. "class type". A class type is a structure, union or C++ class. >> >> 2. "empty class type". An empty class type is: >> >>a. A class type without member. Or >> >>b. A class type with only members of empty class types. Or >> > >> > >> > (a) is a special case of (b). >> > >> >>c. An array of empty class types. >> > >> > >> > It seems confusing to call an array a class type. Instead, how about: >> > >> > 2. An empty type is either an array of empty types or a class type where >> > every member is of empty type. >> > >> >> 3. "empty record". An empty record is Plain Old Data (POD) for the >> >>purposes of layout and >> >>a. A class type without member. Or >> >>b. A class type with only members of empty class types. >> > >> > >> > (a) is a special case of (b). >> > >> >> 4. No memory slot nor register should be used to pass or return an object >> >> of empty record. >> > >> > >> > Objects of array type are never passed or returned (but if through some >> > language extension they were, we'd want this rule to apply). So you don't >> > need rule 3 and this can be just: >> > >> > 3. No memory slot nor register should be used to pass or return an object >> > of empty type. >> >> Thanks very much for your inputs. Here is the proposal: >> >> 1. "class type". A class type is a structure, union or C++ class. >> 2. "empty type". An empty type is either an array of empty types or a >> class type where every member is of empty type. >> 3. No memory slot nor register should be used to pass or return an object >> of empty type. > > David Majnemer points out that we also need to say something about > base classes. We could handle that case like this: > > 2. "empty type". An empty type is a type where it and all of its > subobjects are of class or array type. > > Following the C++ rules, this also means that a class that contains > only unnamed bitfields is empty, because unnamed bitfields are not > subobjects, but might be worth explicitly stating for the C case. That > also matches Clang's behavior. Like this? 1. "class type". A class type is a structure, union or C++ class. 2. "empty type". An empty type is a. A type where it and all of its subobjects are of class or array type. And b. Either an array of empty types or a class type where every member is of empty type. 3. No memory slot nor register should be used to pass or return an object of empty type. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:42 PM, Richard Smith wrote: > Do we really need an 'empty type' special case? > > The x86_64 psABI already seems clear that empty types with size <= 16 > are not passed at all. Following the algorithm in section 3.2.3, each > eightbyte is classified as NO_CLASS, and thus is not passed. So the > proposed change would only affect the behavior of types larger than 16 > bytes that contain no data. It doesn't seem worth breaking ABI to more > efficiently pass those. > Clang isn't consistent between ia32 and x86-64. GCC isn't compatible with clang. My proposal will make GCC and clang compatible. It also makes GCC and clang behave the same on both ia32 and x86-64. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote: >> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote: >>> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: >>>> >>>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith >>>> wrote: >>>> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >>>> >> >>>> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >>>> >> wrote: >>>> >> > On 8 February 2016 at 19:23, Richard Smith wrote: >>>> >> >> "POD for the purpose of layout" is defined in the Itanium C++ ABI >>>> >> >> here: >>>> >> >> >>>> >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions >>>> >> > >>>> >> > Thanks. So there's no problem using "POD for the purposes of layout", >>>> >> > and the change to "POD for the purpose of standard-layout" was >>>> >> > unnecessary and just confused things. >>>> >> >>>> >> Here is the revised proposal: >>>> >> >>>> >> 1. "class type". A class type is a structure, union or C++ class. >>>> >> 2. "empty class type". An empty class type is: >>>> >>a. A class type without member. Or >>>> >>b. A class type with only members of empty class types. Or >>>> > >>>> > >>>> > (a) is a special case of (b). >>>> > >>>> >>c. An array of empty class types. >>>> > >>>> > >>>> > It seems confusing to call an array a class type. Instead, how about: >>>> > >>>> > 2. An empty type is either an array of empty types or a class type >>>> > where >>>> > every member is of empty type. >>>> > >>>> >> 3. "empty record". An empty record is Plain Old Data (POD) for the >>>> >>purposes of layout and >>>> >>a. A class type without member. Or >>>> >>b. A class type with only members of empty class types. >>>> > >>>> > >>>> > (a) is a special case of (b). >>>> > >>>> >> 4. No memory slot nor register should be used to pass or return an >>>> >> object >>>> >> of empty record. >>>> > >>>> > >>>> > Objects of array type are never passed or returned (but if through some >>>> > language extension they were, we'd want this rule to apply). So you don't >>>> > need rule 3 and this can be just: >>>> > >>>> > 3. No memory slot nor register should be used to pass or return an >>>> > object >>>> > of empty type. >>>> >>>> Thanks very much for your inputs. Here is the proposal: >>>> >>>> 1. "class type". A class type is a structure, union or C++ class. >>>> 2. "empty type". An empty type is either an array of empty types or a >>>> class type where every member is of empty type. >>>> 3. No memory slot nor register should be used to pass or return an object >>>> of empty type. >>> >>> David Majnemer points out that we also need to say something about >>> base classes. We could handle that case like this: >>> >>> 2. "empty type". An empty type is a type where it and all of its >>> subobjects are of class or array type. >>> >>> Following the C++ rules, this also means that a class that contains >>> only unnamed bitfields is empty, because unnamed bitfields are not >>> subobjects, but might be worth explicitly stating for the C case. That >>> also matches Clang's behavior. >> >> Like this? >> >> 1. "class type". A class type is a structure, union or C++ class. >> 2. "empty type". An empty type is >>a. A type where it and all of its subobjects are of class or array >>type. And >>b. Either an array of empty types or a class type where every member >>is of empty type. > > You don't need (b). It's implied by (a). Does (a) cover empty type? >> 3. No memory slot nor register should be used to pass or return an object >> of empty type. >> >> >> -- >> H.J. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:58 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote: >> On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith wrote: >>> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote: >>>> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith >>>> wrote: >>>>> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: >>>>>> >>>>>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith >>>>>> wrote: >>>>>> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >>>>>> >> >>>>>> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >>>>>> >> >>>>>> >> wrote: >>>>>> >> > On 8 February 2016 at 19:23, Richard Smith wrote: >>>>>> >> >> "POD for the purpose of layout" is defined in the Itanium C++ ABI >>>>>> >> >> here: >>>>>> >> >> >>>>>> >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions >>>>>> >> > >>>>>> >> > Thanks. So there's no problem using "POD for the purposes of >>>>>> >> > layout", >>>>>> >> > and the change to "POD for the purpose of standard-layout" was >>>>>> >> > unnecessary and just confused things. >>>>>> >> >>>>>> >> Here is the revised proposal: >>>>>> >> >>>>>> >> 1. "class type". A class type is a structure, union or C++ class. >>>>>> >> 2. "empty class type". An empty class type is: >>>>>> >>a. A class type without member. Or >>>>>> >>b. A class type with only members of empty class types. Or >>>>>> > >>>>>> > >>>>>> > (a) is a special case of (b). >>>>>> > >>>>>> >>c. An array of empty class types. >>>>>> > >>>>>> > >>>>>> > It seems confusing to call an array a class type. Instead, how about: >>>>>> > >>>>>> > 2. An empty type is either an array of empty types or a class type >>>>>> > where >>>>>> > every member is of empty type. >>>>>> > >>>>>> >> 3. "empty record". An empty record is Plain Old Data (POD) for the >>>>>> >>purposes of layout and >>>>>> >>a. A class type without member. Or >>>>>> >>b. A class type with only members of empty class types. >>>>>> > >>>>>> > >>>>>> > (a) is a special case of (b). >>>>>> > >>>>>> >> 4. No memory slot nor register should be used to pass or return an >>>>>> >> object >>>>>> >> of empty record. >>>>>> > >>>>>> > >>>>>> > Objects of array type are never passed or returned (but if through some >>>>>> > language extension they were, we'd want this rule to apply). So you >>>>>> > don't >>>>>> > need rule 3 and this can be just: >>>>>> > >>>>>> > 3. No memory slot nor register should be used to pass or return an >>>>>> > object >>>>>> > of empty type. >>>>>> >>>>>> Thanks very much for your inputs. Here is the proposal: >>>>>> >>>>>> 1. "class type". A class type is a structure, union or C++ class. >>>>>> 2. "empty type". An empty type is either an array of empty types or a >>>>>> class type where every member is of empty type. >>>>>> 3. No memory slot nor register should be used to pass or return an object >>>>>> of empty type. >>>>> >>>>> David Majnemer points out that we also need to say something about >>>>> base classes. We could handle that case like this: >>>>> >>>>> 2. "empty type". An empty type is a type where it and all of its >>>>> subobjects are of class or array type. >>>>> >>>>> Following the C++ rules, this also means that a class that contains >>>>> only unnamed bitfields is empty, because unnamed bitfields are not >>>>> subobjects, but might be worth explicitly stating for the C case. That >>>>> also matches Clang's behavior. >>>> >>>> Like this? >>>> >>>> 1. "class type". A class type is a structure, union or C++ class. >>>> 2. "empty type". An empty type is >>>>a. A type where it and all of its subobjects are of class or array >>>>type. And >>>>b. Either an array of empty types or a class type where every member >>>>is of empty type. >>> >>> You don't need (b). It's implied by (a). >> >> Does (a) cover empty type? > > Yes, (a) is a complete definition of "empty type" by itself: the > definition is, essentially, that a complete recursive walk of the type > and all its subobjects never sees anything that would require any > storage (that is, it only sees class types and array types). Is there a definition of subobject? -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:55 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 2:49 PM, H.J. Lu wrote: >> On Mon, Feb 8, 2016 at 2:42 PM, Richard Smith wrote: >>> Do we really need an 'empty type' special case? >>> >>> The x86_64 psABI already seems clear that empty types with size <= 16 >>> are not passed at all. Following the algorithm in section 3.2.3, each >>> eightbyte is classified as NO_CLASS, and thus is not passed. So the >>> proposed change would only affect the behavior of types larger than 16 >>> bytes that contain no data. It doesn't seem worth breaking ABI to more >>> efficiently pass those. >>> >> >> Clang isn't consistent between ia32 and x86-64. GCC isn't compatible >> with clang. My proposal will make GCC and clang compatible. It also >> makes GCC and clang behave the same on both ia32 and x86-64. > > OK, but if the ABI is already saying what we want, and the only > problem is that GCC and Clang don't conform to the ABI in some cases, > then we just need to fix the compilers and not the ABI. Which cases do > we think the existing ABI rule misclassifies? I want to make it explicit in psABIs to avoid any possible confusion and x86-64 classification rules don't apply to ia32. -- H.J.
Re: Linux-abi group
On Mon, Feb 8, 2016 at 3:08 PM, Joseph Myers wrote: > On Mon, 8 Feb 2016, H.J. Lu wrote: > >> >> I was referring to program properties: >> >> >> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8 >> > >> > This looks more like an ELF topic to me, not really ABI. >> > >> > Please discuss this on a GNU project list because it affects the >> > entire GNU project. >> > >> >> gABI is ELF and affects all users, including GNU project, of gABI. >> Linux-abi discusses Linux-specific extensions to gABI. It is for tools >> like compilers, assembler, linker and run-time. It isn't appropriate >> for any GNU project list. > > I find it extremely unlikely that many well-thought-out extensions would > be appropriate for GNU systems using the Linux kernel but not for GNU > systems using Hurd or other kernels - the only such cases would be for > things very closely related to kernel functionality. There is a strong > presumption that toolchain configuration should apply to all GNU systems > rather than being specific to GNU/Linux without good reason. > Most of extensions aren't Linux kernel specific. But some extensions will require kernel support to function properly. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 3:28 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 3:01 PM, H.J. Lu wrote: >> On Mon, Feb 8, 2016 at 2:58 PM, Richard Smith wrote: >>> On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote: >>>> On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith >>>> wrote: >>>>> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote: >>>>>> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith >>>>>> wrote: >>>>>>> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: >>>>>>>> >>>>>>>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith >>>>>>>> wrote: >>>>>>>> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >>>>>>>> >> >>>>>>>> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >>>>>>>> >> >>>>>>>> >> wrote: >>>>>>>> >> > On 8 February 2016 at 19:23, Richard Smith wrote: >>>>>>>> >> >> "POD for the purpose of layout" is defined in the Itanium C++ >>>>>>>> >> >> ABI here: >>>>>>>> >> >> >>>>>>>> >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions >>>>>>>> >> > >>>>>>>> >> > Thanks. So there's no problem using "POD for the purposes of >>>>>>>> >> > layout", >>>>>>>> >> > and the change to "POD for the purpose of standard-layout" was >>>>>>>> >> > unnecessary and just confused things. >>>>>>>> >> >>>>>>>> >> Here is the revised proposal: >>>>>>>> >> >>>>>>>> >> 1. "class type". A class type is a structure, union or C++ class. >>>>>>>> >> 2. "empty class type". An empty class type is: >>>>>>>> >>a. A class type without member. Or >>>>>>>> >>b. A class type with only members of empty class types. Or >>>>>>>> > >>>>>>>> > >>>>>>>> > (a) is a special case of (b). >>>>>>>> > >>>>>>>> >>c. An array of empty class types. >>>>>>>> > >>>>>>>> > >>>>>>>> > It seems confusing to call an array a class type. Instead, how about: >>>>>>>> > >>>>>>>> > 2. An empty type is either an array of empty types or a class type >>>>>>>> > where >>>>>>>> > every member is of empty type. >>>>>>>> > >>>>>>>> >> 3. "empty record". An empty record is Plain Old Data (POD) for the >>>>>>>> >>purposes of layout and >>>>>>>> >>a. A class type without member. Or >>>>>>>> >>b. A class type with only members of empty class types. >>>>>>>> > >>>>>>>> > >>>>>>>> > (a) is a special case of (b). >>>>>>>> > >>>>>>>> >> 4. No memory slot nor register should be used to pass or return an >>>>>>>> >> object >>>>>>>> >> of empty record. >>>>>>>> > >>>>>>>> > >>>>>>>> > Objects of array type are never passed or returned (but if through >>>>>>>> > some >>>>>>>> > language extension they were, we'd want this rule to apply). So you >>>>>>>> > don't >>>>>>>> > need rule 3 and this can be just: >>>>>>>> > >>>>>>>> > 3. No memory slot nor register should be used to pass or return an >>>>>>>> > object >>>>>>>> > of empty type. >>>>>>>> >>>>>>>> Thanks very much for your inputs. Here is the proposal: >>>>>>>> >>>>>>>> 1. "class type". A class type is a structure, union or C++ class. >>>>>>>> 2. &quo
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Tue, Feb 9, 2016 at 6:45 AM, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 3:28 PM, Richard Smith wrote: >> On Mon, Feb 8, 2016 at 3:01 PM, H.J. Lu wrote: >>> On Mon, Feb 8, 2016 at 2:58 PM, Richard Smith wrote: >>>> On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote: >>>>> On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith >>>>> wrote: >>>>>> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote: >>>>>>> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith >>>>>>> wrote: >>>>>>>> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: >>>>>>>>> >>>>>>>>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith >>>>>>>>> wrote: >>>>>>>>> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu >>>>>>>>> > wrote: >>>>>>>>> >> >>>>>>>>> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >>>>>>>>> >> >>>>>>>>> >> wrote: >>>>>>>>> >> > On 8 February 2016 at 19:23, Richard Smith wrote: >>>>>>>>> >> >> "POD for the purpose of layout" is defined in the Itanium C++ >>>>>>>>> >> >> ABI here: >>>>>>>>> >> >> >>>>>>>>> >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions >>>>>>>>> >> > >>>>>>>>> >> > Thanks. So there's no problem using "POD for the purposes of >>>>>>>>> >> > layout", >>>>>>>>> >> > and the change to "POD for the purpose of standard-layout" was >>>>>>>>> >> > unnecessary and just confused things. >>>>>>>>> >> >>>>>>>>> >> Here is the revised proposal: >>>>>>>>> >> >>>>>>>>> >> 1. "class type". A class type is a structure, union or C++ class. >>>>>>>>> >> 2. "empty class type". An empty class type is: >>>>>>>>> >>a. A class type without member. Or >>>>>>>>> >>b. A class type with only members of empty class types. Or >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > (a) is a special case of (b). >>>>>>>>> > >>>>>>>>> >>c. An array of empty class types. >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > It seems confusing to call an array a class type. Instead, how >>>>>>>>> > about: >>>>>>>>> > >>>>>>>>> > 2. An empty type is either an array of empty types or a class >>>>>>>>> > type where >>>>>>>>> > every member is of empty type. >>>>>>>>> > >>>>>>>>> >> 3. "empty record". An empty record is Plain Old Data (POD) for the >>>>>>>>> >>purposes of layout and >>>>>>>>> >>a. A class type without member. Or >>>>>>>>> >>b. A class type with only members of empty class types. >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > (a) is a special case of (b). >>>>>>>>> > >>>>>>>>> >> 4. No memory slot nor register should be used to pass or return an >>>>>>>>> >> object >>>>>>>>> >> of empty record. >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Objects of array type are never passed or returned (but if through >>>>>>>>> > some >>>>>>>>> > language extension they were, we'd want this rule to apply). So you >>>>>>>>> > don't >>>>>>>>> > need rule 3 and this can be just: >>>>>>>>> > >>>>>>>>> > 3. No memory slot nor register should be used to pass or return
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Thu, Feb 11, 2016 at 2:47 AM, Matthijs van Duin
wrote:
> On 8 February 2016 at 22:40, H.J. Lu wrote:
>> "empty type". An empty type is either an array of empty types or a
>> class type where every member is of empty type.
>
> Note that the term "empty type" is commonly used in type theory to
> denote a (or the) type with no values. The closest thing C has would be
> an empty enum when using -fstrict-enums. (Declaring it as return type
> implies [[noreturn]] or undefined behaviour.)
>
> A type with a unique value (such as void or an empty struct) is usually
> known as a unit type.
>
> BTW, being standard layout is not sufficient (nor required afaict) for
> zero-register passing of a unit type. The requirement you need is
> trivially-copyable. Example:
>
> #include
> #include
> #include
>
> using namespace std;
>
> class EmptyInt {
> static map< const EmptyInt *, int > values;
>
> public:
> EmptyInt() = default;
> EmptyInt( int x ) { values[this] = x; }
> ~EmptyInt() { values.erase(this); }
>
> operator int () const { return values[this]; }
> };
>
> typeof( EmptyInt::values ) EmptyInt::values;
>
> EmptyInt foo() {
> return 42;
> }
>
> int main() {
> cout << is_standard_layout{} << endl;
> cout << foo() << endl;
> return 0;
> }
My current proposal is
1. "class type". A class type is a structure, union or C++ class.
2. "empty type". An empty type is Plain Old Data (POD) for the
purposes of layout, and.a type where it and all of its subobjects
are of class or array type.
> This evil contraption satisfies all POD-requirements except for not
> being trivially-copyable. On the other hand taking this example from
> http://en.cppreference.com/w/cpp/concept/StandardLayoutType
>
> struct Q {};
> struct S : Q {};
> struct T : Q {};
> struct U : S, T {}; // not a standard-layout class
>
> Even though U is not standard-layout, it is trivially-copyable and I see
> no reason to allocate a register to pass it.
>
Since this isn't Plain Old Data (POD) for the purposes of layout, it
isn't covered by my proposal for psABI. I leave this to C++ ABI.
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Thu, Feb 11, 2016 at 4:40 AM, Matthijs van Duin wrote: > On 11 February 2016 at 11:53, H.J. Lu wrote: >> Since this isn't Plain Old Data (POD) for the purposes of layout, it >> isn't covered by my proposal for psABI. I leave this to C++ ABI. > > You never define "POD for the purposes of layout", and I can only > interpret it as being equivalent to "standard-layout". The property of > being trivially copyable/destructible is not a statement about layout > and my EmptyInt example is POD in every other aspect. "POD for the purpose of layout" is defined in the Itanium C++ ABI here: http://mentorembedded.github.io/cxx-abi/abi.html#definitions -- H.J.
Re: Linux-abi group
On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde wrote: > H.J, > > I think we are fragmenting with too many standards and mailing lists. This > new discussion group and eventually the resulting standards, all might be > put under LSB http://refspecs.linuxfoundation.org/lsb.shtml > > The Intro on LSB says: > http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html > > And thats what this proposal is intended for. > > And we can use the LSB mailing list > https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all > discussions. > > What do you think? > LSB lists extensions which have been implemented. But it isn't a spec you can use to implement them. For example: http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/progheader.html lists PT_GNU_EH_FRAME, PT_GNU_STACK and PT_GNU_RELRO. But it gives no details. Linux ABI group is the place where we propose extensions before they get implemented. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Thu, Feb 11, 2016 at 5:44 AM, Matthijs van Duin wrote: > On 11 February 2016 at 13:58, H.J. Lu wrote: >> "POD for the purpose of layout" is defined in the Itanium C++ ABI here: >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions > > Sorry, I overlooked that. > > I still stand by my viewpoint however that triviality of copying and > destruction is the appropriate criterion here rather than this obscure > constraint on layout. My focus is interoperability between C and C++: https://llvm.org/bugs/show_bug.cgi?id=26337 I intentionally exclude C++ specific features in my propose. However you have a very valid point. I encourage you to raise it with C++ ABI group: http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Thu, Feb 11, 2016 at 6:18 AM, Matthijs van Duin wrote: > On 11 February 2016 at 15:00, H.J. Lu wrote: >> I intentionally exclude C++ specific features in my propose. > > Yet you use a definition from the Itanium C++ ABI which itself depends > on multiple definitions in a particular version of the C++ standard, > which depend on C++ specific features. Yes, I used this C++ ABI definition to make C++ and C equivalent in empty type definition. > This makes no sense to me. > > Note that triviality of copying/destruction holds for all C types and > is easy to formulate in languages other than C++. (As is the notion of Can you point out which C++ features for empty type with C counter parts aren't covered by "POD for the purpose of layout"? > an aggregate requiring no storage, other than padding. The whole > argument about array parameters seems a bit silly since this is mere > syntax sugar, C/C++ do not support passing an actual array by value.) > > Matthijs van Duin -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Thu, Feb 11, 2016 at 6:30 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 11 Feb 2016, Jonathan Wakely wrote:
>
>> On 11 February 2016 at 12:40, Matthijs van Duin wrote:
>> > You never define "POD for the purposes of layout", and I can only
>> > interpret it as being equivalent to "standard-layout".
>>
>> As Richard pointed out, it's defined in the C++ ABI.
>
> Which is C++y as well (and hence doesn't in itself solve the C/C++
> compatibility we should strive for in the ABI). I'll concur with Matthijs
> and think that trivially copyable is the correct distinction for passing
> without registers (in addition of it being clearer than a strangly defined
> concept of "POD-but-not-quite-POD"). Do you think different? Are there
> non-trivially copyable examples that we'd wish to pass without registers
> as well?
>
>
Any suggestions on new wording, something like
1. "class type". A class type is a structure, union or C++ class.
2. "empty type". An empty type is a type where it and all of its
subobjects are of class or array type.
Does it cover
struct A { };
struct B { };
struct C : A, B { };
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Thu, Feb 11, 2016 at 6:54 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 11 Feb 2016, H.J. Lu wrote:
>
>> Any suggestions on new wording, something like
>>
>> 1. "class type". A class type is a structure, union or C++ class.
>> 2. "empty type". An empty type is a type where it and all of its
>> subobjects are of class or array type.
>>
>> Does it cover
>>
>> struct A { };
>> struct B { };
>> struct C : A, B { };
>
> I think this is covered by the above points. But without further
> restriction I don't see how e.g. the above example with ctors and dtors
> would be ruled out (except if you regard a ctor as a sub-object). For
> that you seem to need trivially-copyable, or that POD-ly thing. So,
> perhaps simply amend (2) "... is a trivially copyable type where it ...".
>
>
> Ciao,
> Michael.
How about
struct A {
static void foo (void) ();
static int xxx;
};
--
H.J.
Re: Linux-abi group
On Thu, Feb 11, 2016 at 8:05 AM, Suprateeka R Hegde wrote: > On 11-Feb-2016 07:21 PM, H.J. Lu wrote: >> >> On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde >> wrote: >>> >>> H.J, >>> >>> I think we are fragmenting with too many standards and mailing lists. >>> This >>> new discussion group and eventually the resulting standards, all might be >>> put under LSB http://refspecs.linuxfoundation.org/lsb.shtml >>> >>> The Intro on LSB says: >>> >>> http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html >>> >>> And thats what this proposal is intended for. >>> >>> And we can use the LSB mailing list >>> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all >>> discussions. >>> >>> What do you think? >>> >> >> LSB lists extensions which have been implemented. But it isn't a spec >> you can use to implement them. For example: >> >> >> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/progheader.html >> >> lists PT_GNU_EH_FRAME, PT_GNU_STACK and PT_GNU_RELRO. >> But it gives no details. Linux ABI group is the place where we propose >> extensions before they get implemented. > > > How to implement, according to me, is design details of a particular > product. It also depends on the language used to develop the product. > Standards, in most cases, are not tied to a language and hence do not > enforce implementation details. > > That is exactly what Linux ABI group tries to address. Please see the Linux gABI extension draft at https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI It describes the conventions and constraints on the implementa- tion of these extensions for interoperability between various tools. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
wrote:
> On 11 February 2016 at 16:31, H.J. Lu wrote:
>> struct A {
>> static void foo (void) ();
>> static int xxx;
>> };
>
> What about it? It's an empty struct. (And it declares a function and
> a variable in the namespace of A, which however do not have any
> relevant impact here.)
>
Thanks for all the feedbacks. Here is the new proposal:
1. "empty type". An empty type is a trivially-copyable aggregate
occupying zero bytes (excluding any padding).
2. No memory slot nor register should be used to pass or return an object
of empty type.
Footnote: Array of empty type can only passed by reference in C/C++.
--
H.J.
Re: gnu-gabi group
On Mon, Feb 15, 2016 at 7:37 AM, Alexandre Oliva wrote: > On Feb 12, 2016, Pedro Alves wrote: > > >>> wonderful. I am not a big fan of google groups mailinglists, they seem >>> to make it hard to subscribe and don't have easy to access archives. >>> Having a local gnu-gabi group on sourceware.org would be better IMHO. > >> +1 > > +1 > > Since it's GNU tools we're talking about, we'd better use a medium that > we've all already agreed to use, than one that a number of us objects > to. I, for one, have closed my Google account several Valentine's Days > ago, for privacy reasons, and this makes the archives of lists hidden > there unusable for me. Please don't spread false information. Anyone can subscribe Linux-ABI group and its archive is to open to everyone. You don't need a gmail account for any of those. There are quite a few non-gmail users. You don't have to take my word for it. I can add your email to Linux-ABI group and you can check it out yourself :-). -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
> On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
> wrote:
>> On 11 February 2016 at 16:31, H.J. Lu wrote:
>>> struct A {
>>> static void foo (void) ();
>>> static int xxx;
>>> };
>>
>> What about it? It's an empty struct. (And it declares a function and
>> a variable in the namespace of A, which however do not have any
>> relevant impact here.)
>>
>
> Thanks for all the feedbacks. Here is the new proposal:
>
> 1. "empty type". An empty type is a trivially-copyable aggregate
> occupying zero bytes (excluding any padding).
> 2. No memory slot nor register should be used to pass or return an object
> of empty type.
>
> Footnote: Array of empty type can only passed by reference in C/C++.
>
I updated intel386, x86-64 and IA MCU psABIs:
https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
to specify:
Empty type is defined as a trivially-copyable aggregate occupying zero bytes
(excluding any padding). No memory slot nor register should be used to pass or
return an object object of empty type.
with footnote: Array of empty type can only passed by reference in C and C++.
Any comments?
Thanks.
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith wrote:
> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>>
>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>> > wrote:
>> >> On 11 February 2016 at 16:31, H.J. Lu wrote:
>> >>> struct A {
>> >>> static void foo (void) ();
>> >>> static int xxx;
>> >>> };
>> >>
>> >> What about it? It's an empty struct. (And it declares a function and
>> >> a variable in the namespace of A, which however do not have any
>> >> relevant impact here.)
>> >>
>> >
>> > Thanks for all the feedbacks. Here is the new proposal:
>> >
>> > 1. "empty type". An empty type is a trivially-copyable aggregate
>> > occupying zero bytes (excluding any padding).
>> > 2. No memory slot nor register should be used to pass or return an object
>> > of empty type.
>> >
>> > Footnote: Array of empty type can only passed by reference in C/C++.
>> >
>>
>> I updated intel386, x86-64 and IA MCU psABIs:
>>
>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>
>> to specify:
>>
>> Empty type is defined as a trivially-copyable aggregate occupying zero bytes
>> (excluding any padding).
>
> I think this is now extremely unclear. Does an empty struct in C++
> occupy zero bytes? sizeof applied to it will produce at least 1.
Can it be considered as padding?
>> No memory slot nor register should be used to pass or
>> return an object object of empty type.
>>
>> with footnote: Array of empty type can only passed by reference in C and C++.
>>
>> Any comments?
>>
>> Thanks.
>>
>>
>> --
>> H.J.
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith wrote:
> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith
>> wrote:
>>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>>>>
>>>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
>>>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>>>> > wrote:
>>>> >> On 11 February 2016 at 16:31, H.J. Lu wrote:
>>>> >>> struct A {
>>>> >>> static void foo (void) ();
>>>> >>> static int xxx;
>>>> >>> };
>>>> >>
>>>> >> What about it? It's an empty struct. (And it declares a function and
>>>> >> a variable in the namespace of A, which however do not have any
>>>> >> relevant impact here.)
>>>> >>
>>>> >
>>>> > Thanks for all the feedbacks. Here is the new proposal:
>>>> >
>>>> > 1. "empty type". An empty type is a trivially-copyable aggregate
>>>> > occupying zero bytes (excluding any padding).
>>>> > 2. No memory slot nor register should be used to pass or return an object
>>>> > of empty type.
>>>> >
>>>> > Footnote: Array of empty type can only passed by reference in C/C++.
>>>> >
>>>>
>>>> I updated intel386, x86-64 and IA MCU psABIs:
>>>>
>>>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>>>
>>>> to specify:
>>>>
>>>> Empty type is defined as a trivially-copyable aggregate occupying zero
>>>> bytes
>>>> (excluding any padding).
>>>
>>> I think this is now extremely unclear. Does an empty struct in C++
>>> occupy zero bytes? sizeof applied to it will produce at least 1.
>>
>> Can it be considered as padding?
>
> Perhaps, but I would contend that that's unclear in at least some
> cases (when the class is used as the type of a member, ...). What
> about this case:
>
> struct X { unsigned : 15; };
>
> Is that empty or not? Do we have a formal definition somewhere of what
> does, and does not, count as padding?
How about this?
Empty type is defined as a trivially-copyable aggregate occupying zero bytes
(excluding any padding or contributing zero bytes to the size of derived
classes in C++).
This will cover
struct dummy0
{
void bar (void);
};
struct dummy1
{
void foo (void);
};
struct dummy : dummy0, dummy1 { };
But not
struct dummy0
{
};
struct dummy1
{
unsigned : 15;
};
struct dummy : dummy0, dummy1
{
};
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith wrote:
> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu wrote:
>> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith wrote:
>>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
>>>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith
>>>> wrote:
>>>>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>>>>>>
>>>>>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
>>>>>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>>>>>> > wrote:
>>>>>> >> On 11 February 2016 at 16:31, H.J. Lu wrote:
>>>>>> >>> struct A {
>>>>>> >>> static void foo (void) ();
>>>>>> >>> static int xxx;
>>>>>> >>> };
>>>>>> >>
>>>>>> >> What about it? It's an empty struct. (And it declares a function and
>>>>>> >> a variable in the namespace of A, which however do not have any
>>>>>> >> relevant impact here.)
>>>>>> >>
>>>>>> >
>>>>>> > Thanks for all the feedbacks. Here is the new proposal:
>>>>>> >
>>>>>> > 1. "empty type". An empty type is a trivially-copyable aggregate
>>>>>> > occupying zero bytes (excluding any padding).
>>>>>> > 2. No memory slot nor register should be used to pass or return an
>>>>>> > object
>>>>>> > of empty type.
>>>>>> >
>>>>>> > Footnote: Array of empty type can only passed by reference in C/C++.
>>>>>> >
>>>>>>
>>>>>> I updated intel386, x86-64 and IA MCU psABIs:
>>>>>>
>>>>>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>>>>>
>>>>>> to specify:
>>>>>>
>>>>>> Empty type is defined as a trivially-copyable aggregate occupying zero
>>>>>> bytes
>>>>>> (excluding any padding).
>>>>>
>>>>> I think this is now extremely unclear. Does an empty struct in C++
>>>>> occupy zero bytes? sizeof applied to it will produce at least 1.
>>>>
>>>> Can it be considered as padding?
>>>
>>> Perhaps, but I would contend that that's unclear in at least some
>>> cases (when the class is used as the type of a member, ...). What
>>> about this case:
>>>
>>> struct X { unsigned : 15; };
>>>
>>> Is that empty or not? Do we have a formal definition somewhere of what
>>> does, and does not, count as padding?
>>
>> How about this?
>>
>> Empty type is defined as a trivially-copyable aggregate occupying zero bytes
>> (excluding any padding or contributing zero bytes to the size of derived
>> classes in C++).
>>
>> This will cover
>>
>> struct dummy0
>> {
>> void bar (void);
>> };
>> struct dummy1
>> {
>> void foo (void);
>> };
>> struct dummy : dummy0, dummy1 { };
>>
>> But not
>>
>> struct dummy0
>> {
>> };
>> struct dummy1
>> {
>> unsigned : 15;
>> };
>> struct dummy : dummy0, dummy1
>> {
>> };
>
> Why not? That looks empty to me. The ABI will classify the
> corresponding eightbyte as NO_CLASS, as it has no members, so it
> should not be passed.
Do you have a wording to describe it?
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Tue, Feb 16, 2016 at 1:45 PM, Richard Smith wrote:
> On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu wrote:
>> On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith wrote:
>>> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu wrote:
>>>> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith
>>>> wrote:
>>>>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
>>>>>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith
>>>>>> wrote:
>>>>>>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>>>>>>>>
>>>>>>>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
>>>>>>>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>>>>>>>> > wrote:
>>>>>>>> >> On 11 February 2016 at 16:31, H.J. Lu wrote:
>>>>>>>> >>> struct A {
>>>>>>>> >>> static void foo (void) ();
>>>>>>>> >>> static int xxx;
>>>>>>>> >>> };
>>>>>>>> >>
>>>>>>>> >> What about it? It's an empty struct. (And it declares a function
>>>>>>>> >> and
>>>>>>>> >> a variable in the namespace of A, which however do not have any
>>>>>>>> >> relevant impact here.)
>>>>>>>> >>
>>>>>>>> >
>>>>>>>> > Thanks for all the feedbacks. Here is the new proposal:
>>>>>>>> >
>>>>>>>> > 1. "empty type". An empty type is a trivially-copyable aggregate
>>>>>>>> > occupying zero bytes (excluding any padding).
>>>>>>>> > 2. No memory slot nor register should be used to pass or return an
>>>>>>>> > object
>>>>>>>> > of empty type.
>>>>>>>> >
>>>>>>>> > Footnote: Array of empty type can only passed by reference in C/C++.
>>>>>>>> >
>>>>>>>>
>>>>>>>> I updated intel386, x86-64 and IA MCU psABIs:
>>>>>>>>
>>>>>>>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>>>>>>>
>>>>>>>> to specify:
>>>>>>>>
>>>>>>>> Empty type is defined as a trivially-copyable aggregate occupying zero
>>>>>>>> bytes
>>>>>>>> (excluding any padding).
>>>>>>>
>>>>>>> I think this is now extremely unclear. Does an empty struct in C++
>>>>>>> occupy zero bytes? sizeof applied to it will produce at least 1.
>>>>>>
>>>>>> Can it be considered as padding?
>>>>>
>>>>> Perhaps, but I would contend that that's unclear in at least some
>>>>> cases (when the class is used as the type of a member, ...). What
>>>>> about this case:
>>>>>
>>>>> struct X { unsigned : 15; };
>>>>>
>>>>> Is that empty or not? Do we have a formal definition somewhere of what
>>>>> does, and does not, count as padding?
>>>>
>>>> How about this?
>>>>
>>>> Empty type is defined as a trivially-copyable aggregate occupying zero
>>>> bytes
>>>> (excluding any padding or contributing zero bytes to the size of derived
>>>> classes in C++).
>>>>
>>>> This will cover
>>>>
>>>> struct dummy0
>>>> {
>>>> void bar (void);
>>>> };
>>>> struct dummy1
>>>> {
>>>> void foo (void);
>>>> };
>>>> struct dummy : dummy0, dummy1 { };
>>>>
>>>> But not
>>>>
>>>> struct dummy0
>>>> {
>>>> };
>>>> struct dummy1
>>>> {
>>>> unsigned : 15;
>>>> };
>>>> struct dummy : dummy0, dummy1
>>>> {
>>>> };
>>>
>>> Why not? That looks empty to me. The ABI will classify the
>>> corresponding eightbyte as NO_CLASS, as it has no members, so it
>>> should not be passed.
>>
>> Do you have a wording to describe it?
>
> Yes, something like what you had before was fine:
>
> "empty type". An empty type is a type where it and all of its
> subobjects (recursively) are of class, structure, union, or array
> type.
>
> Or, if you think it makes the intent clearer, reverse the sense:
>
> A type is non-empty if it or any subobject (recursively) is of any
> type other than class, structure, union, or array type.
Does the above cover
struct dummy0
{
void bar (void);
};
struct dummy1
{
void foo (void);
};
struct dummy : dummy0, dummy1 { };
> If you like, you could add notes that a parameter type is never an
> array type, and that unnamed bit-fields are not subobjects, but they
> seem redundant given the wording of the relevant standards. (You don't
> need to say anything about "POD for the purpose of layout", or
> destructors, or whatever else, because the C++ ABI only delegates to
> the C psABI for cases that are valid to pass in registers from a C++
> language semantics point of view.)
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Tue, Feb 16, 2016 at 3:36 PM, Richard Smith wrote:
> On Tue, Feb 16, 2016 at 1:48 PM, H.J. Lu wrote:
>> On Tue, Feb 16, 2016 at 1:45 PM, Richard Smith wrote:
>>> On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu wrote:
>>>> On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith
>>>> wrote:
>>>>> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu wrote:
>>>>>> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith
>>>>>> wrote:
>>>>>>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
>>>>>>>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith
>>>>>>>> wrote:
>>>>>>>>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>>>>>>>>>>
>>>>>>>>>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu
>>>>>>>>>> wrote:
>>>>>>>>>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>>>>>>>>>> > wrote:
>>>>>>>>>> >> On 11 February 2016 at 16:31, H.J. Lu wrote:
>>>>>>>>>> >>> struct A {
>>>>>>>>>> >>> static void foo (void) ();
>>>>>>>>>> >>> static int xxx;
>>>>>>>>>> >>> };
>>>>>>>>>> >>
>>>>>>>>>> >> What about it? It's an empty struct. (And it declares a function
>>>>>>>>>> >> and
>>>>>>>>>> >> a variable in the namespace of A, which however do not have any
>>>>>>>>>> >> relevant impact here.)
>>>>>>>>>> >>
>>>>>>>>>> >
>>>>>>>>>> > Thanks for all the feedbacks. Here is the new proposal:
>>>>>>>>>> >
>>>>>>>>>> > 1. "empty type". An empty type is a trivially-copyable aggregate
>>>>>>>>>> > occupying zero bytes (excluding any padding).
>>>>>>>>>> > 2. No memory slot nor register should be used to pass or return an
>>>>>>>>>> > object
>>>>>>>>>> > of empty type.
>>>>>>>>>> >
>>>>>>>>>> > Footnote: Array of empty type can only passed by reference in
>>>>>>>>>> > C/C++.
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>> I updated intel386, x86-64 and IA MCU psABIs:
>>>>>>>>>>
>>>>>>>>>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>>>>>>>>>
>>>>>>>>>> to specify:
>>>>>>>>>>
>>>>>>>>>> Empty type is defined as a trivially-copyable aggregate occupying
>>>>>>>>>> zero bytes
>>>>>>>>>> (excluding any padding).
>>>>>>>>>
>>>>>>>>> I think this is now extremely unclear. Does an empty struct in C++
>>>>>>>>> occupy zero bytes? sizeof applied to it will produce at least 1.
>>>>>>>>
>>>>>>>> Can it be considered as padding?
>>>>>>>
>>>>>>> Perhaps, but I would contend that that's unclear in at least some
>>>>>>> cases (when the class is used as the type of a member, ...). What
>>>>>>> about this case:
>>>>>>>
>>>>>>> struct X { unsigned : 15; };
>>>>>>>
>>>>>>> Is that empty or not? Do we have a formal definition somewhere of what
>>>>>>> does, and does not, count as padding?
>>>>>>
>>>>>> How about this?
>>>>>>
>>>>>> Empty type is defined as a trivially-copyable aggregate occupying zero
>>>>>> bytes
>>>>>> (excluding any padding or contributing zero bytes to the size of derived
>>>>>> classes in C++).
>>>>>>
>>>>>> This will cover
>>>>>>
>>>>>> struct dummy0
>>>>>> {
>>>>>> void bar (void);
>>>>>> };
>>>>>> struct dummy1
>>>>>> {
>>>>>> void foo (void);
>>>>>> };
>>>>>> struct dummy : dummy0, dummy1 { };
>>>>>>
>>>>>> But not
>>>>>>
>>>>>> struct dummy0
>>>>>> {
>>>>>> };
>>>>>> struct dummy1
>>>>>> {
>>>>>> unsigned : 15;
>>>>>> };
>>>>>> struct dummy : dummy0, dummy1
>>>>>> {
>>>>>> };
>>>>>
>>>>> Why not? That looks empty to me. The ABI will classify the
>>>>> corresponding eightbyte as NO_CLASS, as it has no members, so it
>>>>> should not be passed.
>>>>
>>>> Do you have a wording to describe it?
>>>
>>> Yes, something like what you had before was fine:
>>>
>>> "empty type". An empty type is a type where it and all of its
>>> subobjects (recursively) are of class, structure, union, or array
>>> type.
>>>
>>> Or, if you think it makes the intent clearer, reverse the sense:
>>>
>>> A type is non-empty if it or any subobject (recursively) is of any
>>> type other than class, structure, union, or array type.
>>
>> Does the above cover
>>
>> struct dummy0
>> {
>> void bar (void);
>> };
>> struct dummy1
>> {
>> void foo (void);
>> };
>> struct dummy : dummy0, dummy1 { };
>
> Yes
>
Here is the new definition:
An empty type is a type where it and all of its subobjects (recursively)
are of class, structure, union, or array type. No memory slot nor register
should be used to pass or return an object of empty type.
Footnote: Array of empty type can only passed by reference in C and C++.
--
H.J.
