* GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release @ 2021-03-06 6:46 Joel Brobecker 2021-03-06 18:13 ` Kevin Buettner 2021-03-09 5:08 ` Simon Marchi 0 siblings, 2 replies; 12+ messages in thread From: Joel Brobecker @ 2021-03-06 6:46 UTC (permalink / raw) To: gdb-patches Hello everyone, Thanks again to everyone who's been helping on this release so far. See the summary below, where we only have 2 patches left to backport. Unless there are any issues that we're discovering last minute, I propose we create the release sometime next weekend: 13-14 March Cheers! Fixed Since the Previous Update: -------------------------------- * [<Simon + Andrew>] <PR backtrace/27147> [GNU/Linux, sparc64] GDB is unable to print full stack trace (got "previous frame inner to this frame" errors) https://sourceware.org/bugzilla/show_bug.cgi?id=27147 * [KeithS] <PR gdb/27333> [dwarf-5] abort on unhandled DW_TAG_type_unit in process_psymtab_comp_unit https://sourceware.org/bugzilla/show_bug.cgi?id=27333 Added Since the Last Update: ---------------------------- * [KevinB] <**PR MISSING**> Fix aarch64-linux-hw-point.c build problem with glibc-2.33 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=665af52ec2a52184d39a76d6e724fa4733dbab3c Already in master. Needs a PR to be created, before the patches can be backported. * [KevinB] <**PR MISSING**> amd64-linux-siginfo.c: Adjust include order to avoid gnulib error https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8488c357ce4fc309d49c7b0224cf9574b68e8116 Already in master. Needs a PR to be created, before the patches can be backported. Other Ongoing Items: -------------------- < none :) > Not Critical, but Requested: ---------------------------- < none :) > Thank you! -- Joel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release 2021-03-06 6:46 GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release Joel Brobecker @ 2021-03-06 18:13 ` Kevin Buettner 2021-03-07 5:45 ` Joel Brobecker 2021-03-09 5:08 ` Simon Marchi 1 sibling, 1 reply; 12+ messages in thread From: Kevin Buettner @ 2021-03-06 18:13 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches On Sat, 6 Mar 2021 10:46:11 +0400 Joel Brobecker <brobecker@adacore.com> wrote: > Added Since the Last Update: > ---------------------------- > > * [KevinB] <**PR MISSING**> > Fix aarch64-linux-hw-point.c build problem with glibc-2.33 > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=665af52ec2a52184d39a76d6e724fa4733dbab3c > > Already in master. Needs a PR to be created, before the patches > can be backported. > > * [KevinB] <**PR MISSING**> > amd64-linux-siginfo.c: Adjust include order to avoid gnulib error > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8488c357ce4fc309d49c7b0224cf9574b68e8116 > > Already in master. Needs a PR to be created, before the patches > can be backported. The PR numbers for these are 27536 and 27535, respectively. I cherry-picked them to gdb-10-branch, updating ChangeLog and the commit logs to include the bug numbers. I've pushed those changes to the branch. Kevin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release 2021-03-06 18:13 ` Kevin Buettner @ 2021-03-07 5:45 ` Joel Brobecker 2021-03-07 6:25 ` Kevin Buettner 0 siblings, 1 reply; 12+ messages in thread From: Joel Brobecker @ 2021-03-07 5:45 UTC (permalink / raw) To: Kevin Buettner via Gdb-patches > > Added Since the Last Update: > > ---------------------------- > > > > * [KevinB] <**PR MISSING**> > > Fix aarch64-linux-hw-point.c build problem with glibc-2.33 > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=665af52ec2a52184d39a76d6e724fa4733dbab3c > > > > Already in master. Needs a PR to be created, before the patches > > can be backported. > > > > * [KevinB] <**PR MISSING**> > > amd64-linux-siginfo.c: Adjust include order to avoid gnulib error > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8488c357ce4fc309d49c7b0224cf9574b68e8116 > > > > Already in master. Needs a PR to be created, before the patches > > can be backported. > > The PR numbers for these are 27536 and 27535, respectively. > > I cherry-picked them to gdb-10-branch, updating ChangeLog and the > commit logs to include the bug numbers. I've pushed those changes to > the branch. Thanks for doing all of the above and the note, Kevin. I've set the target milestone to 10.2 for those, so my scripts can find them when I announce the release; unless there is more you want to do for these PRs, I think we can close them now. -- Joel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release 2021-03-07 5:45 ` Joel Brobecker @ 2021-03-07 6:25 ` Kevin Buettner 0 siblings, 0 replies; 12+ messages in thread From: Kevin Buettner @ 2021-03-07 6:25 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches On Sun, 7 Mar 2021 09:45:32 +0400 Joel Brobecker <brobecker@adacore.com> wrote: > > > Added Since the Last Update: > > > ---------------------------- > > > > > > * [KevinB] <**PR MISSING**> > > > Fix aarch64-linux-hw-point.c build problem with glibc-2.33 > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=665af52ec2a52184d39a76d6e724fa4733dbab3c > > > > > > Already in master. Needs a PR to be created, before the patches > > > can be backported. > > > > > > * [KevinB] <**PR MISSING**> > > > amd64-linux-siginfo.c: Adjust include order to avoid gnulib error > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8488c357ce4fc309d49c7b0224cf9574b68e8116 > > > > > > Already in master. Needs a PR to be created, before the patches > > > can be backported. > > > > The PR numbers for these are 27536 and 27535, respectively. > > > > I cherry-picked them to gdb-10-branch, updating ChangeLog and the > > commit logs to include the bug numbers. I've pushed those changes to > > the branch. > > Thanks for doing all of the above and the note, Kevin. > > I've set the target milestone to 10.2 for those, so my scripts can > find them when I announce the release; unless there is more you want > to do for these PRs, I think we can close them now. I've closed them. Kevin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release 2021-03-06 6:46 GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release Joel Brobecker 2021-03-06 18:13 ` Kevin Buettner @ 2021-03-09 5:08 ` Simon Marchi 2021-03-10 2:48 ` Joel Brobecker 1 sibling, 1 reply; 12+ messages in thread From: Simon Marchi @ 2021-03-09 5:08 UTC (permalink / raw) To: Joel Brobecker, gdb-patches On 2021-03-06 1:46 a.m., Joel Brobecker wrote: > Hello everyone, > > Thanks again to everyone who's been helping on this release so far. > See the summary below, where we only have 2 patches left to backport. > > Unless there are any issues that we're discovering last minute, > I propose we create the release sometime next weekend: > > 13-14 March > > Cheers! > > Fixed Since the Previous Update: > -------------------------------- > > * [<Simon + Andrew>] <PR backtrace/27147> > [GNU/Linux, sparc64] GDB is unable to print full stack trace (got "previous frame inner to this frame" errors) > https://sourceware.org/bugzilla/show_bug.cgi?id=27147 > > * [KeithS] <PR gdb/27333> > [dwarf-5] abort on unhandled DW_TAG_type_unit in process_psymtab_comp_unit > https://sourceware.org/bugzilla/show_bug.cgi?id=27333 > > Added Since the Last Update: > ---------------------------- > > * [KevinB] <**PR MISSING**> > Fix aarch64-linux-hw-point.c build problem with glibc-2.33 > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=665af52ec2a52184d39a76d6e724fa4733dbab3c > > Already in master. Needs a PR to be created, before the patches > can be backported. > > * [KevinB] <**PR MISSING**> > amd64-linux-siginfo.c: Adjust include order to avoid gnulib error > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8488c357ce4fc309d49c7b0224cf9574b68e8116 > > Already in master. Needs a PR to be created, before the patches > can be backported. > > Other Ongoing Items: > -------------------- > > < none :) > > > Not Critical, but Requested: > ---------------------------- > > < none :) > > > Thank you! > A new issue has popped up: https://sourceware.org/bugzilla/show_bug.cgi?id=27541 Tom Tromey and I would be good candidates to look a it, because it's related to the DWARF symbol sharing, which we've both worked on. I will try to give it a look in the following days. Simon ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release 2021-03-09 5:08 ` Simon Marchi @ 2021-03-10 2:48 ` Joel Brobecker 2021-03-15 3:43 ` Simon Marchi 0 siblings, 1 reply; 12+ messages in thread From: Joel Brobecker @ 2021-03-10 2:48 UTC (permalink / raw) To: Simon Marchi; +Cc: gdb-patches Hi Simon, > A new issue has popped up: > > https://sourceware.org/bugzilla/show_bug.cgi?id=27541 > > Tom Tromey and I would be good candidates to look a it, > because it's related to the DWARF symbol sharing, which > we've both worked on. I will try to give it a look in > the following days. Thanks for the heads up, Simon. I've changed its Target Mileston to 10.2 in Bugzilla. -- Joel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release 2021-03-10 2:48 ` Joel Brobecker @ 2021-03-15 3:43 ` Simon Marchi 2021-03-16 3:45 ` Joel Brobecker 0 siblings, 1 reply; 12+ messages in thread From: Simon Marchi @ 2021-03-15 3:43 UTC (permalink / raw) To: Joel Brobecker, Simon Marchi, Tom Tromey; +Cc: gdb-patches On 2021-03-09 9:48 p.m., Joel Brobecker wrote: > Hi Simon, > >> A new issue has popped up: >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=27541 >> >> Tom Tromey and I would be good candidates to look a it, >> because it's related to the DWARF symbol sharing, which >> we've both worked on. I will try to give it a look in >> the following days. > > Thanks for the heads up, Simon. I've changed its Target Mileston > to 10.2 in Bugzilla. > I've been looking at this on and off for the last few days, and I don't think I'll be able to come up with a proper fix in a short time frame. And even if I did, I think it would be too risky for merging in a stable branch right before releasing. The alternative I see to unblock the release is to disable the sharing of partial symbols between objfiles for now. Essentially, a patch that does diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 704ba9f36655..5d9256bece1e 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -1954,7 +1954,8 @@ dwarf2_has_info (struct objfile *objfile, doesn't require relocations and if there aren't partial symbols from some other reader. */ if (!objfile_has_partial_symbols (objfile) - && !gdb_bfd_requires_relocations (objfile->obfd)) + && !gdb_bfd_requires_relocations (objfile->obfd) + && 0) { /* See if one has been created for this BFD yet. */ per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd); We can then take our time to look at a proper fix for master. Simon ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release 2021-03-15 3:43 ` Simon Marchi @ 2021-03-16 3:45 ` Joel Brobecker 2021-03-30 5:02 ` Tom Tromey 0 siblings, 1 reply; 12+ messages in thread From: Joel Brobecker @ 2021-03-16 3:45 UTC (permalink / raw) To: Simon Marchi; +Cc: Simon Marchi, Tom Tromey, gdb-patches Hi Simon, > >> Tom Tromey and I would be good candidates to look a it, > >> because it's related to the DWARF symbol sharing, which > >> we've both worked on. I will try to give it a look in > >> the following days. > > > > Thanks for the heads up, Simon. I've changed its Target Mileston > > to 10.2 in Bugzilla. > > > > I've been looking at this on and off for the last few days, and I don't > think I'll be able to come up with a proper fix in a short time frame. > And even if I did, I think it would be too risky for merging in a stable > branch right before releasing. That's what I was fearing already, when I saw the PR and the discussions that were logged so far. > The alternative I see to unblock the release is to disable the sharing of > partial symbols between objfiles for now. Essentially, a patch that does > > diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c > index 704ba9f36655..5d9256bece1e 100644 > --- a/gdb/dwarf2/read.c > +++ b/gdb/dwarf2/read.c > @@ -1954,7 +1954,8 @@ dwarf2_has_info (struct objfile *objfile, > doesn't require relocations and if there aren't partial symbols > from some other reader. */ > if (!objfile_has_partial_symbols (objfile) > - && !gdb_bfd_requires_relocations (objfile->obfd)) > + && !gdb_bfd_requires_relocations (objfile->obfd) > + && 0) > { > /* See if one has been created for this BFD yet. */ > per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd); > > We can then take our time to look at a proper fix for master. It's quite nice to see that this feature could be disabled with a one-liner like this. Unless Tom has other ideas, this seems like the way to go for me. I also wanted to mention that, in terms of timing, I was planning on starting the regular updates for the 11.1 releases pretty much right after the GDB 10.2 is out. We will just have to list this one right from the beginning. Procedurally speaking, what would help is if we close the PR about the crash with the target milestone set to 10.2 right after your patch is in, and then re-open the PR about the partial symtab sharing to fix the crash on master (or open a new one if there wasn't one already). That way, anyone asking for the list of fixes from 10.1 to 10.2 would find this issue (this is something I do when publishing a .2, for instance). Thanks Simon! -- Joel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release 2021-03-16 3:45 ` Joel Brobecker @ 2021-03-30 5:02 ` Tom Tromey 2021-03-30 7:59 ` Joel Brobecker 2021-03-30 15:14 ` Simon Marchi 0 siblings, 2 replies; 12+ messages in thread From: Tom Tromey @ 2021-03-30 5:02 UTC (permalink / raw) To: Joel Brobecker; +Cc: Simon Marchi, Simon Marchi, Tom Tromey, gdb-patches >> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c >> index 704ba9f36655..5d9256bece1e 100644 >> --- a/gdb/dwarf2/read.c >> +++ b/gdb/dwarf2/read.c >> @@ -1954,7 +1954,8 @@ dwarf2_has_info (struct objfile *objfile, >> doesn't require relocations and if there aren't partial symbols >> from some other reader. */ >> if (!objfile_has_partial_symbols (objfile) >> - && !gdb_bfd_requires_relocations (objfile->obfd)) >> + && !gdb_bfd_requires_relocations (objfile->obfd) >> + && 0) >> { >> /* See if one has been created for this BFD yet. */ >> per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd); >> >> We can then take our time to look at a proper fix for master. Joel> It's quite nice to see that this feature could be disabled with Joel> a one-liner like this. Joel> Unless Tom has other ideas, this seems like the way to go for me. Sorry I didn't respond to this earlier. I think it's fine for the branch. I came up with a complicated plan for the trunk, but after some reflection, I think a better plan is to notice OBJF_READNOW and refuse to do any sharing in this case. That is, it's your patch, but replacing "0" with a check of OBJF_READNOW. The appended probably has the wrong line numbers but it shows the idea. This -readnow stuff is an optimization, which in retrospect is kind of silly, because on the whole I'd rather people not use -readnow anyway, so why bother optimizing. But when I added the gdb-index code, I noticed the possibility and I guess I couldn't resist. Tom diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 11cdcd02d0a..ec044ab66e5 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -1883,9 +1883,11 @@ dwarf2_has_info (struct objfile *objfile, { dwarf2_per_bfd *per_bfd; - /* We can share a "dwarf2_per_bfd" with other objfiles if the BFD - doesn't require relocations. */ - if (!gdb_bfd_requires_relocations (objfile->obfd)) + /* We can share a "dwarf2_per_bfd" with other objfiles if the + BFD doesn't require relocations, and if -readnow was never + requested. */ + if (!gdb_bfd_requires_relocations (objfile->obfd) + && (objfile->flags & OBJF_READNOW) == 0) { /* See if one has been created for this BFD yet. */ per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd); ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release 2021-03-30 5:02 ` Tom Tromey @ 2021-03-30 7:59 ` Joel Brobecker 2021-03-30 17:40 ` Simon Marchi 2021-03-30 15:14 ` Simon Marchi 1 sibling, 1 reply; 12+ messages in thread From: Joel Brobecker @ 2021-03-30 7:59 UTC (permalink / raw) To: Tom Tromey; +Cc: Simon Marchi, Simon Marchi, gdb-patches Hi Tom, On Mon, Mar 29, 2021 at 11:02:13PM -0600, Tom Tromey wrote: > >> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c > >> index 704ba9f36655..5d9256bece1e 100644 > >> --- a/gdb/dwarf2/read.c > >> +++ b/gdb/dwarf2/read.c > >> @@ -1954,7 +1954,8 @@ dwarf2_has_info (struct objfile *objfile, > >> doesn't require relocations and if there aren't partial symbols > >> from some other reader. */ > >> if (!objfile_has_partial_symbols (objfile) > >> - && !gdb_bfd_requires_relocations (objfile->obfd)) > >> + && !gdb_bfd_requires_relocations (objfile->obfd) > >> + && 0) > >> { > >> /* See if one has been created for this BFD yet. */ > >> per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd); > >> > >> We can then take our time to look at a proper fix for master. > > Joel> It's quite nice to see that this feature could be disabled with > Joel> a one-liner like this. > > Joel> Unless Tom has other ideas, this seems like the way to go for me. > > Sorry I didn't respond to this earlier. > I think it's fine for the branch. Great, thank you! Speaking of the branch, given your patch below, perhaps we can have best of both worlds if we go with the solution you suggest? If we could converge on that by the time the weekend comes, I think it would be reasonable to backport your patch to the branch as well. > I came up with a complicated plan for the trunk, but after some > reflection, I think a better plan is to notice OBJF_READNOW and refuse > to do any sharing in this case. That is, it's your patch, but replacing > "0" with a check of OBJF_READNOW. The appended probably has the wrong > line numbers but it shows the idea. > > This -readnow stuff is an optimization, which in retrospect is kind of > silly, because on the whole I'd rather people not use -readnow anyway, Same here. > so why bother optimizing. But when I added the gdb-index code, I > noticed the possibility and I guess I couldn't resist. Lol. > diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c > index 11cdcd02d0a..ec044ab66e5 100644 > --- a/gdb/dwarf2/read.c > +++ b/gdb/dwarf2/read.c > @@ -1883,9 +1883,11 @@ dwarf2_has_info (struct objfile *objfile, > { > dwarf2_per_bfd *per_bfd; > > - /* We can share a "dwarf2_per_bfd" with other objfiles if the BFD > - doesn't require relocations. */ > - if (!gdb_bfd_requires_relocations (objfile->obfd)) > + /* We can share a "dwarf2_per_bfd" with other objfiles if the > + BFD doesn't require relocations, and if -readnow was never > + requested. */ > + if (!gdb_bfd_requires_relocations (objfile->obfd) > + && (objfile->flags & OBJF_READNOW) == 0) > { > /* See if one has been created for this BFD yet. */ > per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd); Sounds like a good idea, especially if that avoids a complicated plan to make it work. The only small comment I have is that it would be useful, I think, to explain why we say we cannot share the dwarf2_per_bfd when -readnow is in effect (too complicated to support and not worth the effort considering that performance is typically not as important in the case of -readnow). -- Joel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release 2021-03-30 7:59 ` Joel Brobecker @ 2021-03-30 17:40 ` Simon Marchi 0 siblings, 0 replies; 12+ messages in thread From: Simon Marchi @ 2021-03-30 17:40 UTC (permalink / raw) To: Joel Brobecker, Tom Tromey; +Cc: Simon Marchi, gdb-patches On 2021-03-30 3:59 a.m., Joel Brobecker wrote: > Hi Tom, > > On Mon, Mar 29, 2021 at 11:02:13PM -0600, Tom Tromey wrote: >>>> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c >>>> index 704ba9f36655..5d9256bece1e 100644 >>>> --- a/gdb/dwarf2/read.c >>>> +++ b/gdb/dwarf2/read.c >>>> @@ -1954,7 +1954,8 @@ dwarf2_has_info (struct objfile *objfile, >>>> doesn't require relocations and if there aren't partial symbols >>>> from some other reader. */ >>>> if (!objfile_has_partial_symbols (objfile) >>>> - && !gdb_bfd_requires_relocations (objfile->obfd)) >>>> + && !gdb_bfd_requires_relocations (objfile->obfd) >>>> + && 0) >>>> { >>>> /* See if one has been created for this BFD yet. */ >>>> per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd); >>>> >>>> We can then take our time to look at a proper fix for master. >> >> Joel> It's quite nice to see that this feature could be disabled with >> Joel> a one-liner like this. >> >> Joel> Unless Tom has other ideas, this seems like the way to go for me. >> >> Sorry I didn't respond to this earlier. >> I think it's fine for the branch. > > Great, thank you! > > Speaking of the branch, given your patch below, perhaps we can have > best of both worlds if we go with the solution you suggest? > If we could converge on that by the time the weekend comes, > I think it would be reasonable to backport your patch to the branch > as well. This is now pushed. Quick! Release before any more bugs pop up! Simon ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release 2021-03-30 5:02 ` Tom Tromey 2021-03-30 7:59 ` Joel Brobecker @ 2021-03-30 15:14 ` Simon Marchi 1 sibling, 0 replies; 12+ messages in thread From: Simon Marchi @ 2021-03-30 15:14 UTC (permalink / raw) To: Tom Tromey, Joel Brobecker; +Cc: Simon Marchi, gdb-patches On 2021-03-30 1:02 a.m., Tom Tromey wrote: >>> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c >>> index 704ba9f36655..5d9256bece1e 100644 >>> --- a/gdb/dwarf2/read.c >>> +++ b/gdb/dwarf2/read.c >>> @@ -1954,7 +1954,8 @@ dwarf2_has_info (struct objfile *objfile, >>> doesn't require relocations and if there aren't partial symbols >>> from some other reader. */ >>> if (!objfile_has_partial_symbols (objfile) >>> - && !gdb_bfd_requires_relocations (objfile->obfd)) >>> + && !gdb_bfd_requires_relocations (objfile->obfd) >>> + && 0) >>> { >>> /* See if one has been created for this BFD yet. */ >>> per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd); >>> >>> We can then take our time to look at a proper fix for master. > > Joel> It's quite nice to see that this feature could be disabled with > Joel> a one-liner like this. > > Joel> Unless Tom has other ideas, this seems like the way to go for me. > > Sorry I didn't respond to this earlier. > I think it's fine for the branch. > > I came up with a complicated plan for the trunk, but after some > reflection, I think a better plan is to notice OBJF_READNOW and refuse > to do any sharing in this case. That is, it's your patch, but replacing > "0" with a check of OBJF_READNOW. The appended probably has the wrong > line numbers but it shows the idea. > > This -readnow stuff is an optimization, which in retrospect is kind of > silly, because on the whole I'd rather people not use -readnow anyway, > so why bother optimizing. But when I added the gdb-index code, I > noticed the possibility and I guess I couldn't resist. > > Tom > > diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c > index 11cdcd02d0a..ec044ab66e5 100644 > --- a/gdb/dwarf2/read.c > +++ b/gdb/dwarf2/read.c > @@ -1883,9 +1883,11 @@ dwarf2_has_info (struct objfile *objfile, > { > dwarf2_per_bfd *per_bfd; > > - /* We can share a "dwarf2_per_bfd" with other objfiles if the BFD > - doesn't require relocations. */ > - if (!gdb_bfd_requires_relocations (objfile->obfd))G > + /* We can share a "dwarf2_per_bfd" with other objfiles if the > + BFD doesn't require relocations, and if -readnow was never > + requested. */ > + if (!gdb_bfd_requires_relocations (objfile->obfd) > + && (objfile->flags & OBJF_READNOW) == 0) > { > /* See if one has been created for this BFD yet. */ > per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd); This is fine with me, and I think it's sufficient for now. It passes the test I wrote, so I'll adjust my patch to use this and post a v2. In the general case, I'm not convinced that there aren't more problems like this, where you load the same BFD with two different "quick" methods (as mentioned in my commit message). We currently handle the psymtabs -> index case (commit efb763a5ea35), necessary for when the index-cache is on. In that case, we just keep using the already-created psymtabs the second time around, the index is just not used. But imagine an index -> psymtabs case. I imagine we could eventually have a "-no-index" switch to the file command and/or a "set use-index on/off" parameter, to tell GDB to not use any index. That could be useful in case the index gives you some trouble and you would like to read the file without it. So you could do "file bin" first and "file -no-index bin" second. The dwarf2_per_bfd is created using the index the first time, but we wouldn't want to re-use that dwarf2_per_bfd the second time. Only sharing the dwarf2_per_bfd between objfiles that use the same "quick" method would make me more confident that we won't hit other such problematic cases. Simon ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-03-30 17:40 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-06 6:46 GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release Joel Brobecker 2021-03-06 18:13 ` Kevin Buettner 2021-03-07 5:45 ` Joel Brobecker 2021-03-07 6:25 ` Kevin Buettner 2021-03-09 5:08 ` Simon Marchi 2021-03-10 2:48 ` Joel Brobecker 2021-03-15 3:43 ` Simon Marchi 2021-03-16 3:45 ` Joel Brobecker 2021-03-30 5:02 ` Tom Tromey 2021-03-30 7:59 ` Joel Brobecker 2021-03-30 17:40 ` Simon Marchi 2021-03-30 15:14 ` Simon Marchi
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).