This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gold linker: rejected multiple definitions with the same absolute value


> When compiling a hardened kernel[0] with CONFIG_PAX_RAP=y and using
> ld.gold as my linker, I get the following error (among others similar):
>
>  ld: error: init/mounts.o: multiple definition of '__rap_hash_ret_panic'
>  ld: init/main.o: previous definition here
>
> As it says, the symbol is defined in both places...
>
>  $ readelf --symbols init/main.o | grep __rap_hash_ret_panic
>  415: ffffffff8eba9bf0     0 OBJECT  GLOBAL DEFAULT  ABS __rap_hash_r...
>
>  $ readelf --symbols init/mounts.o | grep __rap_hash_ret_panic
>  165: ffffffff8eba9bf0     0 OBJECT  GLOBAL DEFAULT  ABS __rap_hash_r...
> But, as you can see, both symbols have equal absolute values. The BFD
> linker lets that slide. Is the stricter approach the intended behavior
> for ld.gold?

I'm not sure if it was intentional or not, but I never considered
making an exception for the case where the definitions were identical.
Knowing now that ld.bfd does that, I'd be willing to have gold allow
this special case.

Let me ask you this, though: when the error was pointed out, did you
feel like it was a simple mistake, easily fixed, or do you think
there's a rationale for having the definition in both files?

I can see an argument for continuing to issue an error, or perhaps
just a warning, rather than silently permit it.

-cary


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]