Re: Jan Hubicka and Uros Bizjak appointed i386 maintainers
David Edelsohn wrote: I am pleased to announce that the GCC Steering Committee has appointed Jan Hubicka and Uros Bizjak as co-maintainers of the i386 port. Thank you! Please find attached the patch that updates my MAINTAINERS entry. 2007-01-09 Uros Bizjak <[EMAIL PROTECTED]> * MAINTAINERS: Add myself as i386 maintainer. Uros. Index: MAINTAINERS === --- MAINTAINERS (revision 120611) +++ MAINTAINERS (working copy) @@ -54,6 +54,7 @@ hppa port Dave Anglin [EMAIL PROTECTED] i386 port Richard Henderson [EMAIL PROTECTED] i386 port Jan Hubicka [EMAIL PROTECTED] +i386 port Uros Bizjak [EMAIL PROTECTED] ia64 port Jim Wilson [EMAIL PROTECTED] iq2000 port Nick Clifton [EMAIL PROTECTED] m32c port DJ Delorie [EMAIL PROTECTED] @@ -243,7 +244,6 @@ Jan Beulich [EMAIL PROTECTED] David Billinghurst[EMAIL PROTECTED] Laurynas Biveinis [EMAIL PROTECTED] -Uros Bizjak [EMAIL PROTECTED] Eric Blake [EMAIL PROTECTED] Jim Blandy [EMAIL PROTECTED] Phil Blundell [EMAIL PROTECTED]
About STACK ALIGNMENT
Hello all, 1. How do i get the stack alignment size of a particular target? Does #define STACK_BOUNDARY 32 serve this purpose? 2. Is it possible to override the STACK Alignment in ld file using ALIGN()? 3. Difference between stack alignment and data alignment? Regards, Rohit
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
H. J. Lu writes: > I am enclosing a patch to implement a new linker swicth, > --dynamic-list-data. It is -Bsymbolic for function symbols only. > I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64 > and Linux/ia64. There are only a few regressions. The function calls > within the new resulting DSOs will bind locally. It speeds up > the enclosed C++ testcase by > > 1. 23% on ia64. > 2. 6% on ia32. > 3. 3% on x86-64. > > Should we consider such optimization? That's a terrible name for the option. What does it mean? Andrew.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote: > H. J. Lu writes: > > I am enclosing a patch to implement a new linker swicth, > > --dynamic-list-data. It is -Bsymbolic for function symbols only. > > I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64 > > and Linux/ia64. There are only a few regressions. The function calls > > within the new resulting DSOs will bind locally. It speeds up > > the enclosed C++ testcase by > > > > 1. 23% on ia64. > > 2. 6% on ia32. > > 3. 3% on x86-64. > > > > Should we consider such optimization? > > That's a terrible name for the option. What does it mean? It is an extension of the current command line options: --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list --dynamic-list FILE Read dynamic list H.J.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
H. J. Lu writes: > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote: > > H. J. Lu writes: > > > I am enclosing a patch to implement a new linker swicth, > > > --dynamic-list-data. It is -Bsymbolic for function symbols only. > > > I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64 > > > and Linux/ia64. There are only a few regressions. The function calls > > > within the new resulting DSOs will bind locally. It speeds up > > > the enclosed C++ testcase by > > > > > > 1. 23% on ia64. > > > 2. 6% on ia32. > > > 3. 3% on x86-64. > > > > > > Should we consider such optimization? > > > > That's a terrible name for the option. What does it mean? > > It is an extension of the current command line options: > > --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list > --dynamic-list FILE Read dynamic list But you said it was like -Bsymbolic for function symbols only. What is the connection between C++ typeinfo and that? (Hint: Java doesn't use C++ typeinfo, but -Bsymbolic for function symbols only would be very useful.) Andrew.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote: > H. J. Lu writes: > > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote: > > > H. J. Lu writes: > > > > I am enclosing a patch to implement a new linker swicth, > > > > --dynamic-list-data. It is -Bsymbolic for function symbols only. > > > > I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64 > > > > and Linux/ia64. There are only a few regressions. The function calls > > > > within the new resulting DSOs will bind locally. It speeds up > > > > the enclosed C++ testcase by > > > > > > > > 1. 23% on ia64. > > > > 2. 6% on ia32. > > > > 3. 3% on x86-64. > > > > > > > > Should we consider such optimization? > > > > > > That's a terrible name for the option. What does it mean? > > > > It is an extension of the current command line options: > > > > --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list > > --dynamic-list FILE Read dynamic list > > But you said it was like -Bsymbolic for function symbols only. What > is the connection between C++ typeinfo and that? (Hint: Java doesn't > use C++ typeinfo, but -Bsymbolic for function symbols only would be > very useful.) --dynamic-list is a generic linker feature. Users have to provide a list of symbols, which will be bound dynamically and everything else is bound locally. --dynamic-list-cpp-typeinfo includes a prefined list for C++ typeinfo. --dynamic-list-data puts data symbols on the dynamic list. H.J.
Re: About STACK ALIGNMENT
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes: > 1. How do i get the stack alignment size of a particular target? >Does #define STACK_BOUNDARY 32 serve this purpose? STACK_BOUNDARY is used to express the alignment maintained by the hardware. In practice this means that gcc can expect the stack to be aligned to that boundary at function entry, and that gcc must maintain that stack alignment when calling a function. In some cases maintaining that alignment may need to be implemented in the function calling sequence. > 2. Is it possible to override the STACK Alignment in ld file using ALIGN()? No, that does not make sense. > 3. Difference between stack alignment and data alignment? One applies to the stack, which holds local variables, and the other applies to global and static variables. Ian
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
H. J. Lu writes: > On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote: > > H. J. Lu writes: > > > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote: > > > > H. J. Lu writes: > > > > > I am enclosing a patch to implement a new linker swicth, > > > > > --dynamic-list-data. It is -Bsymbolic for function symbols only. > > > > > I tried it with C, C++, Java and Fortran on Linux/ia32, > > Linux/x86-64 > > > > > and Linux/ia64. There are only a few regressions. The function > > calls > > > > > within the new resulting DSOs will bind locally. It speeds up > > > > > the enclosed C++ testcase by > > > > > > > > > > 1. 23% on ia64. > > > > > 2. 6% on ia32. > > > > > 3. 3% on x86-64. > > > > > > > > > > Should we consider such optimization? > > > > > > > > That's a terrible name for the option. What does it mean? > > > > > > It is an extension of the current command line options: > > > > > > --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list > > > --dynamic-list FILE Read dynamic list > > > > But you said it was like -Bsymbolic for function symbols only. What > > is the connection between C++ typeinfo and that? (Hint: Java doesn't > > use C++ typeinfo, but -Bsymbolic for function symbols only would be > > very useful.) > > --dynamic-list is a generic linker feature. Users have to provide a > list of symbols, which will be bound dynamically and everything else > is bound locally. --dynamic-list-cpp-typeinfo includes a prefined > list for C++ typeinfo. --dynamic-list-data puts data symbols on > the dynamic list. OK, so in the case of --dynamic-list-data, there is no user-supplied list. Instead, there's (conceptually) an automatically-generated list, which contains every symbol that doesn't point to a function. Can't you just call the new option -Bsymbolic-functions? At least then people like me might have an outside chance of remembering it. Andrew.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Tue, Jan 09, 2007 at 02:01:53PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote:
> > > H. J. Lu writes:
> > > > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote:
> > > > > H. J. Lu writes:
> > > > > > I am enclosing a patch to implement a new linker swicth,
> > > > > > --dynamic-list-data. It is -Bsymbolic for function symbols only.
> > > > > > I tried it with C, C++, Java and Fortran on Linux/ia32,
> Linux/x86-64
> > > > > > and Linux/ia64. There are only a few regressions. The function
> calls
> > > > > > within the new resulting DSOs will bind locally. It speeds up
> > > > > > the enclosed C++ testcase by
> > > > > >
> > > > > > 1. 23% on ia64.
> > > > > > 2. 6% on ia32.
> > > > > > 3. 3% on x86-64.
> > > > > >
> > > > > > Should we consider such optimization?
> > > > >
> > > > > That's a terrible name for the option. What does it mean?
> > > >
> > > > It is an extension of the current command line options:
> > > >
> > > > --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list
> > > > --dynamic-list FILE Read dynamic list
> > >
> > > But you said it was like -Bsymbolic for function symbols only. What
> > > is the connection between C++ typeinfo and that? (Hint: Java doesn't
> > > use C++ typeinfo, but -Bsymbolic for function symbols only would be
> > > very useful.)
> >
> > --dynamic-list is a generic linker feature. Users have to provide a
> > list of symbols, which will be bound dynamically and everything else
> > is bound locally. --dynamic-list-cpp-typeinfo includes a prefined
> > list for C++ typeinfo. --dynamic-list-data puts data symbols on
> > the dynamic list.
>
> OK, so in the case of --dynamic-list-data, there is no user-supplied
> list. Instead, there's (conceptually) an automatically-generated
> list, which contains every symbol that doesn't point to a function.
> Can't you just call the new option -Bsymbolic-functions? At least
> then people like me might have an outside chance of remembering it.
Here is the updated patch to use -Bsymbolic-functions instead.
H.J.
---
bfd/
2007-01-05 H.J. Lu <[EMAIL PROTECTED]>
PR ld/3831
* elf-bfd.h (bfd_elf_link_mark_dynamic_symbol): Add an
argument, Elf_Internal_Sym *.
* elflink.c (bfd_elf_link_mark_dynamic_symbol): Mark a data
symbol dynamic if info->symbolic_functions is TRUE.
(bfd_elf_record_link_assignment): Updated call to
bfd_elf_record_link_assignment.
(_bfd_elf_merge_symbol): Likewise. Always call
bfd_elf_link_mark_dynamic_symbol.
include/
2007-01-05 H.J. Lu <[EMAIL PROTECTED]>
PR ld/3831
* bfdlink.h (bfd_link_info): Rename dynamic to dynamic_list.
Add dynamic and symbolic_functions.
ld/
2007-01-05 H.J. Lu <[EMAIL PROTECTED]>
PR ld/3831
* ldlang.c (lang_process): Change link_info.dynamic to
link_info.dynamic_list.
(lang_append_dynamic_list): Likewise.
* ldmain.c (main): Likewise. Initialize link_info.dynamic and
link_info.symbolic_functions to FALSE.
* lexsup.c (option_values): Add OPTION_SYMBOLIC_FUNCTIONS.
(ld_options): Add -Bsymbolic-functions.
(parse_args): Change link_info.dynamic to link_info.dynamic_list.
Set link_info.symbolic_functions to TRUE for -Bsymbolic-functions.
Set link_info.dynamic to TRUE for --dynamic-list and
--dynamic-list-cpp-typeinfo.
--- binutils/bfd/elf-bfd.h.data 2007-01-09 05:49:14.0 -0800
+++ binutils/bfd/elf-bfd.h 2007-01-09 06:15:11.0 -0800
@@ -1858,7 +1858,8 @@ extern int bfd_elf_link_record_local_dyn
(struct bfd_link_info *, bfd *, long);
extern void bfd_elf_link_mark_dynamic_symbol
- (struct bfd_link_info *, struct elf_link_hash_entry *);
+ (struct bfd_link_info *, struct elf_link_hash_entry *,
+ Elf_Internal_Sym *);
extern bfd_boolean _bfd_elf_close_and_cleanup
(bfd *);
--- binutils/bfd/elflink.c.data 2007-01-09 05:49:14.0 -0800
+++ binutils/bfd/elflink.c 2007-01-09 06:15:11.0 -0800
@@ -454,14 +454,22 @@ bfd_elf_link_record_dynamic_symbol (stru
void
bfd_elf_link_mark_dynamic_symbol (struct bfd_link_info *info,
- struct elf_link_hash_entry *h)
+ struct elf_link_hash_entry *h,
+ Elf_Internal_Sym *sym)
{
- struct bfd_elf_dynamic_list *d = info->dynamic;
+ struct bfd_elf_dynamic_list *d = info->dynamic_list;
- if (d == NULL || info->relocatable)
+ /* It may be called more than once on the same H. */
+ if(h->dynamic || info->relocatable)
return;
- if ((*d->match) (&d->head, NULL, h->root.root.string))
+ if ((info->symbolic_functions
+ && (h->type == STT_OBJECT
+ || (sym != NULL
+ && ELF_ST_TYPE (sym->st_info) == STT_OBJECT)))
+ ||
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Mon, Jan 08, 2007 at 08:23:39PM -0800, H. J. Lu wrote:
> On Mon, Jan 08, 2007 at 08:09:59PM -0800, Andrew Pinski wrote:
> > On Mon, 2007-01-08 at 18:25 -0800, H. J. Lu wrote:
> > > I am enclosing a patch to implement a new linker swicth,
> > > --dynamic-list-data. It is -Bsymbolic for function symbols only.
> > > I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64
> > > and Linux/ia64. There are only a few regressions. The function calls
> > > within the new resulting DSOs will bind locally. It speeds up
> > > the enclosed C++ testcase by
> > >
> > > 1. 23% on ia64.
> > > 2. 6% on ia32.
> > > 3. 3% on x86-64.
> > >
> > > Should we consider such optimization?
> >
> > The real question is, does this work with operator new?
> >
> > In that if I a C++ developer provides a seperate operator new (and
> > delete), does libstdc++ use that one as required by the C++ standard?
>
> These are the regressions I was talking about. I can support them with
> a new linker switch. So far, we have
>
> --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list
> --dynamic-list FILE Read dynamic list
>
> My current proposal adds
>
> --dynamic-list-data Add data symbols to dynamic list
>
> I can add a new one
>
> --dynamic-list-cpp-new Add C++ new/delete to dynamic list
>
> Then we can build libstdc++ with
>
> --dynamic-list-data --dynamic-list-cpp-new
>
I am testing this patch now. It should fix the regresions when
libstdc++ is built with
-Bsymbolic-functions --dynamic-list-cpp-new
H.J.
2007-01-09 H.J. Lu <[EMAIL PROTECTED]>
* ldlang.c (lang_append_dynamic_list_cpp_new): New.
* ldlang.h (lang_append_dynamic_list_cpp_new): Likewise.
* lexsup.c (option_values): Add OPTION_DYNAMIC_LIST_CPP_NEW.
(ld_options): Add entries for OPTION_DYNAMIC_LIST_CPP_NEW.
(parse_args): Handle OPTION_DYNAMIC_LIST_CPP_NEW.
--- ld/ldlang.c.new 2007-01-09 06:15:11.0 -0800
+++ ld/ldlang.c 2007-01-09 06:20:41.0 -0800
@@ -7086,3 +7086,24 @@ lang_append_dynamic_list_cpp_typeinfo (v
lang_append_dynamic_list (dynamic);
}
+
+/* Append the list of C++ operator new and delete dynamic symbols to the
+ existing one. */
+
+void
+lang_append_dynamic_list_cpp_new (void)
+{
+ const char * symbols [] =
+{
+ "operator new*",
+ "operator delete*"
+};
+ struct bfd_elf_version_expr *dynamic = NULL;
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE (symbols); i++)
+dynamic = lang_new_vers_pattern (dynamic, symbols [i], "C++",
+FALSE);
+
+ lang_append_dynamic_list (dynamic);
+}
--- ld/ldlang.h.new 2006-10-25 07:31:37.0 -0700
+++ ld/ldlang.h 2007-01-09 06:21:08.0 -0800
@@ -607,6 +607,7 @@ extern void lang_register_vers_node
(const char *, struct bfd_elf_version_tree *, struct bfd_elf_version_deps *);
extern void lang_append_dynamic_list (struct bfd_elf_version_expr *);
extern void lang_append_dynamic_list_cpp_typeinfo (void);
+extern void lang_append_dynamic_list_cpp_new (void);
bfd_boolean unique_section_p
(const asection *);
extern void lang_add_unique
--- ld/lexsup.c.new 2007-01-09 06:15:11.0 -0800
+++ ld/lexsup.c 2007-01-09 06:22:30.0 -0800
@@ -109,6 +109,7 @@ enum option_values
OPTION_VERSION_SCRIPT,
OPTION_VERSION_EXPORTS_SECTION,
OPTION_DYNAMIC_LIST,
+ OPTION_DYNAMIC_LIST_CPP_NEW,
OPTION_DYNAMIC_LIST_CPP_TYPEINFO,
OPTION_WARN_COMMON,
OPTION_WARN_CONSTRUCTORS,
@@ -506,6 +507,8 @@ static const struct ld_option ld_options
OPTION_VERSION_EXPORTS_SECTION },
'\0', N_("SYMBOL"), N_("Take export symbols list from .exports, using\n"
"\t\t\t\tSYMBOL as the version."), TWO_DASHES },
+ { {"dynamic-list-cpp-new", no_argument, NULL, OPTION_DYNAMIC_LIST_CPP_NEW},
+'\0', NULL, N_("Use C++ operator new/delete dynamic list"), TWO_DASHES },
{ {"dynamic-list-cpp-typeinfo", no_argument, NULL,
OPTION_DYNAMIC_LIST_CPP_TYPEINFO},
'\0', NULL, N_("Use C++ typeinfo dynamic list"), TWO_DASHES },
{ {"dynamic-list", required_argument, NULL, OPTION_DYNAMIC_LIST},
@@ -1255,6 +1258,10 @@ parse_args (unsigned argc, char **argv)
lang_append_dynamic_list_cpp_typeinfo ();
link_info.dynamic = TRUE;
break;
+ case OPTION_DYNAMIC_LIST_CPP_NEW:
+ lang_append_dynamic_list_cpp_new ();
+ link_info.dynamic = TRUE;
+ break;
case OPTION_DYNAMIC_LIST:
/* This option indicates a small script that only specifies
a dynamic list. Read it, but don't assume that we've
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
I am testing this patch now. It should fix the regresions when libstdc++ is built with -Bsymbolic-functions --dynamic-list-cpp-new What about just --dynamic-list-cpp that enables the new behavior and implies --dynamic-list-cpp-typeinfo (I know that it is useless in this particular case, since C++ typeinfo is data, but in general such an option sounds more useful than only --dynamic-list-cpp-new). Paolo
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Tue, Jan 09, 2007 at 04:42:41PM +0100, Paolo Bonzini wrote: > > >I am testing this patch now. It should fix the regresions when > >libstdc++ is built with > > > >-Bsymbolic-functions --dynamic-list-cpp-new I tested it on gcc 4.2 with C, C++, Java and Fortran on Linux/x86-64. There is no regression. > > What about just --dynamic-list-cpp that enables the new behavior and > implies --dynamic-list-cpp-typeinfo (I know that it is useless in this > particular case, since C++ typeinfo is data, but in general such an > option sounds more useful than only --dynamic-list-cpp-new). I think you only need --dynamic-list-cpp-new for building libstdc++.so. -Bsymbolic-functions should be sufficient for other C++ shared libraries. H.J.
Re: Fwd: Re: gcc 4.1.1 for mcore
Hi Alex, this is the error message I'm getting: /tmp/ccvk5vjH.s:38: Error: operand must be absolute in range 1..32, not 53 I run on a Linux machine with AMD CPU (x86_64). Ah yes this problem. I have encountered it too. Presumably you are using a 64-bit Linux ? If you build in a 32-bit environment you can work around this problem. I use this command line, suggested to me by Alex Oliva: CC="gcc -m32" CXX="g++ -m32" ABI="32" setarch i686 I have a fix for the problem now, but the build fails later on (in newlib and then libiberty) so you'll have to give me another day to look at the problem. Cheers Nick
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Tue, Jan 09, 2007 at 06:18:19AM -0800, H. J. Lu wrote: > On Tue, Jan 09, 2007 at 02:01:53PM +, Andrew Haley wrote: > > H. J. Lu writes: > > > On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote: > > > > H. J. Lu writes: > > > > > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote: > > > > > > H. J. Lu writes: > > > > > > > I am enclosing a patch to implement a new linker swicth, > > > > > > > --dynamic-list-data. It is -Bsymbolic for function symbols > > only. > > > > > > > I tried it with C, C++, Java and Fortran on Linux/ia32, > > Linux/x86-64 > > > > > > > and Linux/ia64. There are only a few regressions. The function > > calls > > > > > > > within the new resulting DSOs will bind locally. It speeds up > > > > > > > the enclosed C++ testcase by > > > > > > > > > > > > > > 1. 23% on ia64. > > > > > > > 2. 6% on ia32. > > > > > > > 3. 3% on x86-64. > > > > > > > > > > > > > > Should we consider such optimization? > > > > > > > > > > > > That's a terrible name for the option. What does it mean? > > > > > > > > > > It is an extension of the current command line options: > > > > > > > > > > --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list > > > > > --dynamic-list FILE Read dynamic list > > > > > > > > But you said it was like -Bsymbolic for function symbols only. What > > > > is the connection between C++ typeinfo and that? (Hint: Java doesn't > > > > use C++ typeinfo, but -Bsymbolic for function symbols only would be > > > > very useful.) > > > > > > --dynamic-list is a generic linker feature. Users have to provide a > > > list of symbols, which will be bound dynamically and everything else > > > is bound locally. --dynamic-list-cpp-typeinfo includes a prefined > > > list for C++ typeinfo. --dynamic-list-data puts data symbols on > > > the dynamic list. > > > > OK, so in the case of --dynamic-list-data, there is no user-supplied > > list. Instead, there's (conceptually) an automatically-generated > > list, which contains every symbol that doesn't point to a function. > > Can't you just call the new option -Bsymbolic-functions? At least > > then people like me might have an outside chance of remembering it. > > Here is the updated patch to use -Bsymbolic-functions instead. > I just realized that --dynamic-list-data is -Bsymbolic for function symbols only when you build shared libraries. We can use --dynamic-list-data on executables to make global data symbols dynamic so that dlopened shared libraries can reference them. We can make -Bsymbolic-functions an alias of --dynamic-list-data. But we still need --dynamic-list-data since -Bsymbolic doesn't apply to executables. H.J.
RFC: Mark a section to be discarded for DSO and executable
With LTO, an object file may contain sections with IL, which can be discarded when building DSO and executable. Currently we can't mark such sections with gABI. With GNU linker, we can use a linker script to discard such sections. But it will be more generic to make a section to be discarded for DSO and executable in gABI. In that case, we don't need a special linker script to discard such sections. Something like #define SHF_DISCARD 0x800 would work. H.J.
Re: RFC: Mark a section to be discarded for DSO and executable
"H. J. Lu" <[EMAIL PROTECTED]> writes: > With LTO, an object file may contain sections with IL, which > can be discarded when building DSO and executable. Currently we can't > mark such sections with gABI. With GNU linker, we can use a > linker script to discard such sections. But it will be more generic > to make a section to be discarded for DSO and executable in gABI. > In that case, we don't need a special linker script to discard > such sections. Something like > > #define SHF_DISCARD 0x800 > > would work. That is not strictly required for LTO as I see it. With LTO, the lto program is going to read the .o files with the IL information. It will then generate a new .s file to pass to the assembler. The IL information will never go through the linker. Of course, it is also possible that LTO .o files with IL information will be passed directly to the linker, for whatever reason. In that case, we may want the linker to remove the IL information. This is not substantially different from the linker's current ability to strip debugging information on request. So if you want to propose a solution for that, I think you should consider how it can be used for debugging information as well. And I don't think SHF_DISCARD is a good name. We don't want to arbitrarily discard the data, we want to discard it in certain specific scenarios. Ian
Re: RFC: Mark a section to be discarded for DSO and executable
On 09 Jan 2007 10:09:35 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: "H. J. Lu" <[EMAIL PROTECTED]> writes: > With LTO, an object file may contain sections with IL, which > can be discarded when building DSO and executable. Currently we can't > mark such sections with gABI. With GNU linker, we can use a > linker script to discard such sections. But it will be more generic > to make a section to be discarded for DSO and executable in gABI. > In that case, we don't need a special linker script to discard > such sections. Something like > > #define SHF_DISCARD 0x800 > > would work. That is not strictly required for LTO as I see it. With LTO, the lto program is going to read the .o files with the IL information. It will then generate a new .s file to pass to the assembler. The IL information will never go through the linker. Not only this isn't a requirement, there's a scenario where you *want* to keep the IL inside LTO-optimized DSO and executables for re-optimization. With LTO and IL inside executables and DSO, it becomes possible to do profile-collection without any source code and re-optimize the binary. i.e. an executable can be released with IL inside, and the user of the binary can choose to do profile collection on their own input, and re-optimize the binary to squeeze more performance. This scenario also improves the usability of the profile-feedback directed optimization (by not requiring the source code access and the whole build environment for profile feedback optimization). Of course, it is also possible that LTO .o files with IL information will be passed directly to the linker, for whatever reason. In that case, we may want the linker to remove the IL information. This is not substantially different from the linker's current ability to strip debugging information on request. It should be optional for the linker to remove the sections containing IL. We probably want to have a new option to strip to remove such sections as well as linker option to remove such sections. So if you want to propose a solution for that, I think you should consider how it can be used for debugging information as well. And I don't think SHF_DISCARD is a good name. We don't want to arbitrarily discard the data, we want to discard it in certain specific scenarios. -- #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
Re: RFC: Mark a section to be discarded for DSO and executable
On Tue, Jan 09, 2007 at 10:09:35AM -0800, Ian Lance Taylor wrote: > > That is not strictly required for LTO as I see it. With LTO, the lto > program is going to read the .o files with the IL information. It > will then generate a new .s file to pass to the assembler. The IL > information will never go through the linker. > > Of course, it is also possible that LTO .o files with IL information > will be passed directly to the linker, for whatever reason. In that > case, we may want the linker to remove the IL information. This is > not substantially different from the linker's current ability to strip > debugging information on request. It is different since stripping debugging information is controlled by a linker switch. The new section attribute will make section to be discarded regardless any linker switch. > > So if you want to propose a solution for that, I think you should > consider how it can be used for debugging information as well. And I > don't think SHF_DISCARD is a good name. We don't want to arbitrarily > discard the data, we want to discard it in certain specific scenarios. It is just a way to make a section to be discarded for executable and DSO. I am not sure if you want to mark debugging information to be discarded unless you mean a switch which will ignore the new attribute so that such debugging information won't be discarded. You should mark a section with SHF_DISCARD only if such a section will be removed during final link in all scenarios. H.J.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Tue, Jan 09, 2007 at 09:42:40AM -0800, H. J. Lu wrote: > On Tue, Jan 09, 2007 at 06:18:19AM -0800, H. J. Lu wrote: > > On Tue, Jan 09, 2007 at 02:01:53PM +, Andrew Haley wrote: > > > H. J. Lu writes: > > > > On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote: > > > > > H. J. Lu writes: > > > > > > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote: > > > > > > > H. J. Lu writes: > > > > > > > > I am enclosing a patch to implement a new linker swicth, > > > > > > > > --dynamic-list-data. It is -Bsymbolic for function symbols > > > only. > > > > > > > > I tried it with C, C++, Java and Fortran on Linux/ia32, > > > Linux/x86-64 > > > > > > > > and Linux/ia64. There are only a few regressions. The > > > function calls > > > > > > > > within the new resulting DSOs will bind locally. It speeds up > > > > > > > > the enclosed C++ testcase by > > > > > > > > > > > > > > > > 1. 23% on ia64. > > > > > > > > 2. 6% on ia32. > > > > > > > > 3. 3% on x86-64. > > > > > > > > > > > > > > > > Should we consider such optimization? > > > > > > > > > > > > > > That's a terrible name for the option. What does it mean? > > > > > > > > > > > > It is an extension of the current command line options: > > > > > > > > > > > > --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list > > > > > > --dynamic-list FILE Read dynamic list > > > > > > > > > > But you said it was like -Bsymbolic for function symbols only. What > > > > > is the connection between C++ typeinfo and that? (Hint: Java doesn't > > > > > use C++ typeinfo, but -Bsymbolic for function symbols only would be > > > > > very useful.) > > > > > > > > --dynamic-list is a generic linker feature. Users have to provide a > > > > list of symbols, which will be bound dynamically and everything else > > > > is bound locally. --dynamic-list-cpp-typeinfo includes a prefined > > > > list for C++ typeinfo. --dynamic-list-data puts data symbols on > > > > the dynamic list. > > > > > > OK, so in the case of --dynamic-list-data, there is no user-supplied > > > list. Instead, there's (conceptually) an automatically-generated > > > list, which contains every symbol that doesn't point to a function. > > > Can't you just call the new option -Bsymbolic-functions? At least > > > then people like me might have an outside chance of remembering it. > > > > Here is the updated patch to use -Bsymbolic-functions instead. > > > > I just realized that --dynamic-list-data is -Bsymbolic for function > symbols only when you build shared libraries. We can use > --dynamic-list-data on executables to make global data symbols > dynamic so that dlopened shared libraries can reference them. We can > make -Bsymbolic-functions an alias of --dynamic-list-data. But > we still need --dynamic-list-data since -Bsymbolic doesn't apply to > executables. Here is the updated patch with testcases and document change. H.J. bfd/ 2007-01-09 H.J. Lu <[EMAIL PROTECTED]> PR ld/3831 * elf-bfd.h (bfd_elf_link_mark_dynamic_symbol): Add an argument, Elf_Internal_Sym *. * elflink.c (bfd_elf_link_mark_dynamic_symbol): Mark a data symbol dynamic if info->dynamic_data is TRUE. (bfd_elf_record_link_assignment): Updated call to bfd_elf_record_link_assignment. (_bfd_elf_merge_symbol): Likewise. Always call bfd_elf_link_mark_dynamic_symbol. include/ 2007-01-09 H.J. Lu <[EMAIL PROTECTED]> PR ld/3831 * bfdlink.h (bfd_link_info): Rename dynamic to dynamic_list. Add dynamic and dynamic_data. ld/ 2007-01-05 H.J. Lu <[EMAIL PROTECTED]> PR ld/3831 * NEWS: Mention -Bsymbolic-functions and --dynamic-list-data. * ld.texinfo: Document -Bsymbolic-functions and --dynamic-list-data. * ldlang.c (lang_process): Change link_info.dynamic to link_info.dynamic_list. (lang_append_dynamic_list): Likewise. * ldmain.c (main): Likewise. Initialize link_info.dynamic and link_info.dynamic_data to FALSE. * lexsup.c (option_values): Add OPTION_DYNAMIC_LIST_DATA. (ld_options): Add entries for -Bsymbolic-functions and --dynamic-list-data. Make -Bsymbolic-functions an alias of --dynamic-list-data. (parse_args): Change link_info.dynamic to link_info.dynamic_list. Set link_info.dynamic_data to TRUE for --dynamic-list-data. Set link_info.dynamic to TRUE for --dynamuc-list*. ld/testsuite/ 2007-01-09 H.J. Lu <[EMAIL PROTECTED]> * ld-elf/shared.exp: Add tests for --dynamic-list-data. --- binutils/bfd/elf-bfd.h.data 2007-01-09 09:00:51.0 -0800 +++ binutils/bfd/elf-bfd.h 2007-01-09 09:00:51.0 -0800 @@ -1858,7 +1858,8 @@ extern int bfd_elf_link_record_local_dyn (struct bfd_link_info *, bfd *, long); extern void bfd_elf_link_mark_dynamic_symbol - (struct bfd_link_info
Is delete (nothrow) supported?
Does gcc support "delete (nothrow)"? I ran into 2 problems: 1. I had to call destructor directly since A *p = new (std::nothrow) A; delete (std::nothrow) p; won't cpmpile. I had to use A *p = new (std::nothrow) A; ... operator delete (bb, std::nothrow); 2. A *bb = new (std::nothrow) A [10]; ... operator delete [] (bb, std::nothrow); causes memory corruption since compiler doesn't support delete (std::nothrow) [] p; What is the proper way to use "delete (nothrow)"? H.J.
Re: RFC: Mark a section to be discarded for DSO and executable
H. J. Lu wrote: With LTO, an object file may contain sections with IL, which can be discarded when building DSO and executable. Currently we can't mark such sections with gABI. With GNU linker, we can use a linker script to discard such sections. But it will be more generic to make a section to be discarded for DSO and executable in gABI. In that case, we don't need a special linker script to discard such sections. Something like #define SHF_DISCARD 0x800 would work. We invented: #define SHF_EXCLUDE 0x8000 a long time ago, which is applied to some sections within relocatable objects. Sections tagged with this flag are removed from any final object (executables of .so's). This probably should have followed a SHF_SUNW_ conversion, but this was invented long before we thought about OS specific flags. SHF_EXCLUDE This section is excluded from input to the link-edit of an executable or shared object. This flag is ignored if the SHF_ALLOC flag is also set, or if relocations exist against the section. -- Rod.
RE: RFC: Mark a section to be discarded for DSO and executable
Hi Rod, It looks like SHF_EXCLUDE is exactly what I am looking for. How useful is it in your experiences? Thanks. H.J. [EMAIL PROTECTED] >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of Rod Evans >Sent: Tuesday, January 09, 2007 2:15 PM >To: [EMAIL PROTECTED] >Cc: gcc@gcc.gnu.org; [EMAIL PROTECTED] >Subject: Re: RFC: Mark a section to be discarded for DSO and executable > > >H. J. Lu wrote: >> With LTO, an object file may contain sections with IL, which >> can be discarded when building DSO and executable. Currently we can't >> mark such sections with gABI. With GNU linker, we can use a >> linker script to discard such sections. But it will be more generic >> to make a section to be discarded for DSO and executable in gABI. >> In that case, we don't need a special linker script to discard >> such sections. Something like >> >> #define SHF_DISCARD 0x800 >> >> would work. > >We invented: > >#define SHF_EXCLUDE 0x8000 > >a long time ago, which is applied to some sections within relocatable >objects. Sections tagged with this flag are removed from any final >object (executables of .so's). > >This probably should have followed a SHF_SUNW_ conversion, but this >was invented long before we thought about OS specific flags. > > > > SHF_EXCLUDE > > This section is excluded from input to the link-edit of an executable > or shared object. This flag is ignored if the SHF_ALLOC flag is also > set, or if relocations exist against the section. > >-- > >Rod. > >--~--~-~--~~~---~--~~ > You received this message because you are subscribed to the Google Groups >"Generic System V Application Binary Interface" group. >To post to this group, send email to [EMAIL PROTECTED] >To unsubscribe from this group, send email to generic-abi- >[EMAIL PROTECTED] >For more options, visit this group at >http://groups.google.com/group/generic-abi?hl=en >-~--~~~~--~~--~--~---
Re: Is delete (nothrow) supported?
On Tue, Jan 09, 2007 at 01:55:44PM -0800, H. J. Lu wrote: > Does gcc support "delete (nothrow)"? I ran into 2 problems: > > 1. I had to call destructor directly since > > A *p = new (std::nothrow) A; > delete (std::nothrow) p; > > won't cpmpile. I had to use > > A *p = new (std::nothrow) A; > ... > operator delete (bb, std::nothrow); > > 2. > > A *bb = new (std::nothrow) A [10]; > ... > operator delete [] (bb, std::nothrow); > > causes memory corruption since compiler doesn't support > > delete (std::nothrow) [] p; > > What is the proper way to use "delete (nothrow)"? I figured out that "delete (nothrow)" is mainly for compiler uses. H.J.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Tue, Jan 09, 2007 at 07:52:42AM -0800, H. J. Lu wrote:
> >
> > What about just --dynamic-list-cpp that enables the new behavior and
> > implies --dynamic-list-cpp-typeinfo (I know that it is useless in this
> > particular case, since C++ typeinfo is data, but in general such an
> > option sounds more useful than only --dynamic-list-cpp-new).
>
> I think you only need --dynamic-list-cpp-new for building libstdc++.so.
> -Bsymbolic-functions should be sufficient for other C++ shared
> libraries.
>
Here is a patch for --dynamic-list-cpp-new with a testcase.
H.J.
---
ld/
2007-01-09 H.J. Lu <[EMAIL PROTECTED]>
* NEWS: Mention --dynamic-list-cpp-new.
* ld.texinfo: Document --dynamic-list-cpp-new.
* ldlang.c (lang_append_dynamic_list_cpp_new): New.
* ldlang.h (lang_append_dynamic_list_cpp_new): Likewise.
* lexsup.c (option_values): Add OPTION_DYNAMIC_LIST_CPP_NEW.
(ld_options): Add entry for --dynamic-list-cpp-new.
(parse_args): Handle OPTION_DYNAMIC_LIST_CPP_NEW.
ld/testsuite/
2007-01-09 H.J. Lu <[EMAIL PROTECTED]>
* ld-elf/del.cc: New.
* ld-elf/dl5.cc: Likewise.
* ld-elf/dl5.out: Likewise.
* ld-elf/new.cc: Likewise.
* ld-elf/shared.exp: Add --dynamic-list-cpp-new testcase.
--- ld/NEWS.new 2007-01-09 11:34:46.0 -0800
+++ ld/NEWS 2007-01-09 11:34:53.0 -0800
@@ -1,4 +1,7 @@
-*- text -*-
+* ELF: Add --dynamic-list-cpp-new, which puts C++ operator new and
+ delete on the dynamic list.
+
* ELF: Add -Bsymbolic-functions and --dynamic-list-data, builtin list
for --dynamic-list, which puts global data symbols on the dynamic list.
--- ld/ld.texinfo.new 2007-01-09 11:22:59.0 -0800
+++ ld/ld.texinfo 2007-01-09 11:31:50.0 -0800
@@ -1155,6 +1155,11 @@ scope and node name. See @ref{VERSION}
@item --dynamic-list-data
Include all global data symbols to the dynamic list.
[EMAIL PROTECTED] --dynamic-list-cpp-new
[EMAIL PROTECTED] --dynamic-list-cpp-new
+Provide the builtin dynamic list for C++ operator new and delete. It
+is mainly useful for building shared libstdc++.
+
@kindex --dynamic-list-cpp-typeinfo
@item --dynamic-list-cpp-typeinfo
Provide the builtin dynamic list for C++ runtime type identification.
--- ld/ldlang.c.new 2007-01-09 11:22:59.0 -0800
+++ ld/ldlang.c 2007-01-09 11:22:59.0 -0800
@@ -7086,3 +7086,24 @@ lang_append_dynamic_list_cpp_typeinfo (v
lang_append_dynamic_list (dynamic);
}
+
+/* Append the list of C++ operator new and delete dynamic symbols to the
+ existing one. */
+
+void
+lang_append_dynamic_list_cpp_new (void)
+{
+ const char * symbols [] =
+{
+ "operator new*",
+ "operator delete*"
+};
+ struct bfd_elf_version_expr *dynamic = NULL;
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE (symbols); i++)
+dynamic = lang_new_vers_pattern (dynamic, symbols [i], "C++",
+FALSE);
+
+ lang_append_dynamic_list (dynamic);
+}
--- ld/ldlang.h.new 2006-10-24 23:49:21.0 -0700
+++ ld/ldlang.h 2007-01-09 11:22:59.0 -0800
@@ -607,6 +607,7 @@ extern void lang_register_vers_node
(const char *, struct bfd_elf_version_tree *, struct bfd_elf_version_deps *);
extern void lang_append_dynamic_list (struct bfd_elf_version_expr *);
extern void lang_append_dynamic_list_cpp_typeinfo (void);
+extern void lang_append_dynamic_list_cpp_new (void);
bfd_boolean unique_section_p
(const asection *);
extern void lang_add_unique
--- ld/lexsup.c.new 2007-01-09 11:22:59.0 -0800
+++ ld/lexsup.c 2007-01-09 11:24:13.0 -0800
@@ -108,6 +108,7 @@ enum option_values
OPTION_VERSION_SCRIPT,
OPTION_VERSION_EXPORTS_SECTION,
OPTION_DYNAMIC_LIST,
+ OPTION_DYNAMIC_LIST_CPP_NEW,
OPTION_DYNAMIC_LIST_CPP_TYPEINFO,
OPTION_DYNAMIC_LIST_DATA,
OPTION_WARN_COMMON,
@@ -508,6 +509,8 @@ static const struct ld_option ld_options
'\0', NULL, N_("Bind global function references locally"), ONE_DASH },
{ {"dynamic-list-data", no_argument, NULL, OPTION_DYNAMIC_LIST_DATA},
'\0', NULL, N_("Add data symbols to dynamic list"), TWO_DASHES },
+ { {"dynamic-list-cpp-new", no_argument, NULL, OPTION_DYNAMIC_LIST_CPP_NEW},
+'\0', NULL, N_("Use C++ operator new/delete dynamic list"), TWO_DASHES },
{ {"dynamic-list-cpp-typeinfo", no_argument, NULL,
OPTION_DYNAMIC_LIST_CPP_TYPEINFO},
'\0', NULL, N_("Use C++ typeinfo dynamic list"), TWO_DASHES },
{ {"dynamic-list", required_argument, NULL, OPTION_DYNAMIC_LIST},
@@ -1257,6 +1260,10 @@ parse_args (unsigned argc, char **argv)
lang_append_dynamic_list_cpp_typeinfo ();
link_info.dynamic = TRUE;
break;
+ case OPTION_DYNAMIC_LIST_CPP_NEW:
+ lang_append_dynamic_list_cpp_new ();
+ link_info.dynamic = TRUE;
+ break;
case OPTION_DYNAMIC_LIST:
/* This option indicates a small script that only specifies
Re: RFC: Mark a section to be discarded for DSO and executable
Lu, Hongjiu wrote: It looks like SHF_EXCLUDE is exactly what I am looking for. How useful is it in your experiences? As far as I can tell, this was introduced with the SYSTEM V APPLICATION BINARY INTERFACE for the PowerPC Processor Supplement back in September 1995 :-) Then the Fortran folks got a hold of it for adding some specific sections that they didn't want added to the final output file. Whether it's being used today by any of our compiler components I don't know. I'll put some feelers out. -- Rod.
Re: RFC: Mark a section to be discarded for DSO and executable
Rod Evans wrote: Lu, Hongjiu wrote: It looks like SHF_EXCLUDE is exactly what I am looking for. How useful is it in your experiences? As far as I can tell, this was introduced with the SYSTEM V APPLICATION BINARY INTERFACE for the PowerPC Processor Supplement back in September 1995 :-) Then the Fortran folks got a hold of it for adding some specific sections that they didn't want added to the final output file. Whether it's being used today by any of our compiler components I don't know. I'll put some feelers out. Our compiler folks tell me that they can create optimization (.annotate) sections that are used during the compilation process, but are expected to be excluded from the final executable or shared object, and that these sections are being tagged SHF_EXCLUDE. -- Rod.
Re: proposal to clean up @node Warning Options in invoke.texi
Chris Pickett <[EMAIL PROTECTED]> writes: | Hi, | | For one reason or another, I have spent a fair amount of time reading | and getting confused by the warnings documentation. This applies to | the optimizations as well, but I thought I would start with the | warnings. Today I sat down and created a dependency graph for all of | the options in this node. I made this at first for my own benefit, | and then realized that other people might be interested in the | information. Thanks for doing this -- I believe it is really useful for users, but also for "new" implementers exercising in this area, and for old implementers for reminding the big picture. | I have attached the graph. I am asking for one or more people to | comment on its correctness, and what I consider to be errors, as | indicated in comments. | | Then I have the following proposal for cleaning up the options node in | invoke.texi: | | 1. Create a default section, at the top, and put all options enabled | by default there. | | 2. Try to group options so that they are closer to other connected | nodes in the graph. One thing that really is useful is that all warning flags are grouped in one section (further divided in sub-section). What one could do is to more cross-refs to other flags (not necessarily warning flags). | 3. Get rid of the -Wno-xxx option listings, since it is not always | the case that -Wxxx is enabled by "default", and this just ends up | being rather confusing. Instead, explain in the default section that | everything there can be disabled with -Wno-xxx. I assume the -Wno-xxx that are set by default would be moved to the "default" section? | 4. For each option, specify connected options systematically, perhaps | using the syntax I invented, perhaps using a different and more | natural (i.e. plain old English) syntax. I agree; we need more systematic rules to manage this ever-growing web of warning options. | | 5. Fix what I have labelled as errors. | | In a dream world where I had infinite time, I would invent a grammar | for specifying relationships between options and then use that to | generate number 4 above, and also use it to generate the option | parsing bits of the front end. | | Cheers, | Chris | # A --> Boption A implies option B | # A --> B C option A implies options B and C | # A && B --> C options A and B together imply C | | # A <-- Boption A is implied by option B. | # A <-- B || C option A is implied by either option B or option C | # A <-- B && C option A is implied by options B and C together it would also be useful to have a way to check the resulting redundancy. | # A ==> Boption A enables option B | # A ==> B C option A enables options B and C | # A <== Boption A requires option B (depends on B) | | default --> -Wimport -Wdiv-by-zero -Wendif-labels -Wattributes -Wmultichar | -Wnormalized=nfc -Wdeprecated-declarations -Winvalid-offset-of | -Wint-to-pointer-cast -Wpointer-to-int-cast plus others that are not controlled by named flags. | | -fsyntax-only | | -pedantic --> -Wlong-long -Wvariadic-macros -Wpointer-sign plus others that are not controlled by named flags. It is not obvious whether some of the warning should become hard errors or stay pedwarns as some of the pedwarns were introduced as transitional paths logn time ago. | -pedantic <-- -pedantic-errors -ansi (and corresponding -std= options) also implies pedwarns or errors but not all. Moreoverm, g++ -fpermissive issues warnings where it should be issueing hard errors. [...] | -Winit-self <== -Wuninitialized # depends not only on -O1, but -O(1|2|3|s) I believe the correct understanding is that it depends on optimization level different from -O0. [...] | -Wimplicit <-- -Wall # redundant implication Hmm, I don't understand what you mean here. [...] | -W --> -Wextra We would like "-W" not to be mentioned anymore. -- Gaby
