GDB 8.1.1 release, 2018-05-30 update

GDB 8.1.1 release, 2018-05-30 update

[Joel Brobecker]

Hey everyone,

Still down to the one issue we have left:

  * [KeithS/TomT] PR symtab/23010 (Regression: Assertion: SYMBOL_LANGUAGE (sym) == DICT_LANGUAGE (dict)->la_language)

       This is a regression. Tom sent a patch which got peer-reviewed
       by KeithS, and I gave it a nod, so it should go in sometime
       soon. But we still need to discuss whether the patch is suitable
       for 8.1.1.

       https://sourceware.org/ml/gdb-patches/2018-04/msg00234.html

The good news is that Keith was able to figure out what happens,
and came up with a fairly simple patch, which bodes well for
backporting it to the branch.

Keith, do you have a sense of when you might be able to officially
submit the patch?

Thanks!
-- 
Joel

Re: GDB 8.1.1 release, 2018-05-30 update

[Keith Seitz]

On 05/30/2018 03:20 PM, Joel Brobecker wrote:
> Keith, do you have a sense of when you might be able to officially
> submit the patch?

Sorry about the delay -- I had to take a sick day yesterday. :-(

I'm still trying to write a reproducer. It's just really, really elusive.

Keith

Re: GDB 8.1.1 release, 2018-05-30 update

[Joel Brobecker]

Hey Keith,

> On 05/30/2018 03:20 PM, Joel Brobecker wrote:
> > Keith, do you have a sense of when you might be able to officially
> > submit the patch?
> 
> Sorry about the delay -- I had to take a sick day yesterday. :-(

Sorry to hear that. Hope you're better now!

> I'm still trying to write a reproducer. It's just really, really elusive.

Do you think we have reached the point where we might be past
what's reasonable for trying to create a regression test? Just
trying to guage a bit whether it's worth pouring more resources
into trying to get one, vs using the resources elsewhere.

I have a feeling that you've done your due diligence and spent
enough time that we should consider your patch without a testcase,
since the patch itself is relatively straightforward. If people
prefer, we can limit the patch to just the master branch for now,
but I'd be happy to have it in both.

-- 
Joel

Re: GDB 8.1.1 release, 2018-05-30 update

[Keith Seitz]

On 06/04/2018 02:18 PM, Joel Brobecker wrote:
> 
> Sorry to hear that. Hope you're better now!
> 

Some sort of 24-hour bug. Thank you for your well-wishes.

>> I'm still trying to write a reproducer. It's just really, really elusive.
> 
> Do you think we have reached the point where we might be past
> what's reasonable for trying to create a regression test? Just
> trying to guage a bit whether it's worth pouring more resources
> into trying to get one, vs using the resources elsewhere.

Yeah, I've pretty much given up on triggering the exact conditions that cause a user-visible manifestation of this bug. I have a dwarf assembler file that I've been hacking at, and it is getting *quite* large. Still no luck in causing this bug to trigger.

However, I have been thinking about an alternative, easier way to trigger the bug. That is by wrapping add_symbol_to_list in dwarf2read.c with a custom version that checks if we are adding symbols to a language_minimal dictionary. If it sees that, it issues a complaint. [Or add another option to turn this on/off.]

Once again that adds complexity into an already performance-sensitive area, and I'm not really sure it is worth the effort anymore. Not to mention how hacky it is!

So really, I can continue down this road, or maintainers can make the call to omit a test case for it entirely. Otherwise, I'll return my attention to helping with the patch review backlog.

Keith 

Re: GDB 8.1.1 release, 2018-05-30 update

[Joel Brobecker]

> Yeah, I've pretty much given up on triggering the exact conditions
> that cause a user-visible manifestation of this bug. I have a dwarf
> assembler file that I've been hacking at, and it is getting *quite*
> large. Still no luck in causing this bug to trigger.
> 
> However, I have been thinking about an alternative, easier way to
> trigger the bug. That is by wrapping add_symbol_to_list in
> dwarf2read.c with a custom version that checks if we are adding
> symbols to a language_minimal dictionary. If it sees that, it issues a
> complaint. [Or add another option to turn this on/off.]
> 
> Once again that adds complexity into an already performance-sensitive
> area, and I'm not really sure it is worth the effort anymore. Not to
> mention how hacky it is!
> 
> So really, I can continue down this road, or maintainers can make the
> call to omit a test case for it entirely. Otherwise, I'll return my
> attention to helping with the patch review backlog.

Why not submit the patch as is, without a testcase? Then, leave it
to me to rally the other maintainers to weigh in on the topic ;-).

The alternative option you suggest is kind of interesting; I would
have a hard time evaluating the performance impact without actually
doing some measurements. It could be unnoticeable, particularly
when building with optimization and inlining (I'm thinking that
the extra wrapper could be reduced to one test instruction or two
when complaints are off).

-- 
Joel