OS-7645: ctf symbol mapping needs work


Issue Type:Improvement
Priority:4 - Normal
Created at:2019-03-07T18:22:52.775Z
Updated at:2019-03-20T18:54:16.924Z


Created by:Former user
Reported by:Former user
Assigned to:Former user


Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2019-03-20T18:54:16.909Z)

Fix Versions

2019-03-28 Operation Righteous Cowboy Lightning (Release Date: 2019-03-28)


CTF symbol mapping as implemented in the new round of CTF tools are broken. CTF symbol mapping refers to the act of taking information in a debug format, such as DWARF, and associating that with the corresponding symbol table entries while converting them into CTF.

When I introduced the new tools in OS-4548 (CTF Everywhere Part 1), the way that this mapping was performed was rather naive and in the cast of doing a ctfconvert on a final binary, entirely broken and would result in having few data objects in the CTF data.

The first issue is mostly easily seen when we convert multiple object files that all have the same static symbol, but different types. Imagine each file has a function that returns a different type. Unfortunately, the existing logic would just naively match them based on the name of the symbol and a few other things. This is fundamentally flawed as evidenced above.

The second case is one where when building our lists of symbols and functions we were adding entries that didn't have mappings into the lists, causing them to grow in size, but then also taking the first ones that we saw. This combined to basically not have valid type data for a number of types as the first dwarf compilation unit when converting all at once, would have only a handful of mappings for entries in the symbol table.

The solution here is to really overhaul how we do symbol mapping. First, we need to track a lot more of the elf information that's present. In essence, when matching local symbols we need to use the corresponding file that's indicated by the STT_FILE symbol. This stricter checking has some knock on effects.

These arise in the case of a mapfile reducing symbol visibility. Consider most libraries in illumos use a mapfile to limit symbol visibility to explicitly exported symbols. This causes the DWARF debug data and the symbol table to disagree. Such symbols were previously global which means that have external visibility; however, the reduction gives them a binding of STB_LOCAL. However, we know that such symbols will always be associated with the first STT_FILE symbol because they were previously not associated with any file and then reduced. Therefore, we can use this as a key as to when to perform such a mapping. However, when performing a dedup as part of the conversion of a single DWARF die we can't perform this.

This stricter checking also causes weak symbol mapping to need to be improved. The current version isn't perfect and we miss a few weak symbols, but not all of them. This is unfortunate; however, the general improvements in static symbols make this a worthwhile tradeoff. Solving weak symbols is tricky because while we can note the association of a weak symbol when we first convert single compilation unit, the general conditions we use for weak symbol mapping start to break down when we end up merging because of how the link-editor manipulates them.

Honestly, if we want weak symbol processing to be useful, we either need to ask that ld puts in a section of weak to strong symbol mappings so we can just do this once and for all or we need to wait until we actually do conversion in the link-editor.


Comment by Former user
Created at 2019-03-07T18:27:09.809Z
Updated at 2019-03-20T16:48:28.668Z

To test this, I did a few different things:

1. Changes because we actually changed the text (libctf)
2. Changes because we now properly identified local symbols. In dozens upon dozens of cases we incorrectly were mapping local symbols and always taking the first named definition, which meant that we had the incorrect versions present. I spot checked several examples of this to verify that they actually were different.
3. Programs that were build in illumos-extra and smartos-live had better reporting of STT_OBJECT symbols due to the fixes.
4. We did lose some small number of #pragma weak symbols. This is unfortunate; however, I think the other changes make this an important and worthwhile tradeoff.

Comment by Former user
Created at 2019-03-20T15:38:31.598Z

The full set of things that lost weak symbols are:

libm.so.1: _lib_version
libm.so.2: weak symbols
libc.so.1: synonyms
libld.so.1: lmalloc, lmutex_lock, lmutex_unlock
libresolv_joy.so.2: weak funcs
/lib/amd64/libbsm.so.1: weak funcs 
libc_hwcap*.so.1: weak syms

Comment by Jira Bot
Created at 2019-03-20T18:54:12.416Z

illumos-joyent commit cab8f574b2799281fddf00931d5f96a163272c9a (branch master, by Robert Mustacchi)

OS-7645 ctf symbol mapping needs work
OS-7653 ctf tools shouldn't add blank labels
Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
Reviewed by: John Levon <john.levon@joyent.com>
Approved by: John Levon <john.levon@joyent.com>