gdb and binutils branch master updated. 12ab52e9772a9170018feb44de3ef217e051cc60

[palves at sourceware dot org]

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  12ab52e9772a9170018feb44de3ef217e051cc60 (commit)
      from  e3e3703534b6277b9d60441a9c828b7deadfe603 (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=12ab52e9772a9170018feb44de3ef217e051cc60

commit 12ab52e9772a9170018feb44de3ef217e051cc60
Author: Pedro Alves <palves@redhat.com>
Date:   Wed Feb 26 14:22:33 2014 +0000

    Multiple Ada task-specific breakpoints at the same address.
    
    With the test changed as in the patch, against current mainline, we get:
    
     (gdb) PASS: gdb.ada/tasks.exp: info tasks before inserting breakpoint
     break break_me task 1
     Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
     (gdb) PASS: gdb.ada/tasks.exp: break break_me task 1
     break break_me task 3
     Note: breakpoint 2 also set at pc 0x4030b0.
     Breakpoint 3 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
     (gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
     continue
     Continuing.
     [Switching to Thread 0x7ffff7dc7700 (LWP 27133)]
    
     Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
     27	      null;
     (gdb) FAIL: gdb.ada/tasks.exp: continue to breakpoint
     info tasks
        ID       TID P-ID Pri State                  Name
         1    63b010       48 Waiting on RV with 3   main_task
         2    63bd80    1  48 Accept or Select Term  task_list(1)
     *   3    63f510    1  48 Accepting RV with 1    task_list(2)
         4    642ca0    1  48 Accept or Select Term  task_list(3)
     (gdb) PASS: gdb.ada/tasks.exp: info tasks after hitting breakpoint
    
    The breakpoint that caused a stop is breakpoint 3, but GDB end up
    reporting (and running breakpoint commands of) "Breakpoint 2" instead.
    
    The issue is that the bpstat_check_breakpoint_conditions logic of
    "wrong thread" is missing the "wrong task" check.  This is usually
    harmless, because the thread hop code in infrun.c code that handles
    wrong-task-hitting-breakpoint does check for task-specific breakpoints
    (within breakpoint_thread_match):
    
          /* Check if a regular breakpoint has been hit before checking
             for a potential single step breakpoint.  Otherwise, GDB will
             not see this breakpoint hit when stepping onto breakpoints.  */
          if (regular_breakpoint_inserted_here_p (aspace, stop_pc))
    	{
    	  if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid))
    	    thread_hop_needed = 1;
    	}
    
    IOW, usually, when one only has a task specific breakpoint at a given
    address, things work correctly.  Put another task-specific or
    non-task-specific breakpoint there, and things break.
    
    A patch that eliminates the special thread hop code in infrun.c is
    what exposed this, as after that GDB solely relies on
    bpstat_check_breakpoint_conditions to know whether the right or wrong
    task hit a breakpoint.  IOW, given the latent bug, Ada task-specific
    breakpoints become non-task-specific, and that is caught by the
    testsuite, as:
    
     break break_me task 3
     Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
     (gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
     continue
     Continuing.
     [Switching to Thread 0x7ffff7fcb700 (LWP 17122)]
    
     Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
     27	      null;
     (gdb) PASS: gdb.ada/tasks.exp: continue to breakpoint
     info tasks
        ID       TID P-ID Pri State                  Name
         1    63b010       48 Waiting on RV with 2   main_task
     *   2    63bd80    1  48 Accepting RV with 1    task_list(1)
         3    63f510    1  48 Accept or Select Term  task_list(2)
         4    642ca0    1  48 Accept or Select Term  task_list(3)
     (gdb) FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint
    
    It was after seeing this that I thought of how to expose the bug with
    current mainline.
    
    Tested on x86_64 Fedora 17.
    
    gdb/
    2014-02-26  Pedro Alves  <palves@redhat.com>
    
    	* breakpoint.c (bpstat_check_breakpoint_conditions): Handle
    	task-specific breakpoints.
    
    gdb/testsuite/
    2014-02-26  Pedro Alves  <palves@redhat.com>
    
    	* gdb.ada/tasks.exp: Set a task-specific breakpoint at break_me
    	that won't ever trigger.  Make sure that GDB reports the correct
    	breakpoint that caused the stop.

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

Summary of changes:
 gdb/ChangeLog                   |    5 +++++
 gdb/breakpoint.c                |   10 ++++++----
 gdb/testsuite/ChangeLog         |    6 ++++++
 gdb/testsuite/gdb.ada/tasks.exp |   28 ++++++++++++++++++++++++----
 4 files changed, 41 insertions(+), 8 deletions(-)


hooks/post-receive
-- 
gdb and binutils