Home Original page

[patch] Fix handling of common symbols with plugins

Rafael Espíndola rafael.espindola@gmail.com
Tue Sep 9 23:42:00 GMT 2014 
Currently we don't produce the correct result if a common symbol shows
up in both ELF and IR. In a previous patch I tried to pass the size
information back to the plugin, but unfortunately there is no field in
d_plugin_symbol to pass the alignment.

What I have implemented now is:

* The plugin is expected to handle all common symbols in IR. It can do
it by merging them or by passing multiple objects to the linker with
each symbol.

* The linker will not blindly override a common symbol during the
replacement phase. Instead, the regular logic is applied so that we
don't discard information in case an ELF file had the largest size or
alignment.

In addition to "make check" I tested this with a small script and two
LLVM IR files. The script test all combinations of input order and
file type (IR or ELF) and checks that we get the same alignment and
size.

Cheers,
Rafael


gold
2014-09-09  Rafael Ávila de Espíndola <respindola@mozilla.com>

        * plugin.cc (Sized_pluginobj::do_add_symbols): Ignore isym->size.
        * resolve.cc (Symbol_table::resolve): Don't override common symbols
        during the replacement phase.

include
2014-09-09  Rafael Ávila de Espíndola <respindola@mozilla.com>

        * plugin-api.h (ld_plugin_symbol): Note that size is ignored.

ld
2014-09-09  Rafael Ávila de Espíndola <respindola@mozilla.com>

        * plugin.c (asymbol_from_plugin_symbol): Ignore ldsym->size.
        * testplug.c (parse_symdefstr): Ignore sym->size.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: common.patch
Type: text/x-patch
Size: 2863 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20140909/9806d2e7/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run.sh
Type: application/x-sh
Size: 702 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20140909/9806d2e7/attachment.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.ll
Type: application/octet-stream
Size: 34 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20140909/9806d2e7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.ll
Type: application/octet-stream
Size: 35 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20140909/9806d2e7/attachment-0001.obj>
More information about the Binutils mailing list