[llvm-bugs] [Bug 43931] New: Stop clearing all non-alloc string tables

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Nov 7 08:18:55 PST 2019


https://bugs.llvm.org/show_bug.cgi?id=43931

            Bug ID: 43931
           Summary: Stop clearing all non-alloc string tables
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-objcopy/strip
          Assignee: unassignedbugs at nondot.org
          Reporter: jh7370.2008 at my.bristol.ac.uk
                CC: alexander.v.shaposhnikov at gmail.com,
                    jake.h.ehrlich at gmail.com,
                    jh7370.2008 at my.bristol.ac.uk,
                    llvm-bugs at lists.llvm.org, rupprecht at google.com

llvm-objcopy (and llvm-strip), when it reads in an object, ignores the current
contents of all non-SHF_ALLOC SHT_STRTAB sections, and regenerates them when
writing out. This is fine for string tables that solely represent the symbol
table string table/section header string table, but if they contain contents
that are used by other sections (presumably user-defined/os-specific sections
etc), then the corresponding contents will be lost.

I'm not entirely sure what the solution is: we still want to remove names from
the symbol name table and section header string table if they aren't needed any
more after all. Perhaps the fix here is to preserve the existing contents of a
string table if it is referenced by another section's sh_link field (excepting
the special case of the reference from the symbol table). Optionally, it might
be okay to add new strings to the end of that section, but I think we'd need to
preserve the order of the other strings, so that any references to them are
maintained. Alternatively, we should only remove from/reorganise strings in
string tables when we know it is safe to do so.

GNU objcopy does not appear to clear the contents of such sections. I haven't
checked to see what it does for string tables that are symbol table or section
header string tables.

Example:

## test.yaml
--- !ELF
FileHeader:
  Class:   ELFCLASS64
  Data:    ELFDATA2LSB
  Type:    ET_REL
  Machine: EM_X86_64
Sections:
  - Name:    .foo
    Type:    SHT_PROGBITS
    Link:    .strings
  - Name:    .strings
    Type:    SHT_STRTAB
    Content: "00666700626300"

C:\Work> yaml2obj test.yaml -o test.o
C:\Work> llvm-readelf test.o --sections
There are 5 section headers, starting at offset 0x70:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg
Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00     
0   0  0
  [ 1] .foo              PROGBITS        0000000000000000 000040 000000 00     
2   0  0
  [ 2] .strings          STRTAB          0000000000000000 000040 000007 00     
0   0  0
  [ 3] .strtab           STRTAB          0000000000000000 000047 000001 00     
0   0  1
  [ 4] .shstrtab         STRTAB          0000000000000000 000048 000021 00     
0   0  1

C:\Work> llvm-objcopy test.o test2.o
C:\Work> llvm-readelf test2.o --sections
There are 5 section headers, starting at offset 0x68:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg
Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00     
0   0  0
  [ 1] .foo              PROGBITS        0000000000000000 000040 000000 00     
2   0  0
  [ 2] .strings          STRTAB          0000000000000000 000040 000001 00     
0   0  0
  [ 3] .strtab           STRTAB          0000000000000000 000041 000001 00     
0   0  1
  [ 4] .shstrtab         STRTAB          0000000000000000 000042 000021 00     
0   0  1

C:\Work> objcopy test.o test3.o
C:\Work> llvm-readelf test3.o --sections
There are 5 section headers, starting at offset 0x70:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg
Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00     
0   0  0
  [ 1] .foo              PROGBITS        0000000000000000 000040 000000 00     
0   0  1
  [ 2] .strings          STRTAB          0000000000000000 000040 000007 00     
0   0  1
  [ 3] .strtab           STRTAB          0000000000000000 000047 000001 00     
0   0  1
  [ 4] .shstrtab         STRTAB          0000000000000000 000048 000021 00     
0   0  1

Note that the size of .strings is 1 in test2.o, but 7 in the other two.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191107/53b3141a/attachment-0001.html>


More information about the llvm-bugs mailing list