gdb-7.8 branching status (2014-06-04)

gdb-7.8 branching status (2014-06-04)

[Joel Brobecker]

Hello,

Quick update on where we are on branching the gdb-7.8 branch:

  . break-interp.exp/corefile.exp GDB SEGV
    I think Markus sent a patch, and Pedro mostly approved it
    https://www.sourceware.org/ml/gdb-patches/2014-06/msg00148.html

  . PR 16253-induced performance regression
    So far, I only heard from Doug who thinks the best option
    at this point is to temporarily revert the offending patch.
    It would be nice to hear from Keith as well, JIC.

  . Build failure with Python 2.4
    (caused by "Add xmethod support to the Python API")
    https://www.sourceware.org/ml/gdb-patches/2014-06/msg00169.html
    Shouldn't be a problem for the release, since we build without
    -Werror by default, but should not be hard to fix, and would be
    better to have.

  . I just noticed a regression with gdbserver on LynxOS.
    The testing came back just in the nick of time to identify
    the source of the regression:
        commit 802e8e6d8465a0d05803a987ba1bb3237fb2fb70
        [GDBserver] Make Zx/zx packet handling idempotent.
    I will more into it right away.

  . I also noticed what looks like some failures with gdbserver
    on Windows, but I haven't had time to look into this.
    I am hoping it's the same issue was on LynxOS.

I will create a PR(s) as soon as I know more about the issues I detected.

-- 
Joel

Re: gdb-7.8 branching status (2014-06-04)

[Pedro Alves]

On 06/04/2014 06:18 PM, Joel Brobecker wrote:

>   . I just noticed a regression with gdbserver on LynxOS.
>     The testing came back just in the nick of time to identify
>     the source of the regression:
>         commit 802e8e6d8465a0d05803a987ba1bb3237fb2fb70
>         [GDBserver] Make Zx/zx packet handling idempotent.
>     I will more into it right away.

Blasphemy!  :-P  Hopefully it'll be a simple issue, like, me
installing the new hooks incorrectly..

I also filed PRs for the gdbserver regressions I had mentioned before.

 [Bug go/17018] New: XFAIL: gdb.go/hello.exp: Starting string check
 https://sourceware.org/PR17018

 [Bug gdb/17019] New: gdb.base/restore.exp failures
 https://sourceware.org/PR17019

 [Bug gdb/17020] New: gdb.base/store.exp failures
 https://sourceware.org/PR17020

 [Bug gdb/17016] New: XFAIL: gdb.threads/dlopen-libpthread.exp: info probes all rtld rtld_map_complete
 https://sourceware.org/PR17016

 [Bug gdb/17015] New: gdb.trace/collection.exp failures
 https://sourceware.org/PR17015

 [Bug gdb/17014] New: gdb.trace/unavailable.exp failures
 https://sourceware.org/PR17014

Likely most of those are system/gcc related though.  I'm diffing
against a gdb.sum from a month ago, and I updated my Fedora in
the mean time...  Still, it's shame that all these are failing
on newer systems.

I'll run the testsuite on my current system against 7.7,
diff the result against mainline, and update the PRs with
what I find out.  If they fail on 7.7 as well, they're not
regressions, so can't be blockers.

-- 
Pedro Alves

Re: gdb-7.8 branching status (2014-06-04)

[Joel Brobecker]

> >   . I just noticed a regression with gdbserver on LynxOS.
> >     The testing came back just in the nick of time to identify
> >     the source of the regression:
> >         commit 802e8e6d8465a0d05803a987ba1bb3237fb2fb70
> >         [GDBserver] Make Zx/zx packet handling idempotent.
> >     I will more into it right away.
> 
> Blasphemy!  :-P  Hopefully it'll be a simple issue, like, me
> installing the new hooks incorrectly..

:-)

It looks like a call to a hook which is NULL (supports_z_point_type),
which probably shoots down my hope of the same issue affecting Windows
as well (there, the hook appears to be non-NULL).

I'm trying to see if I should define it for LynxOS or not, but
then we have the same issue with SPU, I think.

-- 
Joel

Re: gdb-7.8 branching status (2014-06-04)

[Pedro Alves]

On 06/04/2014 06:46 PM, Joel Brobecker wrote:

> It looks like a call to a hook which is NULL (supports_z_point_type),
> which probably shoots down my hope of the same issue affecting Windows
> as well (there, the hook appears to be non-NULL).

Ah, I guess you're seeing the crash in mem-break.c:

