Unexpected behaviour of the LLVM gold plugin with --allow-multiple-definition

Project Infrastructure LLVM Dev List Archives
1

Dear LLVM development team,

working with the LLVM gold plugin, I have encountered an unexpected behaviour when the option --allow-multiple-definition (or -z muldefs) is specified for the linker.

Let's suppose the following scenario with four simple source files:

----- main.c ------
#include "unit.h"

int main() {
     only_in_unit1();
     only_in_unit2();
     return get_unit_id();
}

----- unit.h ------

#ifndef _UNIT
#define _UNIT 1

int get_unit_id( void );
void only_in_unit1( void );
void only_in_unit2( void );

#endif

----- unit1.c ------

#include "unit.h"

int get_unit_id( void ) {
     return 1;
}

void only_in_unit1( void ) {}

----- unit2.c ------

#include "unit.h"

int get_unit_id( void ) {
     return 2;
}

void only_in_unit2( void ) {}

2

As it can be seen from the output, get_unit_id is chosen correctly from the
first unit*.c file specified in the input arguments.
However, the symbol only_in_unitX, where unitX is the second specified unit
file, is undefined. In general, it seems that whenever a file has a symbol
which was overridden, all symbols from the file are ignored and not linked
into the output file.

Hi Milan,

What was going on is that the gold plugin was ignoring errors from the
IR linker and continuing with a broken module. I have fixed that in
r192996 and gold should now report an error.

Is this an intended behaviour or I am misusing the commands and/or options?
Please let me now if there is any workaround (e.g. script for the GNU gold
linker) so that I can get the same outcome as in the case without
--emit-llvm.

To implement this we need two things:

* The ir linker itself needs to get a --allow-multiple-definition
option.That is, llvm-link of unit1 and unit2 should work if given that
option.
* We need to extend the gold api so that the plugin (and therefore
llvm) knows that --allow-multiple-definition is in effect.

Cheers,
Rafael