This is the mail archive of the 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: Why GNU LD puts ".?tor*" sections into ".text" section when linking a PE image?

Hi Nick,

Thank you for the answer. Well, I don't know all the possible architectures,
but it sounds like they must also have difficulties with regular function
pointers, right? Could this be true?

The decision to put the content of ".ctor*" and ".dtor*" dates back to
the original commit from Jul 27, 1995, by Steve Chamberlain. It looks
like it has never been revised since then.

I've checked the behavior of MS tools and it looks like they use input
sections ".CRT$XCU" for the same tasks as "ctor*" sections. The content
of these sections goes to ".rdata" output section.

I'm going to propose a patch to make the behavior of GNU ld more close
to MS tools. What do you think?

Best regards,
Igor Kudrin

From: <> on behalf of Nick Clifton <>
Sent: Thursday, December 1, 2016 9:42 PM
To: Igor Kudrin;
Subject: Re: Why GNU LD puts ".?tor*" sections into ".text" section when linking a PE image?

Hi Igor,

> Can anybody explain, why ".ctor*" and ".dtor*" sections were added into a ".text" section?
> Is it safe to move those statements to another place, like a ".rdata" section?

I can hazard a guess, but I cannot give you a definitive answer:

The reason I suspect is so that these sections contain function pointers
and so they should be considered to be part of the executable region of
the program.  This might be important on architectures which make a
distinction between data and code fetches.


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