What should we do re: "[patch] Speed up find_pc_section"

[Joel Brobecker <brobecker@adacore.com>]

Hello everyone,

According to Tristan Gingold, this optimization is currently causing
the Darwin debugger to fail completely (I think Paul knows). Basically,
what happens is that, on Darwin, the debugging info is in the .o files,
and the sections there will necessarily overlap with the sections in
the executable. On MacOS, the way things are currently setup, I think
that we read the .o files as extra object files, rather than sources
of debug info (a-la .gnu_debug_link).

I don't know how dodgy it was in the first place to load the entire
.o as opposed to just its debugging info, but fixing this will require
a non-trivial effort. Tristan has some ideas on how to do this, but
it would be too late for the release - we're probably looking at fixing
this for 7.1. In the meantime, the MacOS port is badly broken.

I would like us to consider the idea of reverting that patch (and all
followup patches), only to re-apply it after the gdb-7.0 branch is cut.
The reason behind this suggestion is that we're still negotiating some
issues uncovered by this patch (I understand that some of the issues
were latent), and we're just so close to the branch time that I think
it would be less risky to release without it.

Paul, before we discuss the merits of that suggestion, do you think
that it would be doable to revert? I know that several patches have
already been applied on top in order to fix some of the issues we
later uncovered.

Other ideas?

Perhaps one possiblity would be to remove that assertion from the code
and let it return one section at random that matches the PC? Paul seems
to say that, if the assertion is tripped, it means that, before his
patch, we were already potentially returning the wrong section anyway.
Does removing the assertion bring us back to that situation?

One last suggestion that Tristan did make this morning, is to downgrade
Darwin support to DSYM files only, as opposed to automatically load
all .o files. That would be too bad, however, as this introduces an
extra step in the build that's inconvenient, and potentially time-
consuming.

-- 
Joel