> 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 _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
