[Bug gold/21054] [MIPS] Forced local symbol rearranging messes up GOT
https://sourceware.org/bugzilla/show_bug.cgi?id=21054 James Cowgill changed: What|Removed |Added Attachment #9754|0 |1 is obsolete|| --- Comment #1 from James Cowgill --- Created attachment 9757 --> https://sourceware.org/bugzilla/attachment.cgi?id=9757&action=edit testcase v2 Fix testcase to add missing section attribute. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld: once multiple symbol definitions are allowed, both definitions end up in the executable
Thanks a lot for the answer: it put me on the right track. The '-ffunction-sections' option works OK on toy examples though GNU linker crashed when I tried the following on real-life object files compiled with -ffunction-sections and -fdata-sections options enabled: for i in $object_files_original do objcopy --weaken $i # weaken symbols for linker not to complain about multiple definitions done ld.bfd -r --gc-sections -u external_symbol1... $object_files_with_replacement_fucntions $object_files_original -o combined.o ld.bfd: BFD (GNU Binutils) 2.27 assertion fail elflink.c:8380 Any clues how to debug it? Also I have not tried COMDAT magic: looks like there are no any external tweaks to put function to COMDAT sections but g++ decides on its own what should be go to COMDAT sections. On Wed, Jan 11, 2017 at 8:50 PM, Jim Wilson wrote: > On 01/11/2017 01:49 AM, Pavel Shishpor wrote: > >> Could please someone advice is it a bug or a feature when we get both >> bodies of the functions with the same name in the executable once >> multiple symbol definitions are allowed? Here is the example showing the >> behavior: >> > > The only thing that the --allow-multiple-definitions option does is > disable the error message that you would normally get. It doesn't change > how the linker output is created. So yes, you will end up with both > definitions in the output. > > It is best to avoid getting multiple definitions in the first place. > > If you want the linker to discard unused functions, then each function > must be in its own section via gcc -ffunction-sections and then use the > linker --gc-sections option. However, this may cause problems of its own, > e.g. debug functions may disappear because they appear unused, it won't > work for libraries where most functions are meant to be used by an > application it is linked with, etc. Or alternatively, you can try making > it a COMDAT function, then duplicates get dropped automatically. > > For your example, the duplicate f function is in the same text section as > the main function, which can't be deleted. The assembler may resolve > intra-section references itself. Which means editing the text section to > remove the f function may break other things in the same section, which is > unsafe, and hence the linker can't do it. Thus the requirement that we can > only delete functions that are in their own section. > > Jim > > ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21057] GDB build failure with flex 2.6.3
https://sourceware.org/bugzilla/show_bug.cgi?id=21057 Simon Marchi changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-17 CC||simon.marchi at ericsson dot com Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21057] GDB build failure with flex 2.6.3
https://sourceware.org/bugzilla/show_bug.cgi?id=21057 --- Comment #1 from Simon Marchi --- Here's the commit in flex at which the gdb build starts failing https://github.com/westes/flex/commit/347652c32b4614995acd4ee0d686499da2070d9e -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21057] GDB build failure with flex 2.6.3
https://sourceware.org/bugzilla/show_bug.cgi?id=21057
--- Comment #2 from Simon Marchi ---
Here are the differences between the 2.6.2-generated ada-lex.c and the
2.6.3-generated ada-lex.c:
--- ada-lex.c.2.6.2 2017-01-17 09:40:59.393641771 -0500
+++ ada-lex.c 2017-01-17 09:49:51.425905663 -0500
@@ -9,11 +9,89 @@
#define FLEX_SCANNER
#define YY_FLEX_MAJOR_VERSION 2
#define YY_FLEX_MINOR_VERSION 6
-#define YY_FLEX_SUBMINOR_VERSION 2
+#define YY_FLEX_SUBMINOR_VERSION 3
#if YY_FLEX_SUBMINOR_VERSION > 0
#define FLEX_BETA
#endif
+#define yy_create_buffer yy_create_buffer
+
+#define yy_delete_buffer yy_delete_buffer
+
+#define yy_scan_buffer yy_scan_buffer
+
+#define yy_scan_string yy_scan_string
+
+#define yy_scan_bytes yy_scan_bytes
+
+#define yy_init_buffer yy_init_buffer
+
+#define yy_flush_buffer yy_flush_buffer
+
+#define yy_load_buffer_state yy_load_buffer_state
+
+#define yy_switch_to_buffer yy_switch_to_buffer
+
+#define yypush_buffer_state yypush_buffer_state
+
+#define yypop_buffer_state yypop_buffer_state
+
+#define yyensure_buffer_stack yyensure_buffer_stack
+
+#define yylex yylex
+
+#define yyrestart yyrestart
+
+#define yylex_init yylex_init
+
+#define yylex_init_extra yylex_init_extra
+
+#define yylex_destroy yylex_destroy
+
+#define yyget_debug yyget_debug
+
+#define yyset_debug yyset_debug
+
+#define yyget_extra yyget_extra
+
+#define yyset_extra yyset_extra
+
+#define yyget_in yyget_in
+
+#define yyset_in yyset_in
+
+#define yyget_out yyget_out
+
+#define yyset_out yyset_out
+
+#define yyget_leng yyget_leng
+
+#define yyget_text yyget_text
+
+#define yyget_lineno yyget_lineno
+
+#define yyset_lineno yyset_lineno
+
+#define yywrap yywrap
+
+#define yyalloc yyalloc
+
+#define yyrealloc yyrealloc
+
+#define yyfree yyfree
+
+#define yytext yytext
+
+#define yyleng yyleng
+
+#define yyin yyin
+
+#define yyout yyout
+
+#define yy_flex_debug yy_flex_debug
+
+#define yylineno yylineno
+
/* First, we deal with platform-specific or compiler-specific issues. */
/* begin standard C headers. */
@@ -215,7 +293,7 @@
int yy_bs_lineno; /**< The line count. */
int yy_bs_column; /**< The column count. */
-
+
/* Whether to try to fill the input buffer when we reach the
* end of it.
*/
@@ -856,9 +934,9 @@
static int find_dot_all (const char *);
-#line 859 "ada-lex.c"
+#line 937 "ada-lex.c"
-#line 861 "ada-lex.c"
+#line 939 "ada-lex.c"
#define INITIAL 0
#define BEFORE_QUAL_QUOTE 1
@@ -1079,7 +1157,7 @@
#line 85 "/home/simark/src/binutils-gdb/gdb/ada-lex.l"
-#line 1082 "ada-lex.c"
+#line 1160 "ada-lex.c"
while ( /*CONSTCOND*/1 )/* loops until end-of-file is
reached */
{
@@ -1524,7 +1602,7 @@
#line 291 "/home/simark/src/binutils-gdb/gdb/ada-lex.l"
YY_FATAL_ERROR( "flex scanner jammed" );
YY_BREAK
-#line 1527 "ada-lex.c"
+#line 1605 "ada-lex.c"
case YY_STATE_EOF(INITIAL):
case YY_STATE_EOF(BEFORE_QUAL_QUOTE):
yyterminate();
@@ -2206,9 +2284,9 @@
);
if ( ! (yy_buffer_stack) )
YY_FATAL_ERROR( "out of dynamic memory in
yyensure_buffer_stack()" );
-
+
memset((yy_buffer_stack), 0, num_to_alloc * sizeof(struct
yy_buffer_state*));
-
+
(yy_buffer_stack_max) = num_to_alloc;
(yy_buffer_stack_top) = 0;
return;
@@ -2237,7 +2315,7 @@
* @param base the character buffer
* @param size the size in bytes of the character buffer
*
- * @return the newly allocated buffer state object.
+ * @return the newly allocated buffer state object.
*/
YY_BUFFER_STATE yy_scan_buffer (char * base, yy_size_t size )
{
@@ -2353,7 +2431,7 @@
*/
int yyget_lineno (void)
{
-
+
return yylineno;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld: once multiple symbol definitions are allowed, both definitions end up in the executable
On Tue, Jan 17, 2017 at 6:56 AM, Pavel Shishpor wrote: > Thanks a lot for the answer: it put me on the right track. The > '-ffunction-sections' option works OK on toy examples though GNU linker > crashed when I tried the following on real-life object files compiled with > -ffunction-sections and -fdata-sections options enabled: > > for i in $object_files_original > do > objcopy --weaken $i # weaken symbols for linker not to complain > about multiple definitions > done > ld.bfd -r --gc-sections -u external_symbol1... > $object_files_with_replacement_fucntions $object_files_original -o > combined.o > > ld.bfd: BFD (GNU Binutils) 2.27 assertion fail elflink.c:8380 > > > Any clues how to debug it? You can try different GNU ld versions. Maybe it works in an earlier or later version. In general, -ffunction-sections and -gc-sections are not commonly used options. So they may not be as reliable as most other gcc/ld options. Normally, I suggest trying gold, but I don't know if it implements -gc-sections. They don't bother to support some of the less common BFD linker options. Debugging this will require some knowledge of how bfd and the linker works, which could take some time. But in general, debugging this is the same as most other programs, put a breakpoint at the assert, and try to work your way backwards to figure out what went wrong. If you want us to debug this, then you have to file a bug report via bugzilla that has a testcase that we can use to reproduce. Speaking of which, the bug-gcc mailing list isn't really meant for emailed bug reports. It is where bugzilla sends email. It is better to ask a question on the main list, or to file a bug report into bugzilla. > Also I have not tried COMDAT magic: looks like there are no any external > tweaks to put function to COMDAT sections but g++ decides on its own what > should be go to COMDAT sections. You are right. I thought we had an attribute or something. You might be able to do this by using a section attribute to put it in a linkonce section, but I'm not sure if that really works offhand. In general, as I mentioned earlier, it is best to avoid duplicate definitions to begin with, rather than try to fix them at link time. Jim ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/21054] [MIPS] Forced local symbol rearranging messes up GOT
https://sourceware.org/bugzilla/show_bug.cgi?id=21054 Emilio Pozuelo Monfort changed: What|Removed |Added CC||pochu27 at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21059] New: [PATCH] binutils 2.28 branch doesn't compile with flex 2.6.3
https://sourceware.org/bugzilla/show_bug.cgi?id=21059 Bug ID: 21059 Summary: [PATCH] binutils 2.28 branch doesn't compile with flex 2.6.3 Product: binutils Version: 2.28 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: bero at lindev dot ch Target Milestone: --- Created attachment 9759 --> https://sourceware.org/bugzilla/attachment.cgi?id=9759&action=edit Patch If flex 2.6.3 is used, building binutils-2_28-branch barfs with undefined references to yywrap (problem is the #ifndef yywrap constructs when flex 2.6.3 #defines yywrap unconditionally to support custom prefixes). Patch attached. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: "-flto -O2" shouln't opt out "undefined reference" error
On 01/16/2017 10:32 AM, Xuefer wrote: without -flto or without -O2 produce good (expected) result: configure:5332: checking for dlsym ... It isn't the linker that is the problem here. It is the compiler. But it isn't a compiler bug. An optimizing compiler is supposed to optimize code like this. I'd say the main problem is trying to use -flto at configure time. This is likely to break lots of configure scripts. char (*f) (); However, this particular problem I can fix with gcc by changing this line to char (* volatile f) (); and now gcc won't optimize away the store, even with -flto. Unfortunately, I can't check LLVM at the moment, as I don't have LLVM -flto support set up on any of my machines at the moment. So this can be fixed by not using -flto at configure time, or by modifying configure scripts to use volatile. There is no linker or compiler fix to make here. Jim ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: "-flto -O2" shouln't opt out "undefined reference" error
volatile: i tried already with clang/llvm it worked. i'm using gentoo linux, trying to emerge everything with -flto. i'm not sure if i understand linker/compiler bug or not a bug, i wonder how many script is affected by this issue. On Wed, Jan 18, 2017 at 7:53 AM Jim Wilson wrote: On 01/16/2017 10:32 AM, Xuefer wrote: > without -flto or without -O2 produce good (expected) result: > > configure:5332: checking for dlsym > ... It isn't the linker that is the problem here. It is the compiler. But it isn't a compiler bug. An optimizing compiler is supposed to optimize code like this. I'd say the main problem is trying to use -flto at configure time. This is likely to break lots of configure scripts. how could -lfto be not used with configure yet with make? pass another CFLAGS to make as argument? IIRC, we tends to assume configure use same CFLAGS as Makefile (which generated by configure anyway) > char (*f) (); However, this particular problem I can fix with gcc by changing this line to char (* volatile f) (); and now gcc won't optimize away the store, even with -flto. Unfortunately, I can't check LLVM at the moment, as I don't have LLVM -flto support set up on any of my machines at the moment. So this can be fixed by not using -flto at configure time, or by modifying configure scripts to use volatile. There is no linker or compiler fix to make here. Jim ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
