RE: [PATCH] Make obj_sec_set_private_data into a format_ops member

["Dave Korn" <dave dot korn at artimi dot com>]

On 02 May 2006 11:37, Alan Modra wrote:

> On Tue, May 02, 2006 at 11:19:35AM +0100, Dave Korn wrote:
>> objects.  It's certainly not necessary to call the hook for those other
>> formats, and indeed is not just superfluous but can also be actually
>> incorrect; for instance it leads to a null pointer dereference on cygwin.
> 
> How?

  When creating the *ABS* section at startup (and presumably also when
creating the *UND* section, but this one crashes first!) we call subseg_get
which then (because of elf.h's definition of obj_sec_set_private_data) calls
coff_new_section_hook in bfd/coffcode.h, where we run into this line:

  coffsymbol (section->symbol)->native = native;

which dies because there isn't a corresponding combined_entry_type struct to
back the symbol.  You could fairly claim that this is a bfd bug for assuming
the pointer won't be null, or that gas is at fault for not creating a fake
internal symbol to back the fake bfd asymbol, but it's still a function call
that isn't made by the non-multi-obj coff targetted builds and that is made by
the multi-obj builds, and if multi-obj is really /really/ meant to be
behaviour-preserving and backward compatible then it should do the same things
to the same data in order to produce the same output and the simplest way of
guaranteeing that is not to have different function call graphs between the
two cases!

>>   My patch preserves existing behaviour in non-multi-obj, fixes incorrect
> 
> Yeah, I know.  Your patch is good, but I'm going to rip out
> obj_sec_set_private_data completely.  Here's a preview.  I haven't
> finished a regression test yet, so things might need to change.
> Especially if I run into your NULL deref.

  I suspect you may well do so on coff targets; and that leads on to larger
issues of regularising the way in which synthetic symbols (i.e. not backed by
a real target-dependent symbol structure with all the relevant internal data)
can be created, doesn't it?

  BTW, this issue aside, how about making the other macros I mentioned into
format ops?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....