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

            Bug ID: 43936
           Summary: Don't add symbol name strings to non-alloc string
                    table in program header
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-objcopy/strip
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected],
                    [email protected],
                    [email protected],
                    [email protected], [email protected]

This is closely related to bug 43935 and bug 43931, but is somewhat separate.

If --add-symbol is run on an ELF with no symbol table, a symbol table is
created. The names of symbols in that symbol table are placed in the first
non-alloc string table section that can be found that is not the section header
string table, falling back to the section header string table if no such
section can be found. It is possible that a string table could be found that is
contained within a program header. If this table is used, the strings will be
"added" to that table, but not actually appear in the output, because within
segments, the program header contents are preserved. It does however change the
section header size (but see also bug 43931). Additionally, if the strings
added are long enough, the names could extend past the end of the program
header, and be written in space after it. I haven't checked exactly what will
happen, but either these strings will be overwritten by something later, or
they themselves will overwrite this data later. Either is bad. The change in
the section header size could also cause layout to be messed up.

We shouldn't pick sections within segments as candidates for the new symbol
table's string table.

Note that bug 43935 means the output file will be invalid, even if this is
fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to