Re: Using the asm suffix
On Mon, Aug 17, 2015 at 09:55:48PM -0700, David Wohlferd wrote:
> >> On systems where an underscore is normally prepended to the name of a C
> >>-function or variable, this feature allows you to define names for the
> >>+variable, this feature allows you to define names for the
> >> linker that do not start with an underscore.
> >Why remove this?
>
> This doc section (Controlling Names Used in Assembler Code) describes
> how the asm suffix affects both data and functions. However, it jumbles
> the two descriptions together.
Probably because they are the same thing...
> My intent here is to break this clearly into two @subsubheadings:
> 'Assembler names for data' and 'Assembler names for functions'. Since
> data is the first section, I removed the word 'function' here.
I missed that, sorry. Or, did you forget to add the same text to the
"function" description?
This patch would be much easier to review if you did one change per patch.
> >> It does not make sense to use this feature with a non-static local
> >> variable since such variables do not have assembler names. If you are
> >> trying to put the variable in a particular register, see @ref{Explicit
> >>-Reg Vars}. GCC presently accepts such code with a warning, but will
> >>-probably be changed to issue an error, rather than a warning, in the
> >>-future.
> >>+Reg Vars}.
> >And this?
>
> Vague statements about possible changes that may or not ever be written
> are not helpful in docs. In this case the statement is particularly
> unhelpful since even the warning appears to be gone.
I don't agree it is a vague statement about possible future changes; it
is more like a statement of intent. It tells the reader "don't write
code like this".
And the warning is still there ("ignoring asm-specifier for non-static
local variable").
> >>-Also, you must not use a
> >>-register name; that would produce completely invalid assembler code. GCC
> >>-does not as yet have the ability to store static variables in registers.
> >>-Perhaps that will be added.
> >And why remove these?
>
> Again with the vague statements about possible future changes. Also,
> whether or not static variables can be stored in registers has nothing
> to do with Asm Labels. If this is still true, it belongs in Explicit
> Reg Vars.
The first part ("must not use a register name") is an important warning.
The second part (about statics) might well be better moved, but it should
not be _re_moved just like that! And it is still true (gives an error,
"multiple storage classes").
Segher
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
On 31/07/15 12:04, Alex Velenko wrote: On 29/07/15 23:14, Jeff Law wrote: On 07/28/2015 12:18 PM, Alex Velenko wrote: On 21/04/15 06:27, Jeff Law wrote: On 04/20/2015 01:09 AM, Shiva Chen wrote: Hi, Jeff Thanks for your advice. can_replace_by.patch is the new patch to handle both cases. pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump after patch can_replace_by.patch Could you help me to review the patch? Thanks. This looks pretty good. I expanded the comment for the new function a bit and renamed the function in an effort to clarify its purpose. From reviewing can_replace_by, it seems it should have been handling this case, but clearly wasn't due to implementation details. I then bootstrapped and regression tested the patch on x86_64-linux-gnu where it passed. I also instrumented that compiler to see how often this code triggers. During a bootstrap it triggers a couple hundred times (which is obviously a proxy for cross jumping improvements). So it's triggering regularly on x86_64, which is good. I also verified that this fixes BZ64916 for an arm-non-eabi toolchain configured with --with-arch=armv7. Installed on the trunk. No new testcase as it's covered by existing tests. Thanks,, jeff Hi, I see this patch been committed in r56 on trunk. Is it okay to port this to fsf-5? It's not a regression, so backporting it would be generally frowned upon. If you feel strongly about it, you should ask Jakub, Joseph or Richi (the release managers) for an exception to the general policy. jeff Hi Jakub, Can this commit be ported to fsf-5? It fixed gcc.target/arm/pr43920-2.c at the time, so I think it is a good idea to port. Please, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 Kind regards, Alex Ping! Currently this test is passed on fsf-trunk, but not passed on fsf-5, so I think it is a regression on fsf-5: arm-none-eabi fsf-5: PASS: gcc.target/arm/pr43920-2.c (test for excess errors) FAIL: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2 PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3 Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300) spawn arm-none-eabi-size pr43920-2.o text databssdechexfilename 58 0 0 58 3apr43920-2.o text size is 58 FAIL: gcc.target/arm/pr43920-2.c object-size text <= 54 arm-none-eabi fsf-trunk: PASS: gcc.target/arm/pr43920-2.c (test for excess errors) PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2 PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3 size is arm-none-eabi-size Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300) spawn arm-none-eabi-size pr43920-2.o text databssdechexfilename 54 0 0 54 36pr43920-2.o text size is 54 PASS: gcc.target/arm/pr43920-2.c object-size text <= 54 Can this, please, be ported? Kind regards, Alex
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
On 18 August 2015 at 10:25, Alex Velenko wrote: > > > On 31/07/15 12:04, Alex Velenko wrote: >> >> On 29/07/15 23:14, Jeff Law wrote: >>> >>> On 07/28/2015 12:18 PM, Alex Velenko wrote: On 21/04/15 06:27, Jeff Law wrote: > > On 04/20/2015 01:09 AM, Shiva Chen wrote: >> >> Hi, Jeff >> >> Thanks for your advice. >> >> can_replace_by.patch is the new patch to handle both cases. >> >> pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump >> >> pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump >> after patch can_replace_by.patch >> >> Could you help me to review the patch? > > Thanks. This looks pretty good. > > I expanded the comment for the new function a bit and renamed the > function in an effort to clarify its purpose. From reviewing > can_replace_by, it seems it should have been handling this case, but > clearly wasn't due to implementation details. > > I then bootstrapped and regression tested the patch on x86_64-linux-gnu > where it passed. I also instrumented that compiler to see how often > this code triggers. During a bootstrap it triggers a couple hundred > times (which is obviously a proxy for cross jumping improvements). So > it's triggering regularly on x86_64, which is good. > > I also verified that this fixes BZ64916 for an arm-non-eabi toolchain > configured with --with-arch=armv7. > > Installed on the trunk. No new testcase as it's covered by existing > tests. > > Thanks,, > jeff > Hi, I see this patch been committed in r56 on trunk. Is it okay to port this to fsf-5? >>> >>> It's not a regression, so backporting it would be generally frowned >>> upon. If you feel strongly about it, you should ask Jakub, Joseph or >>> Richi (the release managers) for an exception to the general policy. >>> >>> jeff >>> >> Hi Jakub, >> Can this commit be ported to fsf-5? It fixed gcc.target/arm/pr43920-2.c >> at the time, so I think it is a good idea to port. Please, see >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 >> Kind regards, >> Alex > > > Ping! > > Currently this test is passed on fsf-trunk, but not passed on fsf-5, so I > think it is a regression on fsf-5: That does not make it a regression, it is only a regression if a version prior to 5 passes, how does this test behave on 4.9? Cheers /Marcus
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
On 18/08/15 10:45, Marcus Shawcroft wrote: On 18 August 2015 at 10:25, Alex Velenko wrote: On 31/07/15 12:04, Alex Velenko wrote: On 29/07/15 23:14, Jeff Law wrote: On 07/28/2015 12:18 PM, Alex Velenko wrote: On 21/04/15 06:27, Jeff Law wrote: On 04/20/2015 01:09 AM, Shiva Chen wrote: Hi, Jeff Thanks for your advice. can_replace_by.patch is the new patch to handle both cases. pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump after patch can_replace_by.patch Could you help me to review the patch? Thanks. This looks pretty good. I expanded the comment for the new function a bit and renamed the function in an effort to clarify its purpose. From reviewing can_replace_by, it seems it should have been handling this case, but clearly wasn't due to implementation details. I then bootstrapped and regression tested the patch on x86_64-linux-gnu where it passed. I also instrumented that compiler to see how often this code triggers. During a bootstrap it triggers a couple hundred times (which is obviously a proxy for cross jumping improvements). So it's triggering regularly on x86_64, which is good. I also verified that this fixes BZ64916 for an arm-non-eabi toolchain configured with --with-arch=armv7. Installed on the trunk. No new testcase as it's covered by existing tests. Thanks,, jeff Hi, I see this patch been committed in r56 on trunk. Is it okay to port this to fsf-5? It's not a regression, so backporting it would be generally frowned upon. If you feel strongly about it, you should ask Jakub, Joseph or Richi (the release managers) for an exception to the general policy. jeff Hi Jakub, Can this commit be ported to fsf-5? It fixed gcc.target/arm/pr43920-2.c at the time, so I think it is a good idea to port. Please, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 Kind regards, Alex Ping! Currently this test is passed on fsf-trunk, but not passed on fsf-5, so I think it is a regression on fsf-5: That does not make it a regression, it is only a regression if a version prior to 5 passes, how does this test behave on 4.9? Cheers /Marcus Hi Marcus, On fsf-4.9 I see the test pass: PASS: gcc.target/arm/pr43920-2.c (test for excess errors) PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2 PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3 Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300) spawn arm-none-eabi-size pr43920-2.o textdata bss dec hex filename 54 0 0 54 36 pr43920-2.o text size is 54 PASS: gcc.target/arm/pr43920-2.c object-size text <= 54 So this is a regression in fsf-5. Kind regards, Alex
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
> On fsf-4.9 I see the test pass: > > PASS: gcc.target/arm/pr43920-2.c (test for excess errors) > PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2 > PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3 > Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300) > spawn arm-none-eabi-size pr43920-2.o >text databssdechexfilename > 54 0 0 54 36pr43920-2.o > text size is 54 > PASS: gcc.target/arm/pr43920-2.c object-size text <= 54 > > So this is a regression in fsf-5. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916#c3 regards Ramana > > Kind regards, > Alex >
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
> Hi Marcus, > > On fsf-4.9 I see the test pass: > > PASS: gcc.target/arm/pr43920-2.c (test for excess errors) > PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2 > PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3 > Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300) > spawn arm-none-eabi-size pr43920-2.o >text databssdechexfilename > 54 0 0 54 36pr43920-2.o > text size is 54 > PASS: gcc.target/arm/pr43920-2.c object-size text <= 54 > > So this is a regression in fsf-5. Sorry about the terse email earlier - don't know what thunderbird did with me and I was running off on an urgent private errand. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916#c3 suggests that this test case worked by fluke in earlier versions of the compiler, and the debate has been whether this is a regression or not. If in case it is not deemed to be a regression based on that comment, we should just XFAIL the test and move on. Given Jakub's away I'm CCing richi on this discussion. regards Ramana > > Kind regards, > Alex >
Re: Adding static-PIE support to binutils
On Mon, Aug 17, 2015 at 10:29:41PM -0700, Cary Coutant wrote: > > 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. > > For the uses you have in mind, -static and -pie together make perfect > sense, but I'd argue that the output file in that case ought to be > ET_EXEC, since it will be in fact a standalone binary to be loaded > directly by the kernel. Not only would you want to omit the .interp > section (actually the PT_INTERP segment), but you also have no need > for the PT_DYNAMIC segment (.dynamic section). As far as I can tell, on the kernel side ET_EXEC implies MAP_FIXED. Use of ET_EXEC vs ET_DYN is a separate matter from whether or not PT_DYNAMIC exists. Non-PIE dynamic-linked main executables with type ET_EXEC have PT_DYNAMIC, for example. > The only thing you need over a standard ET_EXEC file is the dynamic > relocations, with linker-generated symbols bracketing the start and > end of the relocations so that your custom startup code can find them. > It should be reasonably easy to arrange for these. Yes but it's much easier to use _DYNAMIC, and this is also more compatible with existing tools. I suspect gdb would have trouble if _DYNAMIC were missing, though I haven't checked. There's also the matter of arch-specific mess in _DYNAMIC (e.g. the wacky MIPS 'compacted' relocation table for the GOT) that would be a lot of arch-specific work to reimplement with an alternate scheme. bFLT already played the game of "let's redo relocation information in an ad-hoc way instead of using existing ELF mechanisms" and it was an utter mess; I don't want to go down that road again. Rich
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 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? Rich
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.
Deprecate SH5/SH64
Hi all, Kaz and I have been discussing the SH5/SH64 status, which is part of the SH port, every now and then. To our knowledge, there is no real hardware available as of today and we don't think there are any real users for a SH5/SH64 toolchain out there. Moreover, the SH5/SH64 parts of the SH port haven't been touched by anybody for a long time. The only exception is occasional ad-hoc fixes for bug reports from people who build GCC for every architecture that is listed in the Linux kernel. However, we don't actually know whether code compiled for SH5/SH64 still runs at an acceptable level since nobody has been doing any testing for that architecture for a while now. If there are no objections, we would like to deprecate SH5/SH64 support as of GCC 6. Initially this would include an announcement on the changes page and the removal of any documentation related to SH5/SH64. After GCC 6 we might start removing configure options and the respective code paths in the target. Cheers, Oleg
Re: Deprecate SH5/SH64
On Tue, Aug 18, 2015 at 1:00 PM, Oleg Endo wrote: > Hi all, > > Kaz and I have been discussing the SH5/SH64 status, which is part of the SH > port, every now and then. To our knowledge, there is no real hardware > available as of today and we don't think there are any real users for a > SH5/SH64 toolchain out there. Moreover, the SH5/SH64 parts of the SH port > haven't been touched by anybody for a long time. The only exception is > occasional ad-hoc fixes for bug reports from people who build GCC for every > architecture that is listed in the Linux kernel. However, we don't actually > know whether code compiled for SH5/SH64 still runs at an acceptable level > since nobody has been doing any testing for that architecture for a while now. > > If there are no objections, we would like to deprecate SH5/SH64 support as of > GCC 6. > > Initially this would include an announcement on the changes page and the > removal of any documentation related to SH5/SH64. After GCC 6 we might start > removing configure options and the respective code paths in the target. +1 - David
Re: Deprecate SH5/SH64
On 08/18/2015 11:11 AM, David Edelsohn wrote: On Tue, Aug 18, 2015 at 1:00 PM, Oleg Endo wrote: Hi all, Kaz and I have been discussing the SH5/SH64 status, which is part of the SH port, every now and then. To our knowledge, there is no real hardware available as of today and we don't think there are any real users for a SH5/SH64 toolchain out there. Moreover, the SH5/SH64 parts of the SH port haven't been touched by anybody for a long time. The only exception is occasional ad-hoc fixes for bug reports from people who build GCC for every architecture that is listed in the Linux kernel. However, we don't actually know whether code compiled for SH5/SH64 still runs at an acceptable level since nobody has been doing any testing for that architecture for a while now. If there are no objections, we would like to deprecate SH5/SH64 support as of GCC 6. Initially this would include an announcement on the changes page and the removal of any documentation related to SH5/SH64. After GCC 6 we might start removing configure options and the respective code paths in the target. +1 Works for me based on what I've heard independently about sh5 hardware situation. Frankly, I think we should be more aggressive about this kind of port/variant pruning across the board. Jeff
gcc-5-20150818 is now available
Snapshot gcc-5-20150818 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150818/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 226995 You'll find: gcc-5-20150818.tar.bz2 Complete GCC MD5=ab15a2e336b5a58fb7431a4a2f6df8f0 SHA1=6b4a644f87acc4f74b7510f43e81a7f31bd96c63 Diffs from 5-20150811 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Adding static-PIE support to binutils
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?
Rich
diff --git a/bfd/elf32-arm.c b/bfd/elf32-arm.c
index bd4b576..41803c2 100644
--- a/bfd/elf32-arm.c
+++ b/bfd/elf32-arm.c
@@ -13786,7 +13786,7 @@ elf32_arm_size_dynamic_sections (bfd * output_bfd
ATTRIBUTE_UNUSED,
if (elf_hash_table (info)->dynamic_sections_created)
{
/* Set the contents of the .interp section to the interpreter. */
- if (bfd_link_executable (info))
+ if (bfd_link_executable (info) && !info->nointerp)
{
s = bfd_get_linker_section (dynobj, ".interp");
BFD_ASSERT (s != NULL);
diff --git a/bfd/elf32-bfin.c b/bfd/elf32-bfin.c
index 49ef360..8346d57 100644
--- a/bfd/elf32-bfin.c
+++ b/bfd/elf3
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: ctype_members.cc Comparison Always True
On 08/03/2015 12:35 PM, Joel Sherrill wrote: Hi Just noticed this building the head for arm-rtems4.11. Should the first comparison be eliminated and, maybe, a comment added? ctype_members.cc:216:14: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] if (__wc >= 0 && __wc < 128 && _M_narrow_ok) ^ ctype_members.cc: In member function 'virtual const wchar_t* std::ctype::do_narrow(const wchar_t*, const wchar_t*, char, char*) const': ctype_members.cc:230:14: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] if (*__lo >= 0 && *__lo < 128) Unconditionally removing the test alone wouldn't be right for targets where wchar_t is a signed type. But casting the result to an unsigned type with as much precision as wchar_t should make it possible to remove it safely. Martin
Re: Adding static-PIE support to binutils
On Tue, Aug 18, 2015 at 08:58:43PM -0400, Rich Felker wrote: > 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. This is OK to commit with a suitable ChangeLog. I think a separate ld option is best too, because historically -static and its aliases -Bstatic, -dn, -non_shared really are about what type of libraries are accepted rather than choosing linker output type. -- Alan Modra Australia Development Lab, IBM
Re: Adding static-PIE support to binutils
On Wed, Aug 19, 2015 at 01:30:12PM +0930, Alan Modra wrote: > On Tue, Aug 18, 2015 at 08:58:43PM -0400, Rich Felker wrote: > > 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. > > This is OK to commit with a suitable ChangeLog. I think a separate ld > option is best too, because historically -static and its aliases > -Bstatic, -dn, -non_shared really are about what type of libraries are > accepted rather than choosing linker output type. I see good arguments for both ways, and H.J. Lu seems to have switched sides midway if I understand correctly. Using the existing -static option seems nice in that it avoids the need for GCC to know whether ld supports --no-dynamic-linker, but GCC needs to know the right crt file to link anyway. And linking the rcrt1.o file with self-relocation code would be wrong if an external dynamic linker were used. So I don't think this really simplifies the GCC-side problem at all. On the other hand, having a dedicated option also makes other neat stuff possible: for instance, it's possible to do dynamic linking, but with the dynamic linker itself (or at least the bootstrap part of it) linked into the application. This is a potentially interesting setup when you don't want to depend on a fixed dynamic-linker path; the program could instead to an rpath-$ORIGIN style search for its dynamic linker and libs. I don't have any plans to implement such a thing right now, but it's nice to have the option to do so. Overloading -static would not allow this, or at least not easily, since it would suppress linking shared libraries unless you tweak the order perfectly. So, my mild preference is to stick with the way I've done it in the patch, using --no-dynamic-linker (or a different name if anyone wants to change the name). Rich
Re: Adding static-PIE support to binutils
> This is OK to commit with a suitable ChangeLog. I think a separate ld > option is best too, because historically -static and its aliases > -Bstatic, -dn, -non_shared really are about what type of libraries are > accepted rather than choosing linker output type. Gold actually separates these concepts: -Bstatic/-dn and -Bdynamic/-dy are about what kinds of libraries to search for, while -static and -shared/-Bshareable/-G determine what kind of output to produce. -cary
Re: Adding static-PIE support to binutils
On Tue, Aug 18, 2015 at 09:34:45PM -0700, Cary Coutant wrote: > > This is OK to commit with a suitable ChangeLog. I think a separate ld > > option is best too, because historically -static and its aliases > > -Bstatic, -dn, -non_shared really are about what type of libraries are > > accepted rather than choosing linker output type. > > Gold actually separates these concepts: -Bstatic/-dn and -Bdynamic/-dy > are about what kinds of libraries to search for, while -static and > -shared/-Bshareable/-G determine what kind of output to produce. Does static pie (ET_DYN with non-fixed load address, _DYNAMIC relocations, but no PT_INTERP, DT_NEEDEDs, or symbolic relocations) currently work with gold? If so, what is the way to request it? I would say it would make sense to try to do things the same, but from what you're saying it sounds like gold already significantly mismatches the bfd linker behavior...? Rich
Re: Adding static-PIE support to binutils
> Does static pie (ET_DYN with non-fixed load address, _DYNAMIC > relocations, but no PT_INTERP, DT_NEEDEDs, or symbolic relocations) > currently work with gold? If so, what is the way to request it? I > would say it would make sense to try to do things the same, but from > what you're saying it sounds like gold already significantly > mismatches the bfd linker behavior...? No, currently we reject -static and -pie when used together. But it could be supported. I don't think the differences are that significant in practice. In common usage, gold and Gnu ld end up doing the same thing. -cary
