This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug corefiles/16834] New: arm_stub_unwinder blocks dwarf2 unwinders when mapped memory unavailable, but symbols are


https://sourceware.org/bugzilla/show_bug.cgi?id=16834

            Bug ID: 16834
           Summary: arm_stub_unwinder blocks dwarf2 unwinders when mapped
                    memory unavailable, but symbols are
           Product: gdb
           Version: 7.7
            Status: NEW
          Severity: normal
          Priority: P2
         Component: corefiles
          Assignee: unassigned at sourceware dot org
          Reporter: ingemara at opera dot com

When loading a core dump from an ARM platform, the following list is traversed
when choosing which frame unwinder to use (line numbers from the
gdb-7.7-release
tag):

arm-tdep.c:10332
  /* Add some default predicates.  */
  if (is_m)
    frame_unwind_append_unwinder (gdbarch, &arm_m_exception_unwind);
  frame_unwind_append_unwinder (gdbarch, &arm_stub_unwind);
  dwarf2_append_unwinders (gdbarch);
  frame_unwind_append_unwinder (gdbarch, &arm_exidx_unwind);
  frame_unwind_append_unwinder (gdbarch, &arm_prologue_unwind);

As described in https://sourceware.org/gdb/wiki/Internals%20Stack-Frames, when
gdb needs to unwind a frame, the first unwinder which has a sniffer returning 1
is used. Taking a look at arm_stub_unwind.sniffer
(arm_stub_unwind_sniffer(..)),
we'll see the following conditional:

arm-tdep.c:2909
  addr_in_block = get_frame_address_in_block (this_frame);
  if (in_plt_section (addr_in_block)
      /* We also use the stub winder if the target memory is unreadable
         to avoid having the prologue unwinder trying to read it.  */
      || target_read_memory (get_frame_pc (this_frame), dummy, 4) != 0)
    return 1;

  return 0;

Thus, if the program counter of the current frame points to memory which is not
readable, the stub unwinder is chosen to protect gdb from selecting the
prologue
unwinder (which would obviusly fail). Regularly, this isn't an issue in core
dumps, as all shared memory is usually included in the core file as well.
However, if it isn't, for instance due to size limitations, even though the
memory is available on-file as libfoo.so, it's not possible to add such a file
as a memory mapping in gdb.

A similar interface for symbol files are provided through add-symbol-file:

  add-symbol-file libfoo.so 0x12345678

However, even if such information is added, the stub unwinder is chosen
regardless. By swapping order of arm_stup_unwind and the dwarf unwinders set in
dwarf2_append_unwinders (allowing the dwar2 unwinders to have a crack at
unwinding the frame before the stub unwinder), the dwarf2 unwinder is chosen
instead, since the symbol data was added.

It should be possible, when examining a core file, to define mapped memory
regions similar to how add-symbol-file is used, but rather operating on memory
at a lower level, allowing the bypass of the arm stub unwinder. If such an
operation is available, feel free to close this bug and point me in the right
direction (I've tried finding it, trust me).

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]