static int
z_type_supported (char z_type)
{
  return (z_type >= '0' && z_type <= '4'
	  && the_target->supports_z_point_type (z_type));
}

> 
> I'm trying to see if I should define it for LynxOS or not, but
> then we have the same issue with SPU, I think.

The function is a boolean, so assuming false if the
hook is NULL is fine:

  return (z_type >= '0' && z_type <= '4'
+	  && the_target->supports_z_point_type != NULL
	  && the_target->supports_z_point_type (z_type));

-- 
Pedro Alves

Re: gdb-7.8 branching status (2014-06-04)

[Pedro Alves]

On 06/04/2014 06:54 PM, Pedro Alves wrote:
> On 06/04/2014 06:46 PM, Joel Brobecker wrote:

>>
>> I'm trying to see if I should define it for LynxOS or not, but
>> then we have the same issue with SPU, I think.
> 
> The function is a boolean, so assuming false if the
> hook is NULL is fine:
> 
>   return (z_type >= '0' && z_type <= '4'
> +	  && the_target->supports_z_point_type != NULL
> 	  && the_target->supports_z_point_type (z_type));
> 

To clarify, neither LynxOS nor SPU install insert_point nor
remove_point hooks either, so the only thing the method
could do if we installed it would be return false.  But since
insert_point and remove_point can be NULL, it feels natural
to allow supports_z_point_type to be NULL too.

-- 
Pedro Alves

[RFA] gdbserver crash if the_target->supports_z_point_type is NULL

[Joel Brobecker]

Hello,

When debugging on LynxOS targets (and probably on SPU targets as well),
inserting a breakpoint and resuming the program's execution causes
GDBserver to crash.

The crash occurs while handling the Z0 packet sent by GDB to insert
our breakpoint, because z_type_supported calls
the_target->supports_z_point_type without checking that it is not NULL
This patch fixes the issue by making z_type_supported return false if
the_target->supports_z_point_type is NULL.

gdb/gdbserver/ChangeLog:

        PR server/17023
        * mem-break.c (z_type_supported): Return zero if
        THE_TARGET->SUPPORTS_Z_POINT_TYPE is NULL.

Tested on ppx-lynx5. I haven't tested on GNU/Linux, but I feel
sufficiently confident since supports_z_point_type is defined there,
and I am eager to take a look at Windows next. But I can do it
if people think it would be best.  OK to push?

Thanks,
-- 
Joel

---
 gdb/gdbserver/mem-break.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/gdb/gdbserver/mem-break.c b/gdb/gdbserver/mem-break.c
index 71876f7..2ce3ab2 100644
--- a/gdb/gdbserver/mem-break.c
+++ b/gdb/gdbserver/mem-break.c
@@ -897,6 +897,7 @@ static int
 z_type_supported (char z_type)
 {
   return (z_type >= '0' && z_type <= '4'
+	  && the_target->supports_z_point_type != NULL
 	  && the_target->supports_z_point_type (z_type));
 }
 
-- 
1.7.9.5

Re: [RFA] gdbserver crash if the_target->supports_z_point_type is NULL

[Pedro Alves]

On 06/04/2014 07:16 PM, Joel Brobecker wrote:
> Hello,
> 
> When debugging on LynxOS targets (and probably on SPU targets as well),
> inserting a breakpoint and resuming the program's execution causes
> GDBserver to crash.
> 
> The crash occurs while handling the Z0 packet sent by GDB to insert
> our breakpoint, because z_type_supported calls
> the_target->supports_z_point_type without checking that it is not NULL
> This patch fixes the issue by making z_type_supported return false if
> the_target->supports_z_point_type is NULL.
> 
> gdb/gdbserver/ChangeLog:
> 
>         PR server/17023
>         * mem-break.c (z_type_supported): Return zero if
>         THE_TARGET->SUPPORTS_Z_POINT_TYPE is NULL.
> 
> Tested on ppx-lynx5. I haven't tested on GNU/Linux, but I feel
> sufficiently confident since supports_z_point_type is defined there,
> and I am eager to take a look at Windows next. But I can do it
> if people think it would be best.  OK to push?

OK.

-- 
Pedro Alves

pushed: [RFA] gdbserver crash if the_target->supports_z_point_type is NULL

[Joel Brobecker]

> > gdb/gdbserver/ChangeLog:
> > 
> >         PR server/17023
> >         * mem-break.c (z_type_supported): Return zero if
> >         THE_TARGET->SUPPORTS_Z_POINT_TYPE is NULL.
> 
> OK.

