This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [patch]: Unify and cleanup entry point handling for PE targets
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: Kai Tietz <ktietz70 at googlemail dot com>
- Cc: Dave Korn <dave dot korn dot cygwin at googlemail dot com>, Kai Tietz <Kai dot Tietz at onevision dot com>, binutils at sourceware dot org
- Date: Wed, 04 Nov 2009 16:34:28 +0000
- Subject: Re: [patch]: Unify and cleanup entry point handling for PE targets
- References: <OF6E882799.21F6A99D-ONC125765D.003DDE55-C125765D.003E9064@onevision.de> <4AF18B09.3020409@gmail.com> <90baa01f0911040746i61be2405q984e635789dcf8cc@mail.gmail.com>
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