This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: gcc 3.3.3 builds "corrupt" lesstif-0.93.94
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin-apps at cygwin dot com
- Date: Sun, 24 Oct 2004 02:01:18 -0400
- Subject: Re: gcc 3.3.3 builds "corrupt" lesstif-0.93.94
- References: <000701c4b96a$da9c6110$056d65da@DANNY>
Danny Smith wrote:
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