Thanks, Pedro. Patch has been pushed.

-- 
Joel

Re: gdb-7.8 branching status (2014-06-04)

[Joel Brobecker]

> I also filed PRs for the gdbserver regressions I had mentioned before.
> 
>  [Bug go/17018] New: XFAIL: gdb.go/hello.exp: Starting string check
>  https://sourceware.org/PR17018
> 
>  [Bug gdb/17019] New: gdb.base/restore.exp failures
>  https://sourceware.org/PR17019
> 
>  [Bug gdb/17020] New: gdb.base/store.exp failures
>  https://sourceware.org/PR17020
> 
>  [Bug gdb/17016] New: XFAIL: gdb.threads/dlopen-libpthread.exp: info probes all rtld rtld_map_complete
>  https://sourceware.org/PR17016
> 
>  [Bug gdb/17015] New: gdb.trace/collection.exp failures
>  https://sourceware.org/PR17015
> 
>  [Bug gdb/17014] New: gdb.trace/unavailable.exp failures
>  https://sourceware.org/PR17014
> 
> Likely most of those are system/gcc related though.  I'm diffing
> against a gdb.sum from a month ago, and I updated my Fedora in
> the mean time...  Still, it's shame that all these are failing
> on newer systems.
> 
> I'll run the testsuite on my current system against 7.7,
> diff the result against mainline, and update the PRs with
> what I find out.  If they fail on 7.7 as well, they're not
> regressions, so can't be blockers.

Thanks for doing that, Pedro. Let us know when you have the results,
so we know whether we're in the clear or not...

-- 
Joel

Re: gdb-7.8 branching status (2014-06-04)

[Pedro Alves]

On 06/04/2014 07:20 PM, Joel Brobecker wrote:
>> I also filed PRs for the gdbserver regressions I had mentioned before.
>>
>>  [Bug go/17018] New: XFAIL: gdb.go/hello.exp: Starting string check
>>  https://sourceware.org/PR17018
>>
>>  [Bug gdb/17019] New: gdb.base/restore.exp failures
>>  https://sourceware.org/PR17019
>>
>>  [Bug gdb/17020] New: gdb.base/store.exp failures
>>  https://sourceware.org/PR17020
>>
>>  [Bug gdb/17016] New: XFAIL: gdb.threads/dlopen-libpthread.exp: info probes all rtld rtld_map_complete
>>  https://sourceware.org/PR17016
>>
>>  [Bug gdb/17015] New: gdb.trace/collection.exp failures
>>  https://sourceware.org/PR17015
>>
>>  [Bug gdb/17014] New: gdb.trace/unavailable.exp failures
>>  https://sourceware.org/PR17014
>>
>> Likely most of those are system/gcc related though.  I'm diffing
>> against a gdb.sum from a month ago, and I updated my Fedora in
>> the mean time...  Still, it's shame that all these are failing
>> on newer systems.
>>
>> I'll run the testsuite on my current system against 7.7,
>> diff the result against mainline, and update the PRs with
>> what I find out.  If they fail on 7.7 as well, they're not
>> regressions, so can't be blockers.
> 
> Thanks for doing that, Pedro. Let us know when you have the results,
> so we know whether we're in the clear or not...

I've done this now.  I had to rerun all testing in non-parallel mode
to get good diffs...

The "good" news, I get all those FAILs with 7.7 too, so not
regressions.

Apart from the break-interp-exp crashes Markus has a fix for, and
a few PASS -> XFAIL that are marked as GCC bugs, I saw this
with both native and gdbserver:

 -PASS: gdb.cp/koenig.exp: p entry (c)
 +FAIL: gdb.cp/koenig.exp: p entry (c)

This is:

 Regression for gdb.cp/koenig.exp: p entry (c) [Re: [RFA] Fix c++/16253 (tag/variable name collision)]
 https://sourceware.org/ml/gdb-patches/2014-04/msg00374.html

I don't know the current status of that one.  Keith?

and this one on native:

-PASS: gdb.base/pie-execl.exp: continue
-PASS: gdb.base/pie-execl.exp: pie_execl_marker address second
-PASS: gdb.base/pie-execl.exp: pie_execl_marker address has changed
+ERROR: Process no longer exists
+UNRESOLVED: gdb.base/pie-execl.exp: continue

I looked at the backtrace and it's the same as with the
break-interp.exp crashes, so it'll likely be fixed with
Markus' patch.

-- 
Pedro Alves

