This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] New --pe-dll-characteristcs switch for PE ld.


On Fri, Mar 06, 2009 at 04:42:20PM +0000, Dave Korn wrote:
>Christopher Faylor wrote:
>> On Fri, Mar 06, 2009 at 06:48:09AM +0000, Dave Korn wrote:
>>> It's only the extra debug option that mentions pe by name.  So if it
>>> was my choice I'd now want to call the flag "--dll-characteristics".
>>> Do you or any of the other regular maintainers have any suggestions?
>
>> --characteristics 
>
>  This removes the only part of the name that distinguishes whether it refers
>to the "Characteristics" field or the "DllCharacteristics".

Yes, I mentioned this my other message in response to Danny.

>> or --pe-characteristics.
>
>  I could live with this, because it's part of the optional PE header, and the
>Characteristics field is part of the base COFF header, so could in theory be
>denoted by "--coff-characteristics".
>
>  Can you enlarge on how you would see the name "--dll-characteristics"
>causing confusion?  I think it's an odd kind of end-user who'd know enough to
>have a reason to be looking to set these bits, yet somehow be surprised by
>what the option was called.  Most people who end up using it will, I think, be
>either (most common) non-developer-end-users who want to build packages from
>source and will run into problems which someone will answer by saying "Add
>-dll-characteristics=tsaware to the linker flags", and they'll just cut and
>paste it without caring what it means, or (less common) developers fully aware
>of the PE format who will know exactly what the name DllCharacteristics means
>and not be confused by its applicability to more than DLLs alone (and
>conceivably be surprised to find the option named differently).  I'm really
>not grasping the problem that you think could arise.

Since you are talking about things like "documented name"s, why not just
make each of these an option like the Microsoft linker does?  If we're
trying to catch people who are used to these facilities, it seems like
we should be trying to be consistent with the way the entity who created
these flags dealt with them.

So, I'd propose that all of the suboptions just become first-class
options and, if it is really required, --dll-characteristics take an
integer argument to provide pinpoint control over what gets set.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]