[Bug binutils/15300] New: AR/NM/GNU LD and Gold should issue a warning when used on objects with GCC/LLVM LTO data in it and no other symbols
http://sourceware.org/bugzilla/show_bug.cgi?id=15300 Bug #: 15300 Summary: AR/NM/GNU LD and Gold should issue a warning when used on objects with GCC/LLVM LTO data in it and no other symbols Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassig...@sourceware.org ReportedBy: hubi...@gcc.gnu.org Classification: Unclassified To avoid dups of bugs like this http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56312 where users mistakely call ar/nm/ld without a plugin and gets undefined symbols, it would be great if the utilities was able to recognize objects only with LTO symbols and no other object table and issue warning that compilation is likely going to fail. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15300] AR/NM/GNU LD and Gold should issue a warning when used on objects with GCC/LLVM LTO data in it and no other symbols
http://sourceware.org/bugzilla/show_bug.cgi?id=15300
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #1 from Markus Trippelsdorf
2013-03-24 16:31:41 UTC ---
Or better still have the utilities load the plugin automatically.
I'm using the following patch successfully on my machine:
diff --git a/binutils/ar.c b/binutils/ar.c
index c424038..4b14dc5 100644
--- a/binutils/ar.c
+++ b/binutils/ar.c
@@ -138,7 +138,11 @@ static int show_version = 0;
static int show_help = 0;
+#if BFD_SUPPORTS_PLUGINS
+static const char *plugin_target = "plugin";
+#else
static const char *plugin_target = NULL;
+#endif
static const char *target = NULL;
@@ -553,7 +557,6 @@ decode_options (int argc, char **argv)
break;
case OPTION_PLUGIN:
#if BFD_SUPPORTS_PLUGINS
- plugin_target = "plugin";
bfd_plugin_set_plugin (optarg);
#else
fprintf (stderr, _("sorry - this program has been built without plugin
support\n"));
@@ -614,7 +617,6 @@ ranlib_main (int argc, char **argv)
/* PR binutils/13493: Support plugins. */
case OPTION_PLUGIN:
#if BFD_SUPPORTS_PLUGINS
- plugin_target = "plugin";
bfd_plugin_set_plugin (optarg);
#else
fprintf (stderr, _("sorry - this program has been built without plugin
support\n"));
diff --git a/binutils/nm.c b/binutils/nm.c
index ad38e27..84627bc 100644
--- a/binutils/nm.c
+++ b/binutils/nm.c
@@ -177,7 +177,11 @@ static char other_format[] = "%02x";
static char desc_format[] = "%04x";
static char *target = NULL;
-static char *plugin_target = NULL;
+#if BFD_SUPPORTS_PLUGINS
+static const char *plugin_target = "plugin";
+#else
+static const char *plugin_target = NULL;
+#endif
/* Used to cache the line numbers for a BFD. */
static bfd *lineno_cache_bfd;
@@ -1647,7 +1651,6 @@ main (int argc, char **argv)
case OPTION_PLUGIN:/* --plugin */
#if BFD_SUPPORTS_PLUGINS
- plugin_target = "plugin";
bfd_plugin_set_plugin (optarg);
#else
fatal (_("sorry - this program has been built without plugin
support\n"));
Two small scripts allow me to switch from clang's lto-plugin to gcc's:
% cat plugin_clang
sudo rm /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/*
sudo ln -s /usr/lib64/llvm/LLVMgold.so
/usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins
% cat plugin_gcc
sudo rm /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/*
sudo ln -s /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/liblto_plugin.so.0.0.0
/usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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/15300] AR/NM/GNU LD and Gold should issue a warning when used on objects with GCC/LLVM LTO data in it and no other symbols
http://sourceware.org/bugzilla/show_bug.cgi?id=15300 --- Comment #2 from hubicka at ucw dot cz 2013-03-24 18:02:40 UTC --- > Or better still have the utilities load the plugin automatically. Yes, I think ideally the LTO capable compilers should install plugins into the binutils search path and binutils should simply load all available plugins and see what files they claims. That way wrappers won't be needed and mixed LTOs (with LTO objects from different compilers) has chance to work. Honza -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15300] AR/NM/GNU LD and Gold should issue a warning when used on objects with GCC/LLVM LTO data in it and no other symbols
http://sourceware.org/bugzilla/show_bug.cgi?id=15300 --- Comment #3 from hubicka at ucw dot cz 2013-03-24 18:11:13 UTC --- Independently on that however I guess binutils should know to warn when the plugin mechanizm fails and LTO only object is being handled the normal way. It is really very common problem to run into and I think it is really hard to diagnoze for everyone except few people familiar with LTO machinery. Honza -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #21 from Ian Lance Taylor 2013-03-24 22:26:50 UTC --- I don't see why either of your suggested changes would be correct. Would you mind trying my patch, the second one in comment #13, to see if it fixes your problem? Thanks. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #22 from pete 2013-03-25 03:56:32 UTC --- (In reply to comment #21) > I don't see why either of your suggested changes would be correct. > > Would you mind trying my patch, the second one in comment #13, to see if it > fixes your problem? Yes, it can define the symbols correctly. > > Thanks. Is the in_reg() checking for the reference in regular object? If so, will it be more clear if we can check it first? like if (oldsym == NULL || !oldsym->in_reg()) return NULL; if (oldsym->source() != Symbol::IS_UNDEFINED && !oldsym->is_from_dynobj()) return NULL; Well, this is only my opinion. Another question about the only_if_ref flag. Is it for the reference in regular object? Looks like both reg/dyn symbols will go into the namepool, but we don't check in_reg() previously. Thanks. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 ld/15302] New: Branching to linker script symbol is resolved to improperly BLX instruction for cortex-m3
http://sourceware.org/bugzilla/show_bug.cgi?id=15302
Bug #: 15302
Summary: Branching to linker script symbol is resolved to
improperly BLX instruction for cortex-m3
Product: binutils
Version: 2.24 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: terry@arm.com
CC: joey...@arm.com
Classification: Unclassified
Host: i686
Target: cortex-m3
In C file I have a call to function extFunc which is then defined in my linker
script as a script symbol "extFunc = 0x1000 + 1;". In assembly code I got
branch instruction "bl extFunc", but in final image this instruction is
resolved to "blx 0x1000" which is illegal for cortex-m3 and will cause a
HardFault.
Should the ld consider the limitation of cortex-m3 or this is illegal usage
model? Please advise.
Here are steps to reproduce this problem.
My test.c file is:
extern void extFunc (void);
void main (void) {
extFunc ();
}
My link script file is simple as:
extFunc = 0x1000 + 1;
Command to compile the test.c is:
arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -c test.c
Command to build them together is:
arm-none-eabi-ld test.o -T link.ld
Disassemble the produced file and get:
terguo01@terry-pc01:latest$ ./install-native/bin/arm-none-eabi-objdump -d a.out
a.out: file format elf32-littlearm
Disassembly of section .text:
:
0:b580 push{r7, lr}
2:af00 addr7, sp, #0
4:f000 effc blx1000
8:bd80 pop{r7, pc}
a:bf00 nop
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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
