[llvm-commits] [PATCH] [asan] Always use file+offset in symbolizer

Kostya Serebryany kcc at google.com
Thu Oct 18 00:26:08 PDT 2012


unfortunately, this is not as simple as this.
We have Darwin and Android, and we also have the llvm-based symbolizer
(which will eventually replace asan_symbolize.py).
Besides, I still want the offsets to be meaningful for addr2line/atos.
Hopefully, you can resolve this with Alexey.
We may of course put the sanitizer_procmaps.h change under a flag, if the
fix takes too long.

--kcc




On Thu, Oct 18, 2012 at 9:21 AM, NAKAMURA Takumi <geek4civic at gmail.com>wrote:

> compiler-rt/asan: MemoryMappingLayout: Always emit the offset in
> corresponding module.
>
> asan_symbolize.py: Use offset with (rounded to page_size) base address,
> with objdump(1).
>
> FIXME: I have not tested on darwin.
>
> http://llvm-reviews.chandlerc.com/D66
>
> Files:
>   compiler-rt/lib/asan/scripts/asan_symbolize.py
>   compiler-rt/lib/sanitizer_common/sanitizer_procmaps.h
>
> Index: compiler-rt/lib/asan/scripts/asan_symbolize.py
> ===================================================================
> --- compiler-rt/lib/asan/scripts/asan_symbolize.py
> +++ compiler-rt/lib/asan/scripts/asan_symbolize.py
> @@ -109,6 +109,28 @@
>      super(Addr2LineSymbolizer, self).__init__()
>      self.binary = binary
>      self.pipe = self.open_addr2line()
> +    self.base = self.get_base_addr()
> +
> +  def get_base_addr(self):
> +    p = subprocess.Popen(
> +      ['objdump', '-h', self.binary],
> +      stdin=None,
> +      stdout=subprocess.PIPE
> +      )
> +    # Capture the first VMA with 'LOAD'.
> +    a =
> re.compile(r'\s+(?P<Size>[0-9a-f]{8,})\s+(?P<VMA>[0-9a-f]{8,})\s+(?P<LMA>[0-9a-f]{8,})\s+(?P<offset>[0-9a-f]{8,})\s+')
> +    b = re.compile(r'\WLOAD\W')
> +    base = '';
> +    vma = ''
> +    for line in p.stdout:
> +      ma = a.search(line)
> +      if ma:
> +        vma = ma.group('VMA')
> +      elif base == '' and vma != '' and b.search(line):
> +        base = vma
> +
> +    p.wait()
> +    return int(base, 16) & -4096
>
>    def open_addr2line(self):
>      cmd = ['addr2line', '-f', '-e', self.binary]
> @@ -122,6 +144,7 @@
>      if self.binary != binary:
>        return None
>      try:
> +      offset = "0x%x" % (self.base + int(offset, 16))
>        print >> self.pipe.stdin, offset
>        function_name = self.pipe.stdout.readline().rstrip()
>        file_name = self.pipe.stdout.readline().rstrip()
> Index: compiler-rt/lib/sanitizer_common/sanitizer_procmaps.h
> ===================================================================
> --- compiler-rt/lib/sanitizer_common/sanitizer_procmaps.h
> +++ compiler-rt/lib/sanitizer_common/sanitizer_procmaps.h
> @@ -52,18 +52,8 @@
>      for (int i = 0; Next(&start, &end, &file_offset, filename,
> filename_size);
>           i++) {
>        if (addr >= start && addr < end) {
> -        // Don't subtract 'start' for the first entry:
> -        // * If a binary is compiled w/o -pie, then the first entry in
> -        //   process maps is likely the binary itself (all dynamic libs
> -        //   are mapped higher in address space). For such a binary,
> -        //   instruction offset in binary coincides with the actual
> -        //   instruction address in virtual memory (as code section
> -        //   is mapped to a fixed memory range).
> -        // * If a binary is compiled with -pie, all the modules are
> -        //   mapped high at address space (in particular, higher than
> -        //   shadow memory of the tool), so the module can't be the
> -        //   first entry.
> -        *offset = (addr - (i ? start : 0)) + file_offset;
> +       // FIXME: file_offset doesn't make sense if it is not zero.
> +        *offset = (addr - start) + file_offset;
>          return true;
>        }
>      }
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121018/b3a0ae95/attachment.html>


More information about the llvm-commits mailing list