This is the mail archive of the gdb-cvs@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]

gdb and binutils branch master updated. 94481b8c8f63a2a956d18ac1e6d6134c5334cb24


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  94481b8c8f63a2a956d18ac1e6d6134c5334cb24 (commit)
      from  67cf16836da7a65e6c5e08bfbc10a597f741845f (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=94481b8c8f63a2a956d18ac1e6d6134c5334cb24

commit 94481b8c8f63a2a956d18ac1e6d6134c5334cb24
Author: Joel Brobecker <brobecker@adacore.com>
Date:   Wed Nov 20 12:43:20 2013 -0500

    nameless LOAD_DLL_DEBUG_EVENT causes ntdll.dll to be missing
    
    We observed on Windows 2012 that we were unable to unwind past
    exception handlers. For instance, with any Ada program raising
    an exception that does not get handled:
    
        % gnatmake -g a -bargs -shared
        % gdb a
        (gdb) start
        (gdb) catch exception unhandled
        Catchpoint 2: unhandled Ada exceptions
        (gdb) c
        Catchpoint 2, unhandled CONSTRAINT_ERROR at <__gnat_unhandled_exception> (
            e=0x645ff820 <constraint_error>) at s-excdeb.adb:53
        53      s-excdeb.adb: No such file or directory.
    
    At this point, we can already see that something went wrong, since
    the frame selected by the debugger corresponds to a runtime function
    rather than the function in the user code that caused the exception
    to be raised (in our case procedure A).
    
    This is further confirmed by the fact that we are unable to unwind
    all the way to procedure A:
    
        (gdb) bt
        #0  <__gnat_unhandled_exception> (e=0x645ff820 <constraint_error>)
            at s-excdeb.adb:53
        #1  0x000000006444e9a3 in <__gnat_notify_unhandled_exception> (excep=0x284d2
    +0)
            at a-exextr.adb:144
        #2  0x00000000645f106a in __gnat_personality_imp ()
           from C:\[...]\libgnat-7.3.dll
        #3  0x000000006144d1b7 in _GCC_specific_handler (ms_exc=0x242fab0,
            this_frame=0x242fe60, ms_orig_context=0x242f5c0, ms_disp=0x242ef70,
            gcc_per=0x645f0960 <__gnat_personality_imp>)
            at ../../../src/libgcc/unwind-seh.c:289
        #4  0x00000000645f1211 in __gnat_personality_seh0 ()
           from C:\[...]\libgnat-7.3.dll
        #5  0x000007fad3879f4d in ?? ()
        Backtrace stopped: previous frame inner to this frame (corrupt stack?)
    
    It turns out that the unwinder has been doing its job flawlessly
    up until frame #5. The address in frame #5 is correct, but GDB
    is not able to associate it with any symbol or unwind record.
    
    And this is because this address is inside ntdll.dll, and when
    we received the LOAD_DLL_DEBUG_EVENT for that DLL, the system
    was not able to tell us the name of the library, thus causing us
    to silently ignoring the event. Because GDB does not know about
    ntdll.dll, it is unable to access the unwind information from it.
    And because the function at that address does not use a frame
    pointer, the unwinding becomes impossible.
    
    This patch helps recovering ntdll.dll at the end of the "run/attach"
    phase, simply by trying to locate that specific DLL again.
    
    In terms of our medium to long term planning, it seems to me that
    we should be able to simplify the code by ignoring LOAD_DLL_DEBUG_EVENT
    during the startup phase, and modify windows_ensure_ntdll_loaded
    to then detect and report all shared libraries after we've finished
    inferior creation.  But for a change just before 7.7 branch creation,
    I thought it was safest to just handle ntdll.dll specifically. This
    is less intrusive, and ntdll is the only DLL affected by the problem
    I know so far.
    
    gdb/ChangeLog:
    
    	* windows-nat.c (handle_load_dll): Add comments.
            (windows_ensure_ntdll_loaded): New function.
    	(do_initial_windows_stuff): Use windows_ensure_ntdll_loaded.
            Add FIXME comment.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog     |    7 ++++
 gdb/windows-nat.c |   86 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 93 insertions(+), 0 deletions(-)


hooks/post-receive
-- 
gdb and binutils


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