[Bug lto/104617] New: Bug in handling of 64k+ sections

[Bug lto/104617] New: Bug in handling of 64k+ sections

[jakub at gcc dot gnu.org]

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

            Bug ID: 104617
           Summary: Bug in handling of 64k+ sections
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

When foo1.c is:
#define A(n) int foo1##n(void) { return 1##n; }
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7)
A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7)
B(n##8) B(n##9)
#define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7)
C(n##8) C(n##9)
#define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7)
D(n##8) D(n##9)
E(0) E(1) E(2) D(30) D(31) C(320) C(321) C(322) C(323) C(324) C(325)
B(3260) B(3261) B(3262) B(3263) A(32640) A(32641) A(32642)
and I compile it like:
./xgcc -B ./ -c -g -fpic -ffat-lto-objects -flto  -O0 -o foo1.o foo1.c
-ffunction-sections
./xgcc -B ./ -shared -g -fpic -flto -O0 -o foo1.so foo1.o
/tmp/ccTW8mBm.debug.temp.o: file not recognized: file format not recognized

If I add -save-temps, and
readelf -WS foo1.o.debug.temp.o
I see various errors:
readelf: foo1.o.debug.temp.o: Warning: Section 2 has an out of range sh_link
value of 65321
readelf: foo1.o.debug.temp.o: Warning: Section 5 has an out of range sh_link
value of 65321
readelf: foo1.o.debug.temp.o: Warning: Section 10 has an out of range sh_link
value of 65323
There are 13 section headers, starting at offset 0x40:
readelf: foo1.o.debug.temp.o: Warning: [ 2]: Link field (65321) should index a
symtab section.
readelf: foo1.o.debug.temp.o: Warning: [ 5]: Link field (65321) should index a
symtab section.
readelf: foo1.o.debug.temp.o: Warning: [10]: Link field (65323) should index a
string section.

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg
Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00     
0   0  0
  [ 1] .debug_info       PROGBITS        0000000000000000 000380 057ac7 00     
0   0  1
  [ 2] .rela.debug_info  RELA            0000000000000000 057e48 0bf4c0 18   I
65321   1  8
  [ 3] .debug_abbrev     PROGBITS        0000000000000000 117308 00002f 00     
0   0  1
  [ 4] .debug_line       PROGBITS        0000000000000000 117337 000036 00     
0   0  1
  [ 5] .rela.debug_line  RELA            0000000000000000 117370 000048 18   I
65321   4  8
  [ 6] .debug_str        PROGBITS        0000000000000000 1173b8 04fbb7 01  MS 
0   0  1
  [ 7] .debug_line_str   PROGBITS        0000000000000000 166f6f 00001c 01  MS 
0   0  1
  [ 8] .comment          PROGBITS        0000000000000000 166f8b 00002b 01  MS 
0   0  1
  [ 9] .note.GNU-stack   PROGBITS        0000000000000000 166fb6 000000 00     
0   0  1
  [10] .symtab           SYMTAB          0000000000000000 166fb8 23dfa8 18    
65323 65315  8
  [11] .strtab           STRTAB          0000000000000000 3a4f60 04fb36 00     
0   0  1
  [12] .shstrtab         STRTAB          0000000000000000 3f4a96 000097 00     
0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  l (large), p (processor specific)

The sh_link fields containing 65321 looks to be a bug, it should be 10 instead.
65323 should be 11 (index of .strtab), 65315 is probably ok (that is how many
STB_LOCAL symbols are in .symtab).

[Bug lto/104617] Bug in handling of 64k+ sections

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Untested fix:
2022-02-21  Jakub Jelinek  <jakub@redhat.com>

        PR lto/104617
        * simple-object-elf.c (simple_object_elf_match): Fix up URL
        in comment.
        (simple_object_elf_copy_lto_debug_sections): Remap sh_info and
        sh_link even if they are in the SHN_LORESERVE .. SHN_HIRESERVE
        range (inclusive).

--- libiberty/simple-object-elf.c.jj    2022-01-11 23:11:23.967267993 +0100
+++ libiberty/simple-object-elf.c       2022-02-21 20:37:12.815202845 +0100
@@ -528,7 +528,7 @@ simple_object_elf_match (unsigned char h
             not handle objects with more than SHN_LORESERVE sections
             correctly.  All large section indexes were offset by
             0x100.  There is more information at
-            http://sourceware.org/bugzilla/show_bug.cgi?id-5900 .
+            http://sourceware.org/bugzilla/show_bug.cgi?id=5900 .
             Fortunately these object files are easy to detect, as the
             GNU binutils always put the section header string table
             near the end of the list of sections.  Thus if the
@@ -1559,17 +1559,13 @@ simple_object_elf_copy_lto_debug_section
          {
            sh_info = ELF_FETCH_FIELD (type_functions, ei_class, Shdr,
                                       shdr, sh_info, Elf_Word);
-           if (sh_info < SHN_LORESERVE
-               || sh_info > SHN_HIRESERVE)
-             sh_info = sh_map[sh_info];
+           sh_info = sh_map[sh_info];
            ELF_SET_FIELD (type_functions, ei_class, Shdr,
                           shdr, sh_info, Elf_Word, sh_info);
          }
        sh_link = ELF_FETCH_FIELD (type_functions, ei_class, Shdr,
                                   shdr, sh_link, Elf_Word);
-       if (sh_link < SHN_LORESERVE
-           || sh_link > SHN_HIRESERVE)
-         sh_link = sh_map[sh_link];
+       sh_link = sh_map[sh_link];
        ELF_SET_FIELD (type_functions, ei_class, Shdr,
                       shdr, sh_link, Elf_Word, sh_link);
       }

SHN_LORESERVE .. SHN_HIRESERVE is something only relevant for the 16-bit field,
i.e. st_shndx, e_shnum and e_shstrndx.  The latter two are moved to sh_size and
sh_link of the shdr[0], the first one into .symtab_shndx section.

[Bug lto/104617] Bug in handling of 64k+ sections

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
> Untested fix:
> 2022-02-21  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR lto/104617
> 	* simple-object-elf.c (simple_object_elf_match): Fix up URL
> 	in comment.
....
> 
> --- libiberty/simple-object-elf.c.jj	2022-01-11 23:11:23.967267993 +0100
> +++ libiberty/simple-object-elf.c	2022-02-21 20:37:12.815202845 +0100
> @@ -528,7 +528,7 @@ simple_object_elf_match (unsigned char h
>  	     not handle objects with more than SHN_LORESERVE sections
>  	     correctly.  All large section indexes were offset by
>  	     0x100.  There is more information at
> -	     http://sourceware.org/bugzilla/show_bug.cgi?id-5900 .
> +	     http://sourceware.org/bugzilla/show_bug.cgi?id=5900 .

So sourceware.org added the same feature as gcc.gnu.org and you can use a
shorten URL if you want and you should most likely use https intead of http
too:
https://sourceware.org/PR5900

[Bug lto/104617] Bug in handling of 64k+ sections

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:2f59f067610f22c3f2ec9b1516e24b85836676ed

commit r12-7325-g2f59f067610f22c3f2ec9b1516e24b85836676ed
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Feb 22 11:32:08 2022 +0100

    libiberty: Fix up debug.temp.o creation if *.o has 64K+ sections [PR104617]

    On
     #define A(n) int foo1##n(void) { return 1##n; }
     #define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6)
A(n##7) A(n##8) A(n##9)
     #define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6)
B(n##7) B(n##8) B(n##9)
     #define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6)
C(n##7) C(n##8) C(n##9)
     #define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6)
D(n##7) D(n##8) D(n##9)
     E(0) E(1) E(2) D(30) D(31) C(320) C(321) C(322) C(323) C(324) C(325)
     B(3260) B(3261) B(3262) B(3263) A(32640) A(32641) A(32642)
    testcase with
    ./xgcc -B ./ -c -g -fpic -ffat-lto-objects -flto  -O0 -o foo1.o foo1.c
-ffunction-sections
    ./xgcc -B ./ -shared -g -fpic -flto -O0 -o foo1.so foo1.o
    /tmp/ccTW8mBm.debug.temp.o: file not recognized: file format not recognized
    (testcase too slow to be included into testsuite).
    The problem is clearly reported by readelf:
    readelf: foo1.o.debug.temp.o: Warning: Section 2 has an out of range
sh_link value of 65321
    readelf: foo1.o.debug.temp.o: Warning: Section 5 has an out of range
sh_link value of 65321
    readelf: foo1.o.debug.temp.o: Warning: Section 10 has an out of range
sh_link value of 65323
    readelf: foo1.o.debug.temp.o: Warning: [ 2]: Link field (65321) should
index a symtab section.
    readelf: foo1.o.debug.temp.o: Warning: [ 5]: Link field (65321) should
index a symtab section.
    readelf: foo1.o.debug.temp.o: Warning: [10]: Link field (65323) should
index a string section.
    because simple_object_elf_copy_lto_debug_sections doesn't adjust sh_info
and
    sh_link fields in ElfNN_Shdr if they are in between SHN_{LO,HI}RESERVE
    inclusive.  Not adjusting those is incorrect though, SHN_{LO,HI}RESERVE
    range is only relevant to the 16-bit fields, mainly st_shndx in ElfNN_Sym
    where if one needs >= SHN_LORESERVE section number, SHN_XINDEX should be
    used instead and .symtab_shndx section should contain the real section
    index, and in ElfNN_Ehdr e_shnum and e_shstrndx fields, where if >=
    SHN_LORESERVE value is needed it should put those into
    Shdr[0].sh_{size,link}.  But, sh_{link,info} are 32-bit fields which can
    contain any section index.

    Note, as simple-object-elf.c mentions, binutils from 2.12 to 2.18 (so
before
    2011) used to mishandle the > 63.75K sections case and assumed there is a
    hole in between the sections, but what
    simple_object_elf_copy_lto_debug_sections does wouldn't help in that case
    for the debug temp object creation, we'd need to detect the case also in
    that routine and take it into account in the remapping etc.  I think
    it is not worth it given that it is over 10 years, if somebody needs
    63.75K or more sections, better use more recent binutils.

    2022-02-22  Jakub Jelinek  <jakub@redhat.com>

            PR lto/104617
            * simple-object-elf.c (simple_object_elf_match): Fix up URL
            in comment.
            (simple_object_elf_copy_lto_debug_sections): Remap sh_info and
            sh_link even if they are in the SHN_LORESERVE .. SHN_HIRESERVE
            range (inclusive).

[Bug lto/104617] Bug in handling of 64k+ sections

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:4e046995094df30be16e37f639efe77887197a22

commit r11-9717-g4e046995094df30be16e37f639efe77887197a22
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Feb 22 11:32:08 2022 +0100

    libiberty: Fix up debug.temp.o creation if *.o has 64K+ sections [PR104617]

    On
     #define A(n) int foo1##n(void) { return 1##n; }
     #define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6)
A(n##7) A(n##8) A(n##9)
     #define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6)
B(n##7) B(n##8) B(n##9)
     #define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6)
C(n##7) C(n##8) C(n##9)
     #define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6)
D(n##7) D(n##8) D(n##9)
     E(0) E(1) E(2) D(30) D(31) C(320) C(321) C(322) C(323) C(324) C(325)
     B(3260) B(3261) B(3262) B(3263) A(32640) A(32641) A(32642)
    testcase with
    ./xgcc -B ./ -c -g -fpic -ffat-lto-objects -flto  -O0 -o foo1.o foo1.c
-ffunction-sections
    ./xgcc -B ./ -shared -g -fpic -flto -O0 -o foo1.so foo1.o
    /tmp/ccTW8mBm.debug.temp.o: file not recognized: file format not recognized
    (testcase too slow to be included into testsuite).
    The problem is clearly reported by readelf:
    readelf: foo1.o.debug.temp.o: Warning: Section 2 has an out of range
sh_link value of 65321
    readelf: foo1.o.debug.temp.o: Warning: Section 5 has an out of range
sh_link value of 65321
    readelf: foo1.o.debug.temp.o: Warning: Section 10 has an out of range
sh_link value of 65323
    readelf: foo1.o.debug.temp.o: Warning: [ 2]: Link field (65321) should
index a symtab section.
    readelf: foo1.o.debug.temp.o: Warning: [ 5]: Link field (65321) should
index a symtab section.
    readelf: foo1.o.debug.temp.o: Warning: [10]: Link field (65323) should
index a string section.
    because simple_object_elf_copy_lto_debug_sections doesn't adjust sh_info
and
    sh_link fields in ElfNN_Shdr if they are in between SHN_{LO,HI}RESERVE
    inclusive.  Not adjusting those is incorrect though, SHN_{LO,HI}RESERVE
    range is only relevant to the 16-bit fields, mainly st_shndx in ElfNN_Sym
    where if one needs >= SHN_LORESERVE section number, SHN_XINDEX should be
    used instead and .symtab_shndx section should contain the real section
    index, and in ElfNN_Ehdr e_shnum and e_shstrndx fields, where if >=
    SHN_LORESERVE value is needed it should put those into
    Shdr[0].sh_{size,link}.  But, sh_{link,info} are 32-bit fields which can
    contain any section index.

    Note, as simple-object-elf.c mentions, binutils from 2.12 to 2.18 (so
before
    2011) used to mishandle the > 63.75K sections case and assumed there is a
    hole in between the sections, but what
    simple_object_elf_copy_lto_debug_sections does wouldn't help in that case
    for the debug temp object creation, we'd need to detect the case also in
    that routine and take it into account in the remapping etc.  I think
    it is not worth it given that it is over 10 years, if somebody needs
    63.75K or more sections, better use more recent binutils.

    2022-02-22  Jakub Jelinek  <jakub@redhat.com>

            PR lto/104617
            * simple-object-elf.c (simple_object_elf_match): Fix up URL
            in comment.
            (simple_object_elf_copy_lto_debug_sections): Remap sh_info and
            sh_link even if they are in the SHN_LORESERVE .. SHN_HIRESERVE
            range (inclusive).

    (cherry picked from commit 2f59f067610f22c3f2ec9b1516e24b85836676ed)

[Bug lto/104617] Bug in handling of 64k+ sections

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:60d1efc075ac297e208d4dcfc5a5c2a02b9a208b

commit r10-10687-g60d1efc075ac297e208d4dcfc5a5c2a02b9a208b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Feb 22 11:32:08 2022 +0100

    libiberty: Fix up debug.temp.o creation if *.o has 64K+ sections [PR104617]

    On
     #define A(n) int foo1##n(void) { return 1##n; }
     #define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6)
A(n##7) A(n##8) A(n##9)
     #define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6)
B(n##7) B(n##8) B(n##9)
     #define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6)
C(n##7) C(n##8) C(n##9)
     #define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6)
D(n##7) D(n##8) D(n##9)
     E(0) E(1) E(2) D(30) D(31) C(320) C(321) C(322) C(323) C(324) C(325)
     B(3260) B(3261) B(3262) B(3263) A(32640) A(32641) A(32642)
    testcase with
    ./xgcc -B ./ -c -g -fpic -ffat-lto-objects -flto  -O0 -o foo1.o foo1.c
-ffunction-sections
    ./xgcc -B ./ -shared -g -fpic -flto -O0 -o foo1.so foo1.o
    /tmp/ccTW8mBm.debug.temp.o: file not recognized: file format not recognized
    (testcase too slow to be included into testsuite).
    The problem is clearly reported by readelf:
    readelf: foo1.o.debug.temp.o: Warning: Section 2 has an out of range
sh_link value of 65321
    readelf: foo1.o.debug.temp.o: Warning: Section 5 has an out of range
sh_link value of 65321
    readelf: foo1.o.debug.temp.o: Warning: Section 10 has an out of range
sh_link value of 65323
    readelf: foo1.o.debug.temp.o: Warning: [ 2]: Link field (65321) should
index a symtab section.
    readelf: foo1.o.debug.temp.o: Warning: [ 5]: Link field (65321) should
index a symtab section.
    readelf: foo1.o.debug.temp.o: Warning: [10]: Link field (65323) should
index a string section.
    because simple_object_elf_copy_lto_debug_sections doesn't adjust sh_info
and
    sh_link fields in ElfNN_Shdr if they are in between SHN_{LO,HI}RESERVE
    inclusive.  Not adjusting those is incorrect though, SHN_{LO,HI}RESERVE
    range is only relevant to the 16-bit fields, mainly st_shndx in ElfNN_Sym
    where if one needs >= SHN_LORESERVE section number, SHN_XINDEX should be
    used instead and .symtab_shndx section should contain the real section
    index, and in ElfNN_Ehdr e_shnum and e_shstrndx fields, where if >=
    SHN_LORESERVE value is needed it should put those into
    Shdr[0].sh_{size,link}.  But, sh_{link,info} are 32-bit fields which can
    contain any section index.

    Note, as simple-object-elf.c mentions, binutils from 2.12 to 2.18 (so
before
    2011) used to mishandle the > 63.75K sections case and assumed there is a
    hole in between the sections, but what
    simple_object_elf_copy_lto_debug_sections does wouldn't help in that case
    for the debug temp object creation, we'd need to detect the case also in
    that routine and take it into account in the remapping etc.  I think
    it is not worth it given that it is over 10 years, if somebody needs
    63.75K or more sections, better use more recent binutils.

    2022-02-22  Jakub Jelinek  <jakub@redhat.com>

            PR lto/104617
            * simple-object-elf.c (simple_object_elf_match): Fix up URL
            in comment.
            (simple_object_elf_copy_lto_debug_sections): Remap sh_info and
            sh_link even if they are in the SHN_LORESERVE .. SHN_HIRESERVE
            range (inclusive).

    (cherry picked from commit 2f59f067610f22c3f2ec9b1516e24b85836676ed)

[Bug lto/104617] Bug in handling of 64k+ sections

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:2692cbbc12dd08a9f82411e1baf43d6211329b6c

commit r9-10133-g2692cbbc12dd08a9f82411e1baf43d6211329b6c
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Feb 22 11:32:08 2022 +0100

    libiberty: Fix up debug.temp.o creation if *.o has 64K+ sections [PR104617]

    On
     #define A(n) int foo1##n(void) { return 1##n; }
     #define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6)
A(n##7) A(n##8) A(n##9)
     #define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6)
B(n##7) B(n##8) B(n##9)
     #define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6)
C(n##7) C(n##8) C(n##9)
     #define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6)
D(n##7) D(n##8) D(n##9)
     E(0) E(1) E(2) D(30) D(31) C(320) C(321) C(322) C(323) C(324) C(325)
     B(3260) B(3261) B(3262) B(3263) A(32640) A(32641) A(32642)
    testcase with
    ./xgcc -B ./ -c -g -fpic -ffat-lto-objects -flto  -O0 -o foo1.o foo1.c
-ffunction-sections
    ./xgcc -B ./ -shared -g -fpic -flto -O0 -o foo1.so foo1.o
    /tmp/ccTW8mBm.debug.temp.o: file not recognized: file format not recognized
    (testcase too slow to be included into testsuite).
    The problem is clearly reported by readelf:
    readelf: foo1.o.debug.temp.o: Warning: Section 2 has an out of range
sh_link value of 65321
    readelf: foo1.o.debug.temp.o: Warning: Section 5 has an out of range
sh_link value of 65321
    readelf: foo1.o.debug.temp.o: Warning: Section 10 has an out of range
sh_link value of 65323
    readelf: foo1.o.debug.temp.o: Warning: [ 2]: Link field (65321) should
index a symtab section.
    readelf: foo1.o.debug.temp.o: Warning: [ 5]: Link field (65321) should
index a symtab section.
    readelf: foo1.o.debug.temp.o: Warning: [10]: Link field (65323) should
index a string section.
    because simple_object_elf_copy_lto_debug_sections doesn't adjust sh_info
and
    sh_link fields in ElfNN_Shdr if they are in between SHN_{LO,HI}RESERVE
    inclusive.  Not adjusting those is incorrect though, SHN_{LO,HI}RESERVE
    range is only relevant to the 16-bit fields, mainly st_shndx in ElfNN_Sym
    where if one needs >= SHN_LORESERVE section number, SHN_XINDEX should be
    used instead and .symtab_shndx section should contain the real section
    index, and in ElfNN_Ehdr e_shnum and e_shstrndx fields, where if >=
    SHN_LORESERVE value is needed it should put those into
    Shdr[0].sh_{size,link}.  But, sh_{link,info} are 32-bit fields which can
    contain any section index.

    Note, as simple-object-elf.c mentions, binutils from 2.12 to 2.18 (so
before
    2011) used to mishandle the > 63.75K sections case and assumed there is a
    hole in between the sections, but what
    simple_object_elf_copy_lto_debug_sections does wouldn't help in that case
    for the debug temp object creation, we'd need to detect the case also in
    that routine and take it into account in the remapping etc.  I think
    it is not worth it given that it is over 10 years, if somebody needs
    63.75K or more sections, better use more recent binutils.

    2022-02-22  Jakub Jelinek  <jakub@redhat.com>

            PR lto/104617
            * simple-object-elf.c (simple_object_elf_match): Fix up URL
            in comment.
            (simple_object_elf_copy_lto_debug_sections): Remap sh_info and
            sh_link even if they are in the SHN_LORESERVE .. SHN_HIRESERVE
            range (inclusive).

    (cherry picked from commit 2f59f067610f22c3f2ec9b1516e24b85836676ed)

[Bug lto/104617] Bug in handling of 64k+ sections

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.