* GDB 8.2 branch 2018-06-22 Update @ 2018-06-22 14:05 Joel Brobecker 2018-06-22 14:10 ` Simon Marchi ` (5 more replies) 0 siblings, 6 replies; 9+ messages in thread From: Joel Brobecker @ 2018-06-22 14:05 UTC (permalink / raw) To: gdb-patches Hi everyone, Can we do a quick status update on the branch? Below are items that were discussed previously. For those items that are still in progress, can you tell us whether or not you think you'll be able to finish it by end of this month? Note that, for practical reasons, the window for branching is either end of this month, or end of July. As far as I know, the following items are now complete: * (AlanH) gdb/gdbserver support for aarch64 SVE Looks like the code is now in? :-) [v3] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00400.html [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00145.html * (AndrewB) gdb: Don't drop SIGSTOP during stop_all_threads Latest update: Reviewed and mostly OK'ed (minor comments) Waiting for next version of the patch. https://www.sourceware.org/ml/gdb-patches/2018-06/msg00284.html The following items are still in progress: * (PhilippeW) Implement 'frame apply COMMAND', enhance 'thread apply COMMAND' It looks like a review was done around Jun 12-15, and some discussions, but no v3 yet. [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00118.html * (SergioDJ) Implement IPv6 support for GDB/gdbserver From what I can tell, a v2 was sent, and a review done just a couple of days ago. Is that accurate? [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00384.html [v1] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00238.html I will add the following issue I discovered to the list as well: * (JoelB) SEGV on x86_64-windows due to fs_base/gs_base Not necessarily entirely crippling, but crashes GDB as soon as we make it try to access the fs_base/gs_base registers. For instance: "info reg", or inferior function call (presuming that print $fs_base/print $gs_base is unlikely) I have a patch that I will share momentarily. I think it's simple-enough that it should be in by end of month. Anything else? Thank you! -- Joel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.2 branch 2018-06-22 Update 2018-06-22 14:05 GDB 8.2 branch 2018-06-22 Update Joel Brobecker @ 2018-06-22 14:10 ` Simon Marchi 2018-06-22 14:13 ` Joel Brobecker ` (4 subsequent siblings) 5 siblings, 0 replies; 9+ messages in thread From: Simon Marchi @ 2018-06-22 14:10 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches On 2018-06-22 10:05, Joel Brobecker wrote: > Hi everyone, > > Can we do a quick status update on the branch? Below are items that > were discussed previously. For those items that are still in progress, > can you tell us whether or not you think you'll be able to finish it > by end of this month? > > Note that, for practical reasons, the window for branching is either > end of this month, or end of July. > > As far as I know, the following items are now complete: > > * (AlanH) gdb/gdbserver support for aarch64 SVE > Looks like the code is now in? :-) > > [v3] > https://www.sourceware.org/ml/gdb-patches/2018-06/msg00400.html > [v2] > https://www.sourceware.org/ml/gdb-patches/2018-06/msg00145.html Yes I think this is done. > * (AndrewB) gdb: Don't drop SIGSTOP during stop_all_threads > Latest update: Reviewed and mostly OK'ed (minor comments) > Waiting for next version of the patch. > https://www.sourceware.org/ml/gdb-patches/2018-06/msg00284.html This looks like it's in too. Simon ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.2 branch 2018-06-22 Update 2018-06-22 14:05 GDB 8.2 branch 2018-06-22 Update Joel Brobecker 2018-06-22 14:10 ` Simon Marchi @ 2018-06-22 14:13 ` Joel Brobecker 2018-06-22 15:40 ` Alan Hayward ` (3 subsequent siblings) 5 siblings, 0 replies; 9+ messages in thread From: Joel Brobecker @ 2018-06-22 14:13 UTC (permalink / raw) To: gdb-patches > Can we do a quick status update on the branch? Below are items that > were discussed previously. For those items that are still in progress, > can you tell us whether or not you think you'll be able to finish it > by end of this month? I forgot to add the items that Tom mentioned -- sorry Tom! * (volunteer? else TomT) PR breakpoints/23300 `commands` does not work correctly if abbreviated to `comm` Suspected regression. * (???) PR mi/23312 MI producing invalid records following redirection (m_suppress_field_separator) My understanding from Tom's message was that it was perhaps a regression, but looking at the report, it seems to indicate that 7.12 is affected too? -- Joel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.2 branch 2018-06-22 Update 2018-06-22 14:05 GDB 8.2 branch 2018-06-22 Update Joel Brobecker 2018-06-22 14:10 ` Simon Marchi 2018-06-22 14:13 ` Joel Brobecker @ 2018-06-22 15:40 ` Alan Hayward 2018-06-22 16:54 ` Sergio Durigan Junior ` (2 subsequent siblings) 5 siblings, 0 replies; 9+ messages in thread From: Alan Hayward @ 2018-06-22 15:40 UTC (permalink / raw) To: Joel Brobecker; +Cc: GDB Patches, nd > > On 22 Jun 2018, at 15:05, Joel Brobecker <brobecker@adacore.com> wrote: > > Hi everyone, > > Can we do a quick status update on the branch? Below are items that > were discussed previously. For those items that are still in progress, > can you tell us whether or not you think you'll be able to finish it > by end of this month? > > Note that, for practical reasons, the window for branching is either > end of this month, or end of July. > > As far as I know, the following items are now complete: > > * (AlanH) gdb/gdbserver support for aarch64 SVE > Looks like the code is now in? :-) > > [v3] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00400.html > [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00145.html > Yes, all my SVE work is in now (Only just - I committed the core file patch about two minutes ago!). Happy for the branch to go ahead whenever. I’m going to see if I can get my full SVE core support patch in too. However - please don’t delay the branch for it. I had it as a stretch goal, and if it makes it then great, if not it can wait. I’m still working on it, with a few bits yet to figure out. Alan. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.2 branch 2018-06-22 Update 2018-06-22 14:05 GDB 8.2 branch 2018-06-22 Update Joel Brobecker ` (2 preceding siblings ...) 2018-06-22 15:40 ` Alan Hayward @ 2018-06-22 16:54 ` Sergio Durigan Junior 2018-06-22 18:22 ` Joel Brobecker 2018-06-23 15:17 ` Philippe Waroquiers 2018-06-25 21:26 ` Pedro Franco de Carvalho 5 siblings, 1 reply; 9+ messages in thread From: Sergio Durigan Junior @ 2018-06-22 16:54 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches On Friday, June 22 2018, Joel Brobecker wrote: > Hi everyone, Hey Joel, > * (SergioDJ) Implement IPv6 support for GDB/gdbserver > > From what I can tell, a v2 was sent, and a review done just > a couple of days ago. Is that accurate? > > [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00384.html > [v1] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00238.html Yes, that is accurate. I'm now working on addressing a few aspects of the review, but it is still a bit unclear to me whether my new approach will be accepted or whether Pedro's suggested approach will work without problems. I'm doing some testing to determine what to do next. I'd like to know: if, for some reason, I'm unable to get this patch accepted until, say, next Thursday (June 28th), would it be OK to remove it from the list of blockers, and to backport it to the branch later? I'm asking because I don't want to be the one blocking the branching from happening, since the IPv6 feature is not a major regression/problem to be fixed anyway. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.2 branch 2018-06-22 Update 2018-06-22 16:54 ` Sergio Durigan Junior @ 2018-06-22 18:22 ` Joel Brobecker 2018-06-22 20:41 ` Sergio Durigan Junior 0 siblings, 1 reply; 9+ messages in thread From: Joel Brobecker @ 2018-06-22 18:22 UTC (permalink / raw) To: Sergio Durigan Junior; +Cc: gdb-patches Hi Sergio, > > * (SergioDJ) Implement IPv6 support for GDB/gdbserver > > > > From what I can tell, a v2 was sent, and a review done just > > a couple of days ago. Is that accurate? > > > > [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00384.html > > [v1] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00238.html > > Yes, that is accurate. I'm now working on addressing a few aspects of > the review, but it is still a bit unclear to me whether my new approach > will be accepted or whether Pedro's suggested approach will work without > problems. I'm doing some testing to determine what to do next. Thanks for the update. > I'd like to know: if, for some reason, I'm unable to get this patch > accepted until, say, next Thursday (June 28th), would it be OK to remove > it from the list of blockers, and to backport it to the branch later? > I'm asking because I don't want to be the one blocking the branching > from happening, since the IPv6 feature is not a major regression/problem > to be fixed anyway. It depends on how intrusive the patch is, so it's a judgement call. For patches that are really obviously safe, or for which we can say that they cannot affect anything but themselves, the decision is fairly easy. For other patches, we need to weigh the benefits vs the risk we are taking. One thing we could be doing is cut the branch, but then wait for the branch to contain the changes we want before we create the first pre-release. The pre-release tarballs are our last change for field testing before we issue the first release, and in the case of a riskier than usual patch, it can be one way to compromise. We've only done it once or twice, if memory serves, and the context was that there was a difficult bug deemed critical that needed time to be fixed. Rather than holding people's changes for master up while we spent time fixing master, we just branched, knowing that we would have to backport the fix before we could generate the first pre-release. Who decides? I tend to defer to the maintainers who approved the patch for master. But if, for some reason, the maintainer doesn't feel like they can decide on their own, I am always happy to take a look and provide my opinion on the matter -- it is just sometimes a bit more difficult for me to make a fair assessment, not being entirely familiar with the patch. Scanning through v2 of your patch, my first reaction is that it seems a bit risky to be backporting this to the branch, as it touches the IPv4 layer quite a bit; it might be a lot of mechanical changes, but what it shows is that it needs a careful analysis of the risk we are taking. Having reviewed the patches in more details already, Pedro might be better placed to let you know the changes of getting it in after the branch. You might also want to think about this another way: If you rush your changes now and then we discover a major and difficult-to-fix bug, it's less pressure to have to fix it on master, than it is to have to do an emergency fix on the branch, possibly followed by an emergency release... I say this not to discourage people, but to make sure that the extra motivation of making a release doesn't turn into an unnecessary constraint. -- Joel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.2 branch 2018-06-22 Update 2018-06-22 18:22 ` Joel Brobecker @ 2018-06-22 20:41 ` Sergio Durigan Junior 0 siblings, 0 replies; 9+ messages in thread From: Sergio Durigan Junior @ 2018-06-22 20:41 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches On Friday, June 22 2018, Joel Brobecker wrote: >> I'd like to know: if, for some reason, I'm unable to get this patch >> accepted until, say, next Thursday (June 28th), would it be OK to remove >> it from the list of blockers, and to backport it to the branch later? >> I'm asking because I don't want to be the one blocking the branching >> from happening, since the IPv6 feature is not a major regression/problem >> to be fixed anyway. > > It depends on how intrusive the patch is, so it's a judgement call. > For patches that are really obviously safe, or for which we can say > that they cannot affect anything but themselves, the decision is > fairly easy. For other patches, we need to weigh the benefits vs > the risk we are taking. > > One thing we could be doing is cut the branch, but then wait for > the branch to contain the changes we want before we create the first > pre-release. The pre-release tarballs are our last change for field > testing before we issue the first release, and in the case of a riskier > than usual patch, it can be one way to compromise. We've only done it > once or twice, if memory serves, and the context was that there was > a difficult bug deemed critical that needed time to be fixed. Rather > than holding people's changes for master up while we spent time fixing > master, we just branched, knowing that we would have to backport the fix > before we could generate the first pre-release. > > Who decides? I tend to defer to the maintainers who approved the patch > for master. But if, for some reason, the maintainer doesn't feel like > they can decide on their own, I am always happy to take a look and > provide my opinion on the matter -- it is just sometimes a bit more > difficult for me to make a fair assessment, not being entirely > familiar with the patch. > > Scanning through v2 of your patch, my first reaction is that it seems > a bit risky to be backporting this to the branch, as it touches the > IPv4 layer quite a bit; it might be a lot of mechanical changes, but > what it shows is that it needs a careful analysis of the risk we are > taking. Having reviewed the patches in more details already, Pedro > might be better placed to let you know the changes of getting it in > after the branch. Thanks for the throrough explanation, it's always good to understand more about the whole process. I agree with you: the patch is a bit risky, indeed. Even though I'm trying to extend the existing tests and make sure that it works as it should, there's always the possibility of making a mistake, especially if we rush things. > You might also want to think about this another way: If you rush > your changes now and then we discover a major and difficult-to-fix bug, > it's less pressure to have to fix it on master, than it is to have > to do an emergency fix on the branch, possibly followed by an emergency > release... I say this not to discourage people, but to make sure that > the extra motivation of making a release doesn't turn into an unnecessary > constraint. You're absolutely right. I've been thinking about that myself, and that's why I decided to send the e-mail and ask more details about the process of backporting. Curiously, we at Red Hat have had to discuss a very similar situation involving this same patch, and we also decided to postpone including it in a next RHEL GDB release for the same reason. Having said all that, I would like to request the removal of the IPv6 patch from the list of blocking features for the branch. I think it's better for Pedro as well, because this way he doesn't have to try to review things like crazy before next weekend. Thanks a lot, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.2 branch 2018-06-22 Update 2018-06-22 14:05 GDB 8.2 branch 2018-06-22 Update Joel Brobecker ` (3 preceding siblings ...) 2018-06-22 16:54 ` Sergio Durigan Junior @ 2018-06-23 15:17 ` Philippe Waroquiers 2018-06-25 21:26 ` Pedro Franco de Carvalho 5 siblings, 0 replies; 9+ messages in thread From: Philippe Waroquiers @ 2018-06-23 15:17 UTC (permalink / raw) To: Joel Brobecker, gdb-patches On Fri, 2018-06-22 at 10:05 -0400, Joel Brobecker wrote: > The following items are still in progress: > > * (PhilippeW) Implement 'frame apply COMMAND', enhance 'thread apply COMMAND' > > It looks like a review was done around Jun 12-15, and some > discussions, but no v3 yet. > > [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00118.html Hello Joel, I could not work earlier on the comments, the last 2 weeks were difficult for me. I am busy working on v3, I should be able to submit a new version in the next 2..3 days, as I can spend some time on this this week-end and the next evenings. Of course, this patch can go in the next release, if you deem it is better. Thanks Philippe ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.2 branch 2018-06-22 Update 2018-06-22 14:05 GDB 8.2 branch 2018-06-22 Update Joel Brobecker ` (4 preceding siblings ...) 2018-06-23 15:17 ` Philippe Waroquiers @ 2018-06-25 21:26 ` Pedro Franco de Carvalho 5 siblings, 0 replies; 9+ messages in thread From: Pedro Franco de Carvalho @ 2018-06-25 21:26 UTC (permalink / raw) To: Joel Brobecker, gdb-patches Joel Brobecker <brobecker@adacore.com> writes: > Anything else? Hello, I'm still working on enabling more registers in powerpc, and there's a chance it might be ready by the end of the week. However, the number of new registers breaks a use case with tracepoints due to an internal buffer size. I have submitted patches to improve this [1], and I'm addressing the comments from Ulrich's review. These affect the core parts of gdb, not only powerpc. [1] https://sourceware.org/ml/gdb-patches/2018-06/msg00501.html Thanks! -- Pedro Franco de Carvalho ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-06-25 21:26 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-06-22 14:05 GDB 8.2 branch 2018-06-22 Update Joel Brobecker 2018-06-22 14:10 ` Simon Marchi 2018-06-22 14:13 ` Joel Brobecker 2018-06-22 15:40 ` Alan Hayward 2018-06-22 16:54 ` Sergio Durigan Junior 2018-06-22 18:22 ` Joel Brobecker 2018-06-22 20:41 ` Sergio Durigan Junior 2018-06-23 15:17 ` Philippe Waroquiers 2018-06-25 21:26 ` Pedro Franco de Carvalho
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).