Back before .rdata was enabled for user data in GCC, const data was put into ,text, which is normally readonly as well. But this, in pe-dll.c:pe_create_import_fixup
line 2178
/* If we ever use autoimport, we have to cast text section writable. */ config.text_read_only = FALSE; output_bfd->flags &= ~WP_TEXT
allowed it to work. .
Good info. Thanks -- I'll try to code up a similar patch (but the "obvious" symbol certainly doesn't exist currently, and "config.rdata_read_only" is *really* going to look funny. I can see it now on the binutils list: "Why do you want a flag that indicates whether the read-only-data section is read-only?"
So checking one or both of these flags provides info on whether we might also need to make .rdata writeable.
Me? I would just do something simple like mark the problematic data as dllimport. I don't like the idea of making .text writeable, let alone .rdata
I don't think that would work. Take this earlier example:
const struct poptOption options[] = { ... {"version", 'v', POPT_ARG_NONE, &cl_output_version, 0, "Output compiler version and serial", NULL}, ... }
In this example, it is cl_output_version that is dllimported from a DLL. But it's options[] that is in .rdata, and contains the reference to cl_output_version. By explicitly dllimporting cl_output_version, you still don't solve the problem of "options[0].value" being stored in a non-writable section. [Unless dllimport somehow instructs the *windows loader* to do the magic properly, before the "non-writable" thing is enforced -- kinda like my original hope for "our" machinery, but which might happen even earlier in the whole process. I'm not sure about this]
Plus, there's another problem: variables imported from a DLL are usually declared by the library's header file. So, if (somehow) declaring cl_output_version as dllimport would fix this rdata problem, you still have now forced us back to the Bad Old Days before auto-import. Because now, in order to support this wierd corner case (a CLIENT app wants to stick the address of a dll-imported variable into a data structure that is marked const, and is thus stored in .rdata) you require that the LIBRARY declare that symbol using the old magic DLLIMPEXP-style macros, which expand to declspec(dllimport) when building a client (and, presumably, declspec(dllexport) when building the library itself: this isn't necessary, but its "the way it's done").
And here's the rub: with current binutils, if ONE symbol is declared dllexport, then ALL of them must be -- because having ONE symbol declared dllexport "turns off" the auto-EXPORT functionality when building the DLL.
Your solution "feels" like a step backwards, to me -- even assuming it actually solves the problem, which I don't think it will [see three paragraphs up]. Yeah, I could test this instead of speculating, but it's late. If someone beats me to it, an ounce of experimental data is worth a ton of theory -- go for it.
-- Chuck