[patch]: Unify and cleanup entry point handling for PE targets

[Dave Korn]

Kai Tietz wrote:

>>  Hi Kai.  Thanks for bearing with me.
>
> No problem. This were pretty long 24 hours ;)

  Yes, and for 48 of those 24 hours I was even off the air owing to a blown-up
PSU!

>>> +static int is_linked_dll = 0;

>>  Is this new variable really necessary?  I couldn't figure out any way that
>> it could be set and the variable 'dll' above not also be set.  When you give
>> '-dll', the switch case OPTION_DLL sets 'is_linked_dll', and it calls
>> 'set_pe_name ("__dll__", 1)', which sets the 'dll' variable also.  I can't
>> find any code that would notice a symbol called "__dll__" in one of the input
>> BFDs and set the 'dll' variable based on it, so I think these two variables
>> will always be in step, won't they?

> Well, AFAICS those variable should be always in step. I just wanted to
> avoid here to mix linker symbol values with internal state variables.
> But if you think it is better to mix them, I can change this here.

  I see what you're getting at; conceptually these are two different things,
one is a command-line switch, the other the value of a symbol.  However, the
value of the symbol is what the command-line option is there to specify, so
it's still a very direct test of the command-line option's presence or
absence.  And also, I wonder if one day we'll want to let people define those
symbols in input .o files to a final link and cause it to have the same affect
as specifying those corresponding command-line options.  So I'd suggest just
using the state of the 'dll' variable to decide about the entrypoint and
eliminate 'is_linked_dll'.

> Initial I did it mechanically, and then verified the x64, arm, and
> i686 cases explicit.

> Yes, I agree. If there are still some issues, which I don't expect
> here, we have enough time to clean them up.

  Yep, your testing seems adequate to have covered all the popular platforms;
patch is OK once the redundant variable has been removed.

    cheers,
      DaveK