Re: gdb-7.8 branching status (2014-06-04)

[Keith Seitz]

On 06/05/2014 06:58 AM, Pedro Alves wrote:
> Apart from the break-interp-exp crashes Markus has a fix for, and
> a few PASS -> XFAIL that are marked as GCC bugs, I saw this
> with both native and gdbserver:
>
>   -PASS: gdb.cp/koenig.exp: p entry (c)
>   +FAIL: gdb.cp/koenig.exp: p entry (c)
>
> This is:
>
>   Regression for gdb.cp/koenig.exp: p entry (c) [Re: [RFA] Fix c++/16253 (tag/variable name collision)]
>   https://sourceware.org/ml/gdb-patches/2014-04/msg00374.html
>
> I don't know the current status of that one.  Keith?

I'm working on that one. It's your call, but I hesitate to block a 
release on this. The failure mode is induced by having glibc debuginfo, 
which exports a symbol of the same name ("entry"). The actual feature 
being tested still works, though.

Keith

Re: gdb-7.8 branching status (2014-06-04)

[Keith Seitz]

On 06/05/2014 07:14 AM, Keith Seitz wrote:
> On 06/05/2014 06:58 AM, Pedro Alves wrote:
>> Apart from the break-interp-exp crashes Markus has a fix for, and
>> a few PASS -> XFAIL that are marked as GCC bugs, I saw this
>> with both native and gdbserver:
>>
>>   -PASS: gdb.cp/koenig.exp: p entry (c)
>>   +FAIL: gdb.cp/koenig.exp: p entry (c)
>>
>> This is:
>>
>>   Regression for gdb.cp/koenig.exp: p entry (c) [Re: [RFA] Fix
>> c++/16253 (tag/variable name collision)]
>>   https://sourceware.org/ml/gdb-patches/2014-04/msg00374.html
>>
>> I don't know the current status of that one.  Keith?
>
> I'm working on that one. It's your call, but I hesitate to block a
> release on this. The failure mode is induced by having glibc debuginfo,
> which exports a symbol of the same name ("entry"). The actual feature
> being tested still works, though.

I forgot to mention. Since we are reverting the patch for 16253, this 
regression should go away, too.

https://sourceware.org/ml/gdb-patches/2014-04/msg00374.html

Keith

Re: gdb-7.8 branching status (2014-06-04)

[Joel Brobecker]

Thanks again for the update, Pedro.

So we only have one new potential issue:

> This is:
> 
>  Regression for gdb.cp/koenig.exp: p entry (c) [Re: [RFA] Fix c++/16253 (tag/variable name collision)]
>  https://sourceware.org/ml/gdb-patches/2014-04/msg00374.html
> 
> I don't know the current status of that one.  Keith?

-- 
Joel

Re: gdb-7.8 branching status (2014-06-04)

[Keith Seitz]

On 06/04/2014 10:18 AM, Joel Brobecker wrote:
>    . PR 16253-induced performance regression
>      So far, I only heard from Doug who thinks the best option
>      at this point is to temporarily revert the offending patch.
>      It would be nice to hear from Keith as well, JIC.

I agree. In fact, I think I mentioned this several days ago on IRC. The 
bug isn't particularly nasty/common/important to block a release. Users 
have had to deal with it for some time, a little while longer won't hurt.

I can provide a patch to revert it from either HEAD or the 7.8 branch. 
Just let me know which you'd prefer. [That is, if Doug hasn't already 
done so or is working on it, but I know he's very, very busy at the moment.]

Keith

Re: gdb-7.8 branching status (2014-06-04)

[Joel Brobecker]

> >   . PR 16253-induced performance regression
> >     So far, I only heard from Doug who thinks the best option
> >     at this point is to temporarily revert the offending patch.
> >     It would be nice to hear from Keith as well, JIC.
> 
> I agree. In fact, I think I mentioned this several days ago on IRC.
> The bug isn't particularly nasty/common/important to block a
> release. Users have had to deal with it for some time, a little
> while longer won't hurt.
> 
> I can provide a patch to revert it from either HEAD or the 7.8
> branch. Just let me know which you'd prefer. [That is, if Doug
> hasn't already done so or is working on it, but I know he's very,
> very busy at the moment.]

Thanks, Keith. Doug was only suggesting the revert, so did not offer
to do the revert. Would you mind doing it?

Thanks again,
-- 
Joel

Re: gdb-7.8 branching status (2014-06-04)

[Doug Evans]

