Re: [Patch] Don't relocate compressed sections

[Roland McGrath <roland at hack dot frob dot com>]

> On Wed, Mar 28, 2012 at 01:36:26PM -0700, Roland McGrath wrote:
> > As mentioned before, if we merge and finish up the relocate branch
> > then the problem goes away.
> 
> But we currently don't have an estimate for when this will happen.

IIRC it was pretty well ready when I left it.  I just merged the trunk
into the branch.  It still builds except for strip.c where you copied
some of the libdwfl/relocate.c code.  That needs to get the
corresponding updates to use ebl_reloc_simple_types instead of
ebl_reloc_simple_type.  Do you want to make those fixes on the branch?

I think the main barrier was wanting some more consideration on the new
API additions (look at 'git diff master..roland/relocate -- libdw.h')
before we enshrined them in the permanent libdw ABI.  So one option is
just to decide we think they are good enough as they are.

Another option is to do an intermediate version of the branch with all
the internals changes, but without making any new interfaces public.
Then libdwfl-based uses like systemtap's get the (presumed, measurable)
performance benefits of reloc-on-demand and the compressed-section
problem goes away for libdwfl.  But we don't commit to any new APIs or
ABIs.

> Until we do finish that I like to not apply relocations to compressed
> sections, since we know that just doesn't work (and the corruption might
> not even be detected if we do). That is really all the patch does.

I have several concerns here.  Even if we did just that, then I thought
the patch looked ugly enough that it can probably be done in a way
somewhat cleaner than that.  But that's just the trivial concern.

It concerns me more that we would be papering over our lack of thorough
support for .zdebug_* sections while making it appear that we might
handle them.  Giving such a false impression might be worse than an
"obviously broken" state.

The support I added in commit 725aad5d was pretty minimal and I surely
overlooked multiple subtleties at the time.  (We weren't near a release
at the time, and I probably figured we'd have more close attention
before the next release than we actually had in the year--exactly one
year, it so happens--that we had from then until 0.153.)  The libdwfl
interaction for ET_REL that's been noticed here is just one.  Another
that pops to mind now is that ebl_debugscn_p doesn't match .zdebug_*
sections.  What effects does that have?


Thanks,
Roland