This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH, CFI] Fix EH for coldfire-uclinux
- From: Daniel Jacobowitz <dan at codesourcery dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Maxim Kuvyrkov <maxim at codesourcery dot com>, binutils <binutils at sourceware dot org>, Jason Merrill <jason at redhat dot com>
- Date: Wed, 4 Nov 2009 14:46:38 -0500
- Subject: Re: [PATCH, CFI] Fix EH for coldfire-uclinux
- References: <4AF0A236.email@example.com> <4AF1C2E0.firstname.lastname@example.org>
On Wed, Nov 04, 2009 at 10:07:28AM -0800, Richard Henderson wrote:
> On 11/03/2009 01:35 PM, Maxim Kuvyrkov wrote:
> >To generate bFLT binaries for coldfire-uclinux elf2flt utility is used.
> >Elf2flt does not honor PT_LOAD's from the executable. So, despite
> >appearances of the ELF file, .text and .eh_frame sections will not end
> >up in the same segment in bFLT file. Therefore PC-relative encoding
> >cannot be used for CFI on coldfire-uclinux. Hence this patch defines
> >CFI_DIFF_EXPR_OK to 0 for coldfire-uclinux.
> I don't see anything wrong with the patch as far as it goes, but...
That's good enough for me (for now) - Maxim, the patch can go in.
> The best solution would be to fix elf2flt and get the eh data into
> the read-only section, then use DW_EH_PE_datarel for any items that
> reside in the data section.
The problem's not just with elf2flt, but also with various other bits
including ld and linker scripts (I haven't tracked down all the pieces
yet): we end up with only one PT_LOAD segment. Then elf2flt splits
things based on BFD's section flags (argh). So things ld thought were
in a single segment turn out not to be.
Once we get things into two segments as they are Intended To Be, then
we should be able to teach elf2flt to work based on segments. At that
point this becomes a lot simpler; read-only eh data -> read-only
We have plenty of incentive to get this really right. For instance,
GDB tries to relocate the binary at runtime. It uses ptrace to get
the text and data offsets, then applies those offsets... cleverly, to
segments as seen in the ELF file. So the mismatch messes up the
address of every global variable.
I guess we can back out the gas change at that point.
> The only thing missing
> at this point is the fact that unlike other targets, m68k doesn't
> parse the @RELOC specifiers on .long data.
Which doesn't matter if you're using CFI directives, does it?