On Wed, Jun 4, 2014 at 3:23 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> >   . PR 16253-induced performance regression
>> >     So far, I only heard from Doug who thinks the best option
>> >     at this point is to temporarily revert the offending patch.
>> >     It would be nice to hear from Keith as well, JIC.
>>
>> I agree. In fact, I think I mentioned this several days ago on IRC.
>> The bug isn't particularly nasty/common/important to block a
>> release. Users have had to deal with it for some time, a little
>> while longer won't hurt.
>>
>> I can provide a patch to revert it from either HEAD or the 7.8
>> branch. Just let me know which you'd prefer. [That is, if Doug
>> hasn't already done so or is working on it, but I know he's very,
>> very busy at the moment.]
>
> Thanks, Keith. Doug was only suggesting the revert, so did not offer
> to do the revert. Would you mind doing it?

That'd be awesome.  Thanks!

Re: gdb-7.8 branching status (2014-06-04)

[Joel Brobecker]

>   . I also noticed what looks like some failures with gdbserver
>     on Windows, but I haven't had time to look into this.
>     I am hoping it's the same issue was on LynxOS.

I can now say with relative certainty that it isn't the same issue.
It looks related to the fact that target-async is enabled by default.
I'm still gathering evidence, but the the reproducer is a little racy;
it doesn't always fail, and doesn't always fail at the same point :-(.

Sadly, I also noticed that the "maint set target-async" command is
missing on Windows hosts :-(. So that made testing my theory a little
more difficult, and added yet more work before we can cut the 7.8
branch. But in any case, manually setting target_async_permitted
and target_async_permitted_1 (I am paranoid) to 0 allowed me to
pass my test 20 times in a row, as opposed to having it fail roughly
12-15 times.

I will create PRs and investigate further tomorrow.

-- 
Joel

Re: gdb-7.8 branching status (2014-06-04)

[Joel Brobecker]

> >   . I also noticed what looks like some failures with gdbserver
> >     on Windows, but I haven't had time to look into this.
> >     I am hoping it's the same issue was on LynxOS.
> 
> I can now say with relative certainty that it isn't the same issue.
> It looks related to the fact that target-async is enabled by default.
> I'm still gathering evidence, but the the reproducer is a little racy;
> it doesn't always fail, and doesn't always fail at the same point :-(.
> 
> Sadly, I also noticed that the "maint set target-async" command is
> missing on Windows hosts :-(. So that made testing my theory a little
> more difficult, and added yet more work before we can cut the 7.8
> branch. But in any case, manually setting target_async_permitted
> and target_async_permitted_1 (I am paranoid) to 0 allowed me to
> pass my test 20 times in a row, as opposed to having it fail roughly
> 12-15 times.

Hmmmpf, really elusive one to track down as the problem becomes more
and more elusive as you add traces. It looks like communication issue,
although I don't have all the details yet. I created a PR:

    GDB+GDBserver hangs on Windows waiting for stop event since target-async
    on by default
    https://sourceware.org/bugzilla/show_bug.cgi?id=17028

I mentioned target-async in the subject since this seems to be
the trigger that allowed the problem to show up, but so far,
I don't see why this would make a difference.

-- 
Joel

Re: gdb-7.8 branching status (2014-06-04)

[Pedro Alves]

On 06/05/2014 10:03 PM, Joel Brobecker wrote:

> Hmmmpf, really elusive one to track down as the problem becomes more
> and more elusive as you add traces. It looks like communication issue,
> although I don't have all the details yet. I created a PR:
> 
>     GDB+GDBserver hangs on Windows waiting for stop event since target-async
>     on by default
>     https://sourceware.org/bugzilla/show_bug.cgi?id=17028
> 
> I mentioned target-async in the subject since this seems to be
> the trigger that allowed the problem to show up, but so far,
> I don't see why this would make a difference.

Thanks Joel.  As I said on the PR, I'll try to debug this
too, right after I send out a fix for another issue I'm
addressing atm.

-- 
Pedro Alves

Re: gdb-7.8 branching status (2014-06-04)

[Joel Brobecker]

> Sadly, I also noticed that the "maint set target-async" command is
> missing on Windows hosts :-(. So that made testing my theory a little
> more difficult, and added yet more work before we can cut the 7.8
> branch.

FTR: I think I was using a version that was too old, and so this command
was probably not implemented yet. When I tried investigating this issue,
the command was there....

-- 
Joel

Re: gdb-7.8 branching status (2014-06-04)

[Yao Qi]

On 06/05/2014 01:18 AM, Joel Brobecker wrote:
> Quick update on where we are on branching the gdb-7.8 branch:

I tested gdb head on both arm-none-eabi and arm-none-linux-gnueabi
yesterday.  Except gdb.cp/koenig.exp fail, there is no regression.
However, there are some new fails (compared with 7.7.1), but none of
them are blockers, IMO.

New FAIL: default/gdb.sum:gdb.base/hbreak-unmapped.exp: hbreak *0
New FAIL: default/gdb.sum:gdb.base/hbreak-unmapped.exp: info break shows
hw breakpoint

bare metal target isn't consider in this case, and I've proposed here
https://sourceware.org/ml/gdb-patches/2014-06/msg00074.html

FAIL: gdb.base/async.exp: finish&
FAIL: gdb.base/async.exp: nexti&
FAIL: gdb.threads/sigstep-threads.exp: continue
FAIL: gdb.threads/sigstep-threads.exp: step 2
FAIL: gdb.stabs/gdb11479.exp: sizeof (*e) in test forced_stabs
FAIL: gdb.stabs/gdb11479.exp: sizeof (*e) in test2 forced_stabs
FAIL: gdb.base/jit.exp: PIE: one_jit_test-1: continue to breakpoint:
break here 2 (the program exited)

I'll take a look.

-- 
Yao (齐尧)

Re: gdb-7.8 branching status (2014-06-04)

[Pedro Alves]

On 06/05/2014 03:38 PM, Yao Qi wrote:
> On 06/05/2014 01:18 AM, Joel Brobecker wrote:
>> Quick update on where we are on branching the gdb-7.8 branch:
> 
> I tested gdb head on both arm-none-eabi and arm-none-linux-gnueabi
> yesterday.  Except gdb.cp/koenig.exp fail, there is no regression.
> However, there are some new fails (compared with 7.7.1), but none of
> them are blockers, IMO.
> 
> New FAIL: default/gdb.sum:gdb.base/hbreak-unmapped.exp: hbreak *0
> New FAIL: default/gdb.sum:gdb.base/hbreak-unmapped.exp: info break shows
> hw breakpoint
> 
> bare metal target isn't consider in this case, and I've proposed here
> https://sourceware.org/ml/gdb-patches/2014-06/msg00074.html

TBC, this is just a test issue, not a GDB bug.  I've followed up now.

> 
> FAIL: gdb.base/async.exp: finish&
> FAIL: gdb.base/async.exp: nexti&
> FAIL: gdb.threads/sigstep-threads.exp: continue
> FAIL: gdb.threads/sigstep-threads.exp: step 2
> FAIL: gdb.stabs/gdb11479.exp: sizeof (*e) in test forced_stabs
> FAIL: gdb.stabs/gdb11479.exp: sizeof (*e) in test2 forced_stabs
> FAIL: gdb.base/jit.exp: PIE: one_jit_test-1: continue to breakpoint:
> break here 2 (the program exited)

None of these ring a bell to me atm.

> I'll take a look.

Thanks.

-- 
Pedro Alves

Re: gdb-7.8 branching status (2014-06-04)

[Joel Brobecker]

> I tested gdb head on both arm-none-eabi and arm-none-linux-gnueabi
> yesterday.  Except gdb.cp/koenig.exp fail, there is no regression.
> However, there are some new fails (compared with 7.7.1), but none of
> them are blockers, IMO.
> 
> New FAIL: default/gdb.sum:gdb.base/hbreak-unmapped.exp: hbreak *0
> New FAIL: default/gdb.sum:gdb.base/hbreak-unmapped.exp: info break shows
> hw breakpoint
> 
> bare metal target isn't consider in this case, and I've proposed here
> https://sourceware.org/ml/gdb-patches/2014-06/msg00074.html
> 
> FAIL: gdb.base/async.exp: finish&
> FAIL: gdb.base/async.exp: nexti&
> FAIL: gdb.threads/sigstep-threads.exp: continue
> FAIL: gdb.threads/sigstep-threads.exp: step 2
> FAIL: gdb.stabs/gdb11479.exp: sizeof (*e) in test forced_stabs
> FAIL: gdb.stabs/gdb11479.exp: sizeof (*e) in test2 forced_stabs
> FAIL: gdb.base/jit.exp: PIE: one_jit_test-1: continue to breakpoint:
> break here 2 (the program exited)
> 
> I'll take a look.

Thanks for the update as well.

-- 
Joel