[Bug tapsets/10206] symname() resolves incorrect symbols on ppc

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-05-28 09:28 -------
Completely unfiltered will be somewhat difficult since there are some strange
corner cases for not-really-a-symbol things that might have values that cannot
be made relative. See the comments in translate.cxx (dump_unwindsyms).

          // We are only interested in "real" symbols.
          // We omit symbols that have suspicious addresses (before base,
          // or after end).
          if ((GELF_ST_TYPE (sym.st_info) == STT_FUNC ||
               GELF_ST_TYPE (sym.st_info) == STT_OBJECT)
               && !(sym.st_shndx == SHN_UNDEF   // Value undefined,
                    || shndxp == (GElf_Word) -1 // in a non-allocated section,
                    || sym.st_value >= end      // beyond current module,
                    || sym.st_value < base))    // before first section.
            {

[...]
              if (n == 1 && modname == "kernel")
                {
                  // This is a symbol within a (possibly relocatable)
                  // kernel image.

                  // We only need the function symbols to identify kernel-mode
                  // PC's, so we omit undefined or "fake" absolute addresses.
                  // These fake absolute addresses occur in some older i386
                  // kernels to indicate they are vDSO symbols, not real
                  // functions in the kernel. We also omit symbols that have
                  if (GELF_ST_TYPE (sym.st_info) == STT_FUNC
                      && sym.st_shndx == SHN_ABS)
                    continue;
[...]

Do you happen to know which case the symbol you need hits?
An nm --format=sysv vmlinux | grep symbolname output would help.
Then we can change the filter to accept those.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10206

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.