https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968

--- Comment #57 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 
Uni-Bielefeld.DE> ---
> --- Comment #56 from rguenther at suse dot de <rguenther at suse dot de> ---
> On Wed, 10 Jan 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
[...]
> I can reproduce that with -ffat-lto-objects where indeed we somehow
> get confused when we should preserve only part of a SHT_GROUP given
> we don't "prune" groups.  The question to me is why do we put
> both macro sections in a single group ...  but that's probably
> an artifact on how things are supposed to work in the end...
> [I wonder if SHF_EXCLUDE works "properly" for group members when
> doing a non-LTO link]
>
> Anyway, this should be "easy" to fix with sth like
>
>       else if (sh_type == SHT_GROUP)
>         {
>           /* Remap section indices in groups and remove removed members.  
> */
>           unsigned char *ent, *dst;
>           for (dst = ent = buf + 4; ent < buf + length - 4; ent += 4)
>             {
>               unsigned shndx = type_functions->fetch_Elf_Word (ent);
>               if (pfnret[shndx - 1] == -1)
>                 ;
>               else
>                 {
>                   type_functions->set_Elf_Word (dst, sh_map[shndx]);
>                   dst += 4;
>                 }
>             }
>           /* Adjust the length.  */
>           length = dst - buf;
>         }
>
> in the group handling.
>
> That fixes -ffat-lto-objects handling for me with the testcase.
> Will re-test with that.

[I'm continuing this with examples from a build using gas 2.29 instead
of as since things are easier to see there.]

While this fixed the error in the group section

Group Section:  .group
  Signature Symbol: wm4.0.b58ba986a79b71e96526231091292919
  Members:
    index   flags / section
      [0]   [ COMDAT ]
      [1]   .debug_macro

COMDAT group section [    1] `.group' [wm4.0.b58ba986a79b71e96526231091292919]
contains 1 sections:
   [Index]    Name
   [    7]   .debug_macro

the link error (during ld -r) remains:

ld: fatal: relocation error: R_386_32: file /var/tmp//cco6lLmcdebugobjtem:
section [6].rel.debug_macro: symbol .debug_macro (section): symbol has been
discarded with discarded section: [7].debug_macro

Relocation Section:  .rel.debug_macro
  index  type      offset value  section      symbol
    [0]  R_386_32     0x3     0  .debug_macro .debug_line (section)
    [1]  R_386_32     0x8     0  .debug_macro .debug_macro (section)

We do have two .debug_macro sections and their corresponding reloc
sections here, as already in the input objects:

Section Header[6]:  sh_name: .rel.debug_macro
    sh_addr:      0               sh_flags:   [ SHF_INFO_LINK ]
    sh_size:      0x10            sh_type:    [ SHT_REL ]
    sh_offset:    0x324           sh_entsize: 0x8 (2 entries)
    sh_link:      11              sh_info:    5
    sh_addralign: 0x4       

Section Header[8]:  sh_name: .rel.debug_macro
    sh_addr:      0               sh_flags:   [ SHF_INFO_LINK ]
    sh_size:      0xa50           sh_type:    [ SHT_REL ]
    sh_offset:    0xaf4           sh_entsize: 0x8 (330 entries)
    sh_link:      11              sh_info:    7
    sh_addralign: 0x4       

Section Header[5]:  sh_name: .debug_macro
    sh_addr:      0               sh_flags:   0
    sh_size:      0x11            sh_type:    [ SHT_PROGBITS ]
    sh_offset:    0x312           sh_entsize: 0
    sh_link:      0               sh_info:    0
    sh_addralign: 0x1       

Section Header[7]:  sh_name: .debug_macro
    sh_addr:      0               sh_flags:   [ SHF_GROUP ]
    sh_size:      0x7c0           sh_type:    [ SHT_PROGBITS ]
    sh_offset:    0x334           sh_entsize: 0
    sh_link:      0               sh_info:    0
    sh_addralign: 0x1       

        Rainer

Reply via email to