[Bug gold/16794] gold doesn't include the "implicit addend" when processing REL relocations to mergable sections
https://sourceware.org/bugzilla/show_bug.cgi?id=16794
--- Comment #8 from Ryan Prichard ---
> In a string merge section, sym+offset is valid only for offset within the
> string at sym.
The GNU assembler is apparently willing to use section+offset to identify a
mergeable string for some relocations (maybe non-PC-relative / non-GOT
relocations?).
e.g.:
extern int puts(const char*);
void func() { puts("foo1"); }
void func2() { puts("foo2"); }
If I compile with "gcc -m32 -fno-pie -O2 -c", I see these relocations in the
object file:
0004 0501 R_386_32 .rodata.str1.1
0024 0501 R_386_32 .rodata.str1.1
The assembly references local symbols (.LC0 and .LC1) within .rodata.str1.1,
but the assembler has omitted the symbols in favor of relocations to the
section itself. The second REL relocation has an addend of 5 stored inside the
.text content.
gold appears to handle merging section+offset relocations fine when they're
R_386_32, but not when they're R_386_GOTOFF. Both relocation types are
documented in the psABI as allowing an addend.
Also:
> I looked at the testcase briefly, and it looked like test.o contained two
> strings, "xabcde" and "abcde". ld.bfd merged the two, but ld.gold didn't. I
> used "GNU gold (GNU Binutils for Debian 2.31.1) 1.16".
gold's overlapping string merging happens when -O2 is passed to ld.gold, and I
hadn't passed -O2. When I do, I see the reported/unwanted ld.gold behavior.
--
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 gold/16794] gold doesn't include the "implicit addend" when processing REL relocations to mergable sections
https://sourceware.org/bugzilla/show_bug.cgi?id=16794 --- Comment #6 from Ryan Prichard --- I attached another test case to the Android NDK issue, https://github.com/android/ndk/issues/1076. -- 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 gold/16794] gold doesn't include the "implicit addend" when processing REL relocations to mergable sections
https://sourceware.org/bugzilla/show_bug.cgi?id=16794 --- Comment #5 from Ryan Prichard --- Created attachment 11983 --> https://sourceware.org/bugzilla/attachment.cgi?id=11983&action=edit testcase 2 -- 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 gold/16794] gold doesn't include the "implicit addend" when processing REL relocations to mergable sections
https://sourceware.org/bugzilla/show_bug.cgi?id=16794 Ryan Prichard changed: What|Removed |Added CC||danalbert at google 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 gold/16794] gold doesn't include the "implicit addend" when processing REL relocations to mergable sections
https://sourceware.org/bugzilla/show_bug.cgi?id=16794 Ryan Prichard changed: What|Removed |Added CC||rprichard at google dot com --- Comment #4 from Ryan Prichard --- I looked at the testcase briefly, and it looked like test.o contained two strings, "xabcde" and "abcde". ld.bfd merged the two, but ld.gold didn't. I used "GNU gold (GNU Binutils for Debian 2.31.1) 1.16". However, if I write a test case where the strings/constants are identical, they *are* merged, and gold doesn't reliably update the GOT offset on the relocations. Gold seems to handle a relocation to a local symbol within a mergeable section, but not a relocation to the section directly. I'll attach a test case that writes a couple of x86-32 assembly files and runs them on a Linux machine. I'm using the syntax, "(.rodata.str1.1+4)@GOTOFF(%ebx)" on x86-32 to reference the section rather than a symbol. LLVM has a workaround for this bug. It was briefly reverted, then restored: https://reviews.llvm.org/D64327. -- 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/22941] binutils build fails if intl/plural.y is newer than intl/plural.c
https://sourceware.org/bugzilla/show_bug.cgi?id=22941 Ryan Prichard changed: What|Removed |Added CC||juro.bystricky at intel dot com, ||rprichard at google 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/22941] binutils build fails if intl/plural.y is newer than intl/plural.c
https://sourceware.org/bugzilla/show_bug.cgi?id=22941 Ryan Prichard changed: What|Removed |Added Summary|binutils build fails if |binutils build fails if |intl/parser.y is newer than |intl/plural.y is newer than |intl/parser.c |intl/plural.c -- 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/22941] New: binutils build fails if intl/parser.y is newer than intl/parser.c
https://sourceware.org/bugzilla/show_bug.cgi?id=22941 Bug ID: 22941 Summary: binutils build fails if intl/parser.y is newer than intl/parser.c Product: binutils Version: 2.31 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: rprichard at google dot com Target Milestone: --- binutils has the same non-deterministic build problem that was reported in https://sourceware.org/bugzilla/show_bug.cgi?id=22432. (Aside: various other projects appear to have the same pair of files, e.g. gdb, gcc, e2fsprogs, ...) When I build binutils for Linux, it uses gettext from libc, but when I cross-compile for Windows, it instead used its bundled libintl. If I check out binutils source on a normal Linux desktop, the intl/plural.c and intl/plural.y typically have equal mtimes and ctimes, so the build system uses the intl/plural.c file (generated by Bison 1.35) and the build succeeds. If I instead use a WSL (Windows-Subsystem-for-Linux) environment, the intl/plural.y is typically newer than intl/plural.c (slower filesystem?), and the build system regenerates plural.c (using e.g. Bison 3.0.4). With the regenerated file, the build fails. Build errors: bison -y --name-prefix=__gettext --output plural.c ../../intl/plural.y ../../intl/plural.y:46.1-12: warning: deprecated directive, use ‘%pure-parser’ [-Wdeprecated] %pure_parser rm -f plural.h x86_64-w64-mingw32-gcc -c -g -O2 -D__USE_MINGW_ACCESS -DHAVE_CONFIG_H -I. -I../../intl plural.c In file included from ../../intl/plural.y:35:0: ../../intl/plural-exp.h:102:23: error: conflicting types for ‘libintl_gettextparse’ # define PLURAL_PARSE libintl_gettextparse ^ ../../intl/plural.y:40:25: note: in expansion of macro ‘PLURAL_PARSE’ # define __gettextparse PLURAL_PARSE ^~~~ plural.c:184:5: note: in expansion of macro ‘__gettextparse’ int __gettextparse (void); ^~ ../../intl/plural-exp.h:102:23: note: previous declaration of ‘libintl_gettextparse’ was here # define PLURAL_PARSE libintl_gettextparse ^ ../../intl/plural-exp.h:114:12: note: in expansion of macro ‘PLURAL_PARSE’ extern int PLURAL_PARSE PARAMS ((void *arg)); ^~~~ ../../intl/plural-exp.h:102:23: error: conflicting types for ‘libintl_gettextparse’ # define PLURAL_PARSE libintl_gettextparse ^ ../../intl/plural.y:40:25: note: in expansion of macro ‘PLURAL_PARSE’ # define __gettextparse PLURAL_PARSE ^~~~ plural.c:63:25: note: in expansion of macro ‘__gettextparse’ #define yyparse __gettextparse ^~ plural.c:1129:1: note: in expansion of macro ‘yyparse’ yyparse (void) ^~~ ../../intl/plural-exp.h:102:23: note: previous declaration of ‘libintl_gettextparse’ was here # define PLURAL_PARSE libintl_gettextparse ^ ../../intl/plural-exp.h:114:12: note: in expansion of macro ‘PLURAL_PARSE’ extern int PLURAL_PARSE PARAMS ((void *arg)); ^~~~ plural.c: In function ‘libintl_gettextparse’: plural.c:64:25: error: too few arguments to function ‘__gettextlex’ #define yylex __gettextlex ^ plural.c:1298:16: note: in expansion of macro ‘yylex’ yychar = yylex (&yylval); ^ plural.c:64:25: note: declared here #define yylex __gettextlex ^ ../../intl/plural.y:69:12: note: in expansion of macro ‘yylex’ static int yylex PARAMS ((YYSTYPE *lval, const char **pexp)); ^ ../../intl/plural.y:178:29: error: ‘arg’ undeclared (first use in this function) ((struct parse_args *) arg)->res = $1; ^~~ ../../intl/plural.y:178:29: note: each undeclared identifier is reported only once for each function it appears in Makefile:133: recipe for target 'plural.o' failed make[2]: *** [plural.o] Error 1 make[2]: Leaving directory '/usr/local/google/home/rprichard/android/binutils-gdb/out/intl' Makefile:6574: recipe for target 'all-intl' failed make[1]: *** [all-intl] Error 2 make[1]: Leaving directory '/usr/local/google/home/rprichard/android/binutils-gdb/out' Makefile:856: recipe for target 'all' failed make: *** [all] Error 2 binutils already requires bison to build, so it seems sensible to fix this issue the same way that glibc was already fixed: rprichard@cashew:~/android/binutils-gdb$ for f in $(find . -name '
[Bug gas/4029] relax_segment can't stabilize .gcc_except_table
https://sourceware.org/bugzilla/show_bug.cgi?id=4029 Ryan Prichard changed: What|Removed |Added CC||rprichard at google dot com --- Comment #13 from Ryan Prichard --- FWIW: This issue affects the LLVM assembler, too: https://bugs.llvm.org/show_bug.cgi?id=35809. -- 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
