This is the mail archive of the cygwin mailing list for the Cygwin 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: cygwin, libtool, dlpreopen, and .rdata

Shankar Unni wrote:

Brian Ford wrote:

Yes, I see. I hope Danny Smith might weigh in here?

I would argue that this is gcc's responsibility. If a const structure variable contains *any* code or data addresses, it's not safe to put it in .rdata (or .rodata, whatever the platform calls it), because of relocation issues.

So rather than detect a "DLL import", I'd say *any* function addresses

Actually, *function* addresses are fine; they don't get relocated (at least, not by the runtime-pseudo-reloc gobbledygook). It's only the addresses of DATA items exported by DLLs that get relocated in this way.

AND, they get relocated IF AND ONLY IF you are linking to a DLL. If you link to a static library, no runtime relocation is necessary because the linker resolves all of the addresses in question at link time. And if (really the same issue as a static lib) the addresses in question come from a standalone .o (e.g. an extern data item in your own app, not one supplied by a library at all) then why shouldn't it be const -- and put in .rdata?

But how is gcc supposed to know that you're going to link to a DLL? (The same question applies to creating the trampolines for DATA exports in the first place, and that took some seriously hairy code and over a year to get it right, and stabilized).

Yeah, you could play it safe and just say "In x86, any structure or variable that is initialized with the address of any variable (but not function), should go into .data, not .rdata" -- and lose the benefits of const==.rdata for those structures. But that "punishes" many common cases in the interests of making a few rare cases work properly.

Sometimes the answer really is "Don't do that.": don't declare structs const if they contain addresses of data coming from an external library.

in a const initializer should cause the variable to go into a regular .data section, without any complicated decision-making by binutils.

(Note: this is not the same problem that Danny talks about in that message - that usage was legitimate, and there was no attempt to have a const initialized variable with a data address.)



-- Unsubscribe info: Problem reports: Documentation: FAQ:

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