This is the mail archive of the
mailing list for the Cygwin project.
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
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
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: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html