httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Novy <n...@feld.cvut.cz>
Subject [PATCH] Apache 1.3.21-dev for NetWare builds (5)
Date Mon, 27 Aug 2001 14:08:25 GMT
Hi all,
here is the biggest issue I am experiencing with my builds of the Apache 
for NetWare using the GNU stuff:

5. CodeWarrior bitfields alignment (compatibility) issue

The Apache binaries produced by the CodeWarrior (currently the only one 
officially supported tool for NetWare builds of the Apache server) are 
affected by an alignment issue (bitfields). It causes incompatibility 
between the core and external modules built with other tools (GNU stuff, 
Watcom, ...).

There is a structure called "uri_components" defined in src/include/util_uri.h:

typedef struct {
//   ...
    unsigned short port;
    unsigned is_initialized:1;
    unsigned dns_looked_up:1;
    unsigned dns_resolved:1;
} uri_components;

... and it is used within a structure called "request_rec" (widely used
by the modules and the core) defined in src/include/httpd.h:

struct request_rec {
//...
    uri_components parsed_uri; /* components of uri, dismantled */
    void *per_dir_config; /* Options set in config files, etc. */
    void *request_config; /* Notes on *this* request */
//...
};*

*An "unsigned short port" element is incorrectly aligned to 4 bytes (should be 2 bytes) and
the following set of bitfields is incorrectly aligned to 4 bytes (should by 1 byte) by CW
compiler => the size of "uri_components" is different (+5 bytes than usual, e.g. if compiling
with gcc), offset to bitfield (the same for all its components) also differ.

Most problems (abends) occur if accessing something below a "parsed_uri" structure element
(typically a "per_dir_config" used by a "ap_get_module_config" macro in some modules).

For more understanding: Here is the latest posting from Guenter Knauf 
taken from the "support.apachebuilds" forum on nntp.wiserlabz.com news 
server, where this issue was discussed:

>>>>>
Hi all,
the following (unofficial) answer I received from Metrowerks support;
I hope that this is NOT the final word......
=========
Hi,

I just got this in, and it looks to be the final word I am going to get.  So
why don't you look this over, (I've left it verbatim) and tell me if this is
acceptable to you.  It looks just like and implementation dependent item
where you should not count on it working the same.

Ron

=========

I agree this is an undesirable way for bitfields to be aligned, but this
agrees with MSVC, upon which we based the bitfield layout.  (In MSVC the
smallest we can make the struct is 4 bytes!)

I think the way to work around this is to change the bitfield base type to
"unsigned char".  The type of the bitfield is used in determining how it is
aligned; thus, using a smaller type will require a smaller alignment.

P.S.  Remind the developers that this style of bitfield alignment is neither
"correct" or "incorrect" (unless something really bad is happening such as
bitfields overlapping each other or other members of the struct) since
neither ANSI nor C99 define how compilers implement bitfields.  This is
strictly the vendor's decision.
<<<<<

I suggest to fix the problem as described (patch attached), even if it will be considered
as CodeWarrior's bug (and fixed, then) by Metrowerks or not. I've detailedly analyzed the
issue and I see no way how to stay backwardly compatible with this issue, so all binaries
for NetWare platform (Apache core+modules from CVS sources and all "3rd party" external modules
produced with CW) should be re-built after the fix (if it will be commited) - it will not
be possible to mix new NLMs with older Apache core or modules.

I have tested the fix with CW 5.3 and gcc 2.95.3 and it seems that alignment of problematic
structures is the same (it differs from current status quo, of course). The change in the
source file shared on all platforms is requested, so verification on these ones will be needed.
I don't expect problems (no change in alignment) on platforms where the GNU stuff is used
(gcc). Thanks.

Regards,
Pavel


Mime
View raw message