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: ld big trouble.


2009/9/2 Dave Korn <dave.korn.cygwin@googlemail.com>:
>
> ? ?Hi gang,
>
> ?Here's ld's toplevel from ldlang.c:
>
>> void
>> lang_process (void)
>> {
>> ? [ ... ]
>> ? if (! link_info.relocatable)
>> ? ? {
>> ? ? ? asection *found;
>> ? ? ? [ ... ]
>> ? ? ? /* Look for a text section and set the readonly attribute in it. ?*/
>> ? ? ? found = bfd_get_section_by_name (link_info.output_bfd, ".text");
>>
>> ? ? ? if (found != NULL)
>> ? ? ? {
>> ? ? ? ? if (config.text_read_only)
>> ? ? ? ? ? found->flags |= SEC_READONLY;
>> ? ? ? ? else
>> ? ? ? ? ? found->flags &= ~SEC_READONLY;
>> ? ? ? }
>> ? ? }
>> ? [ ... ]
>
> ?Why only ".text" here, and not a more general match for (e.g.) ".text.*"?
> GCC's partitioning options generate sections with names like ".text.unlikely",
> or ".text.cold" and ".text.hot". ?Shouldn't these text sections be governed by
> the same text_read_only flag? ?It breaks auto-import on PE platforms, because
> that requires that all text sections (well, all that have fixup imports
> anyway) be writable.
>
> ?The answer to these questions tells me whether to use a more general string
> matcher across all sections here, or whether to do special processing in the
> ldemul_before_allocation() hooks in the PE/PE+ emulations. ?However the
> "text_read_only" member appears to have been added without being mentioned in
> a ChangeLog, and nor is it commented where declared, so I'm reluctant to
> attempt to divine its intended semantics. ?I'm off to go and spend some time
> digging through the mailing lists and cvs history, but I thought I'd leave
> this here while I get on with that in case anyone has a definitive word to say
> about it.
>
> ? ?cheers,
> ? ? ?DaveK
>

Well, I don't know who implemented it, but I know why it is present.
For x64, new implementation of pseudo-relocation v1, and for v2 this
isn't necessary anymore
This patch itself was necessary as old relocation code doesn't changed
memory access for modification.
In general it is a rude hack IMHO, as it allows code modifications in
a general way, which can be a security issue.

Cheers,
Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination


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