Re: Using the asm suffix
On Sun, Aug 16, 2015 at 06:33:40PM -0700, David Wohlferd wrote:
> As a followup to my update to the inline asm docs, I'm cleaning up the
> docs for 'Asm Labels.' The changes I want to make are pretty
> straight-forward (attached; comments welcome). But then I came across
> this line of code (from
> https://github.com/rschmukler/cs537-p5/blob/master/xv6/proc.h#L38):
>
> extern struct proc *proc asm("%gs:4");
>
> This x86 code says that 'proc' is located at an offset of 4 bytes from
> the gs register.
It says that the assembler name of the function is "%gs:4"; it works
by accident, not by design (imagine what would happen if the function
was defined in this same translation unit!)
> There isn't any description of using asm like this in the current Asm
> Labels docs.
And there shouldn't be. It's a hack.
Segher
RE: vectorization cost macro TARGET_VECTORIZE_ADD_STMT_COST
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: Friday, August 14, 2015 9:59 PM
To: Ajit Kumar Agarwal
Cc: Jeff Law; gcc@gcc.gnu.org; Vinod Kathail; Shail Aditya Gupta; Vidhumouli
Hunsigida; Nagaraju Mekala
Subject: RE: vectorization cost macro TARGET_VECTORIZE_ADD_STMT_COST
On August 14, 2015 5:03:58 PM GMT+02:00, Ajit Kumar Agarwal
wrote:
>
>
>-Original Message-
>From: Richard Biener [mailto:richard.guent...@gmail.com]
>Sent: Monday, August 03, 2015 2:59 PM
>To: Ajit Kumar Agarwal
>Cc: Jeff Law; gcc@gcc.gnu.org; Vinod Kathail; Shail Aditya Gupta;
>Vidhumouli Hunsigida; Nagaraju Mekala
>Subject: Re: vectorization cost macro TARGET_VECTORIZE_ADD_STMT_COST
>
>On Sun, Aug 2, 2015 at 4:13 PM, Ajit Kumar Agarwal
> wrote:
>> All:
>>
>> The definition of the following macro that determine the statement
>cost that adds to vectorization cost.
>>
>> #define TARGET_VECTORIZE_ADD_STMT_COST.
>>
>> In the implementation of the above macro the following is done for
>many vectorization supported architectures like i386, ARM.
>>
>> if (where == vect_body && stmt_info && stmt_in_inner_loop_p
>(stmt_info))
>> count *= 50; /* FIXME. */
>>
>> I have the following questions.
>>
>> 1. Why the multiplication factor of 50 is choosen?
>
>>>It's a wild guess. See
>tree-vect-loop.c:vect_get_single_scalar_iteration_cost.
>
>> 2. The comment mentions that the inner loop relative to the loop
>being
>> vectorized is added more weight. If more weight is added to the inner
>
>> loop for the loop being vectorized, the chances of vectorizing the
>inner loop decreases. Why the inner loop cost is increased with
>relative to the loop being vectorized?
>
>>>In fact adding more weight to the inner loop increases the chance of
>vectorizing it (if vectorizing the inner loop is profitable).
>>>Both scalar and vector cost get biased by a factor of 50 (we assume
>50 iterations of the inner loop for one iteration of the outer loop),
>so a non-profitable >>vectorization in the outer loop can be offsetted
>by profitable inner loop vectorization.
>
>>>Yes, '50' can be improved if we actually know the iteration count of
>the inner loop or if we have profile-feedback.
>
>Instead of vector and scalar cost get biased by a factor of 50, Can the
>benefit of vectorization calculated as follows
>
>Benefit = scalar cost - vector cost/VF; Cost = 0; For ( I = 1; I < N;
>i++) {
>Cost = cost + (final_value - Initial value)/steps; }
>
>Benefit = Benefit * cost;
>
>Where
>N = No. of levels of the loop;
>Final_value = Final iteration count of the loop.
>Initial_value = Initial Iteration count of the loop.
>Steps = steps of the iteration for the loop.
>VF = vectorization factor.
>
>Thus increase in the Levels of the loops increases the benefit of
>vectorization. Also if the scalar cost is more than the vectorization
>cost then the Scalar cost - vector cost /VF increases with the same
>vectorization Factor thus increasing the benefit of vectorization.
>>Sure. But the number of iterations may only be available symbolically, thus
>>the cost be only useful for the dynamic check at runtime. A better static
estimate would also be useful.
Thanks. For the cases the loop bound can be known at the compile time, through
Value Range Analysis. Already GCC uses the value range
Information/Analysis To calculate the Loop bound. We can use the same loop
bound info to get the static estimate on the number of iterations.
Based on the above estimates, the above cost calculation as I have mentioned
can be used for Vectorization cost Analysis.
Thanks & Regards
Ajit
Richard.
>Thanks & Regards
>Ajit
>
>Richard.
>
>
>> Thanks & Regards
>> Ajit
Re: Using the asm suffix
On Sun, Aug 16, 2015 at 06:33:40PM -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?
> 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?
> +To specify the assember name for functions, write a declaration for the
^ typo
> +function before its definition and put @code{asm} there, like this:
> +
> @smallexample
> -extern func () asm ("FUNC");
> -
> -func (x, y)
> - int x, y;
> -/* @r{@dots{}} */
> +extern int func (int x, int y) asm ("MYFUNC");
> +
> +int func (int x, int y)
> +@{
> + /* @r{@dots{}} */
> @end smallexample
If you want to modernise the code, drop "extern" as well? :-)
> -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?
Segher
Re: Results from SPEC2006 FP analysis done at Richard`s request {late July / early August}
On Fri, Aug 14, 2015 at 3:35 PM, Abe Skolnik wrote: > [Alan wrote:] > >> Interesting, thanks. For what kind of architecture are these - > > You are welcome. > > You raised 2 or 3 good points, I think. > > First: the numbers are all from builds on and for the AMD64 ISA, AKA > "x86_64". My apologies for forgetting to mention that vital fact. > > Second: I did not tell the SPEC build system to use any particular "-march" > or "-mtune" flags, and AFAIK it [SPEC] did not add any that I didn`t specify. > In other words, those compiler-tuning values were almost certainly at their > GCC defaults. > > [A question about the preceding: is "-march=native" the default nowadays, at > least on GNU/Linux? AFAIK the default GCC behavior is (still?) to > generate code for the most generic form of the target ISA unless an explicit > flag overrides this.] > > Third: the server in question has Intel silicon for its CPUs. If an implicit > "-march=native" or similar is suspected of having been a factor, then please > let me know and I`ll report back on the specifics. [I am at home right now, > so I have no easy way of getting that data right now.] Ah, so for a meaningful comparison -march=native should be used. Otherwise we don't get much store if-conversion anyway. Richard. > >> specifically: with/out masked/gathering loads/stores ?? > > > TTBOMK, generic AMD64/x86_64 does _not_ have the gathering stuff and the very > latest from Intel _does_. > > Sorry, but I don`t know about the masked form[s]. If that`s important to > know, then please tell me and I will investigate. > > Regards, > > Abe
Re: Results from SPEC2006 FP analysis done at Richard`s request {late July / early August}
[Richard wrote:] Ah, so for a meaningful comparison -march=native should be used. Otherwise we don't get much store if-conversion anyway. Understood. I`ll adjust configuration files accordingly and redo the analyses. Please look for an updated report from me later this week. Regards, Abe
Re: Making __builtin_signbit type-generic
On Sun, 16 Aug 2015, FX wrote: > > It's necessary to avoid the type-generic signbit expanding to call a library > > function that may not exist, but as all currently supported floating-point > > formats do have a sign bit specified in signbit_ro I believe the case > > of failing to expand inline can be made into an abort. > > I can confirm that even in 2015, the only format which has (signbit_ro < > 0) is real_internal_format, which I think doesn’t matter here. So: > should I, in addition to the change in gcc/builtins.def, add some > aborts() or sorry() in gcc/builtins.c if we can’t expand (which should > never happen)? Well, a gcc_unreachable or gcc_assert, yes. And tests including that the compiler doesn't crash if you pass a type other than a real floating-point type (the validate_arglist call should handle that). -- Joseph S. Myers jos...@codesourcery.com
Re: CFI directives and dynamic stack alignment
On Tue, 2015-08-11 at 10:05 +0930, Alan Modra wrote: > > The 'and' instruction is where the stack gets aligned and if I remove that > > one instruction, everything works. I think I need to put out some new CFI > > psuedo-ops to handle this but I am not sure what they should be. I am just > > not very familiar with the CFI directives. > > I don't speak mips assembly very well, but it looks to me that you > have more than just CFI problems. How do you restore sp on return > from the function, assuming sp wasn't 16-byte aligned to begin with? > Past that "and $sp,$sp,$3" you don't have any means of calculating > the original value of sp! (Which of course is why you also can't find > a way of representing the frame address.) I have code in expand_prologue that copies the incoming stack pointer to a temporary hard register and then I have code to the entry_block to copy that register into a virtual register. In the exit block that virtual register is copied back to a temporary hard register and expand_epilogue copies it back to $sp to restore the stack pointer. This function (fn2) ends with a call to abort, which is noreturn, so the optimizer sees that the epilogue is dead code and GCC determines that there is no need to save the old stack pointer since it will never get restored. I guess I need to tell GCC to save the stack pointer in expand_prologue even if it never sees a use for it. I guess I need to make the temporary register where I save $sp volatile or do something else so that the assignment (and its associated .cfi) is not deleted by the optimizer. Steve Ellcey sell...@imgtec.com
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 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? Rich
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: CFI directives and dynamic stack alignment
On Mon, Aug 17, 2015 at 10:38:22AM -0700, Steve Ellcey wrote: > On Tue, 2015-08-11 at 10:05 +0930, Alan Modra wrote: > > > > The 'and' instruction is where the stack gets aligned and if I remove that > > > one instruction, everything works. I think I need to put out some new CFI > > > psuedo-ops to handle this but I am not sure what they should be. I am > > > just > > > not very familiar with the CFI directives. > > > > I don't speak mips assembly very well, but it looks to me that you > > have more than just CFI problems. How do you restore sp on return > > from the function, assuming sp wasn't 16-byte aligned to begin with? > > Past that "and $sp,$sp,$3" you don't have any means of calculating > > the original value of sp! (Which of course is why you also can't find > > a way of representing the frame address.) > > I have code in expand_prologue that copies the incoming stack pointer to > a temporary hard register and then I have code to the entry_block to > copy that register into a virtual register. In the exit block that > virtual register is copied back to a temporary hard register and > expand_epilogue copies it back to $sp to restore the stack pointer. OK, then you need to emit a .cfi directive to say the frame top is given by the temp hard reg sometime after that assignment and before sp is aligned in the prologue, and another .cfi directive when copying to the pseudo. It's a while since I looked at the CFI code in gcc, but arranging this might be as simple as setting RTX_FRAME_RELATED_P on the insns involved. If -fasynchronous-unwind-tables, then you'll also need to track the frame in the epilogue. > This function (fn2) ends with a call to abort, which is noreturn, so the > optimizer sees that the epilogue is dead code and GCC determines that > there is no need to save the old stack pointer since it will never get > restored. I guess I need to tell GCC to save the stack pointer in > expand_prologue even if it never sees a use for it. I guess I need to > make the temporary register where I save $sp volatile or do something > else so that the assignment (and its associated .cfi) is not deleted by > the optimizer. Ah, I see. Yes, the temp and pseudo are not really dead if they are needed for unwinding. -- Alan Modra Australia Development Lab, IBM
Re: Adding static-PIE support to binutils
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? Rich
Re: Adding static-PIE support to binutils
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.
Rich
--- binutils-2.25.1.orig/bfd/elf32-sh.c
+++ binutils-2.25.1/bfd/elf32-sh.c
@@ -3344,7 +3344,7 @@
if (htab->root.dynamic_sections_created)
{
/* Set the contents of the .interp section to the interpreter. */
- if (info->executable)
+ if (info->executable && !info->nointerp)
{
s = bfd_get_linker_section (dynobj, ".interp");
BFD_ASSERT (s != NULL);
--- binutils-2.25.1.orig/bfd/elflink.c
+++ binutils-2.25.1/bfd/elflink.c
@@ -206,7 +206,7 @@
/* A dynamically linked executable has a .interp section, but a
shared library does not. */
- if (info->executable)
+ if (info->executable && !info->nointerp)
{
s = bfd_make_section_anyway_with_flags (abfd, ".interp",
flags | SEC_READONLY);
@@ -5620,7 +5620,7 @@
bfd_boolean all_defined;
*sinterpptr = bfd_get_linker_section (dynobj, ".interp");
- BFD_ASSERT (*sinterpptr != NULL || !info->executable);
+ BFD_ASSERT (*sinterpptr != NULL || !info->executable || info->nointerp);
if (soname != NULL)
{
--- binutils-2.25.1.orig/include/bfdlink.h
+++ binutils-2.25.1/include/bfdlink.h
@@ -426,6 +426,9 @@
/* TRUE if BND prefix in PLT entries is always generated. */
unsigned int bndplt: 1;
+ /* TRUE if generation of .interp/PT_INTERP should be suppressed. */
+ unsigned int nointerp: 1;
+
/* Char that may appear as the first char of a symbol, but should be
skipped (like symbol_leading_char) when looking up symbols in
wrap_hash. Used by PowerPC Linux for 'dot' symbols. */
--- binutils-2.25.1.orig/ld/ldlex.h
+++ binutils-2.25.1/ld/ldlex.h
@@ -33,6 +33,7 @@
OPTION_DEFSYM,
OPTION_DEMANGLE,
OPTION_DYNAMIC_LINKER,
+ OPTION_NO_DYNAMIC_LINKER,
OPTION_SYSROOT,
OPTION_EB,
OPTION_EL,
--- binutils-2.25.1.orig/ld/lexsup.c
+++ binutils-2.25.1/ld/lexsup.c
@@ -138,6 +138,9 @@
{ {"dynamic-linker", required_argument, NULL, OPTION_DYNAMIC_LINKER},
'I', N_("PROGRAM"), N_("Set PROGRAM as the dynamic linker to use"),
TWO_DASHES },
+ { {"no-dynamic-linker", no_
Re: Using the asm suffix
There isn't any description of using asm like this in the current Asm Labels docs. And there shouldn't be. It's a hack. Ok, good. After experimenting with this, I wasn't looking forward to trying to describe what did and didn't work. dw
Re: Using the asm suffix
Thank you for the review and comments.
On 8/17/2015 3:41 AM, Segher Boessenkool wrote:
On Sun, Aug 16, 2015 at 06:33:40PM -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.
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.
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.
+To specify the assember name for functions, write a declaration for the
^ typo
Some typos are more embarrassing than others.
+function before its definition and put @code{asm} there, like this:
+
@smallexample
-extern func () asm ("FUNC");
-
-func (x, y)
- int x, y;
-/* @r{@dots{}} */
+extern int func (int x, int y) asm ("MYFUNC");
+
+int func (int x, int y)
+@{
+ /* @r{@dots{}} */
@end smallexample
If you want to modernise the code, drop "extern" as well? :-)
Ok.
-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.
Update attached.
dw
Index: extend.texi
===
--- extend.texi (revision 226751)
+++ extend.texi (working copy)
@@ -8367,8 +8367,14 @@
You can specify the name to be used in the assembler code for a C
function or variable by writing the @code{asm} (or @code{__asm__})
-keyword after the declarator as follows:
+keyword after the declarator.
+It is up to you to make sure that the assembler names you choose do not
+conflict with any other assembler symbols.
+@subsubheading Assembler names for data:
+
+This sample shows how to specify the assembler name for data:
+
@smallexample
int foo asm ("myfoo") = 2;
@end smallexample
@@ -8379,33 +8385,30 @@
@samp{_foo}.
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.
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}.
-You cannot use @code{asm} in this way in a function @emph{definition}; but
-you can get the same effect by writing a declaration for the function
-before its definition and putting @code{asm} there, like this:
+@subsubheading Assembler names for functions:
+To specify the assembler name for functions, write a declaration for the
+function before its definition and put @code{asm} there, like this:
+
@smallexample
-extern func () asm ("FUNC");
-
-func (x, y)
- int x, y;
-/* @r{@dots{}} */
+int func (int x, int y) asm ("MYFUNC");
+
+int func (int x, int y)
+@{
+ /* @r{@dots{}} */
@end smallexample
-It is up to you to make sure that the assembler names you choose do not
-conflict with any other assembler symbols. 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.
+@noindent
+This specifies that the name to be used for the function @code{func} in
+the assembler code should be @code{MYFUNC}.
@node Explicit Reg Vars
@subsection Variables in Specified Registers
Re: Adding static-PIE support to binutils
> 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). 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. -cary
