Re: [PATCH] Indicate dependency on personality routines for ARMEHABI - take 2

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Mon, 2005-03-07 at 18:40, Julian Brown wrote:
> Paul Brook wrote:
> >>>Is one per file sufficient? I'd expect one per section would be needed to
> >>>prevent bad things happening with partial linking.
> >>
> >>Yes, you are probably right. This version should fix that: it resets the
> >>bitmap of relocations which have been output when the section is changed
> >>to one of type SHT_ARM_EXIDX.
> > 
> > 
> > I still only get one R_ARM_NONE relocation for the example below.
>  > [snipped example]
> 
> This version fixes that example, and my previous tests - it now tests 
> for the section being changed to one of type SHT_PROGBITS, rather than 
> SHT_ARM_EXIDX.
> 
> Tests have been re-run.
> 
> OK to apply?

I fear we aren't there yet.  Consider emitting unwind sections for a
real C++ application that goes something like

.text
.text.foo (eg a common function definition)
.text

We'll get two references added to the .text section.  That's not
necessarily fatal, but it is indicative of a design flaw.

Nick's point about making push/pop section work correctly made me think
about this for a moment.  I think the correct way to handle this is to
rework the TC_SEGMENT_INFO_TYPE code (and hence the mapping symbol code)
so that it is a structure rather than a single datum type.  You could
then add marked_pr_dependency to that type and all segment
pushing/popping should just work magically, solving both Nick's question
and the case above once and for all.

R.