[Bug ld/23729] New: PROVIDE inside --start-group/--end-group overrides defined symbol

[ivan at espressif dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23729

            Bug ID: 23729
           Summary: PROVIDE inside --start-group/--end-group overrides
                    defined symbol
           Product: binutils
           Version: 2.31
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: ivan at espressif dot com
  Target Milestone: ---

Created attachment 11285
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11285&action=edit
Files to reproduce the issue

Hello,

I am upgrading from Binutils 2.26.1 to Binutils 2.31.1 and seeing which might
be a regression, or at least, unexpected behavior change.

Consider the case:
* an application consists of a main source file (main.c) and a static library
(libfunc.a)
* main source file calls the function 'func' defined in the static library
* application also uses a linker script, which defines symbol 'func' using
PROVIDE(func = address);

Input files are given to the linker in the following order:

    --start-group libfunc.a main.o -T export.ld --end-group

With binutils 2.26.1, symbol 'func' is taken from 'libfunc.a'. With binutils
2.31.1, symbol 'func' is taken from the PROVIDE statement.

I can get obtain the old behavior (symbol 'func' taken from 'libfunc.a') if i
change the order of input files to:

    -T export.ld --start-group libfunc.a main.o --end-group

or:

    --start-group libfunc.a main.o --end-group -T export.ld


Issue was originally met for Xtensa ELF target, but I am also seeing it for
elf64-x86-64 (testing on Ubuntu 16.04).

If this new behavior is expected, please consider documenting this interaction
of PROVIDE and --start-group/--end-group.

Reproducer is attached. Unpack the archive, enter ld_provide_repro directory
and run 'make check'. If 'func' definition from LD script is used, its address
will be shown as 0x5000. Otherwise, if 'func' definition from libfunc.a is
used, its address will be 0x000b or similar small value.

-- 
You are receiving this mail because:
You are on the CC list for the bug.