Chip Bennett wrote:
I did some experimenting, and it appears to me that C (gcc) and DTrace
behave the same way, as long as you compare the executions in the same
addressing mode.
Gcc defaulted to -m32, which pads after the pointer, because the long
long wants to align on a 64 bit boundary. D defaults to 64 bit, so I
used the -32 option and got the same results. The whole structure is 24
bytes, but the fields are 4, 4, 4, and 8.
Using D's default 64 bit mode, and using the -m64 option in gcc, the
structure was still 24 bytes, but the fields were 4, 4, 8, and 8,
because the pointer is now 64 bits wide: no padding.
Weird. I just installed SUNWgcc to compare, and it has the same mapping
as SunStudioExpress.
Maybe there's something more interesting about the full example, where
feeding the same declarations to gcc/SunStudioExpress vs. DTrace has
different results.
Here's a C testcase, which with a 32-bit build shows no padding between
hostname and request_time, but 4 bytes of padding are introduced between
those fields when the same declarations are used in D.
#include <stdio.h>
#include <stddef.h>
/* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
typedef struct apr_pool_t apr_pool_t;
typedef struct conn_rec conn_rec;
typedef struct server_rec server_rec;
typedef struct request_rec request_rec;
typedef long long apr_int64_t;
typedef apr_int64_t apr_time_t;
struct request_rec {
/** The pool associated with the request */
apr_pool_t *pool;
/** The connection to the client */
conn_rec *connection;
/** The virtual host for this request */
server_rec *server;
/** Pointer to the redirected request if this is an external redirect */
request_rec *next;
/** Pointer to the previous request if this is an internal redirect */
request_rec *prev;
/** Pointer to the main request if this is a sub-request
* (see http_request.h) */
request_rec *main;
/* Info about the request itself... we begin with stuff that only
* protocol.c should ever touch...
*/
/** First line of request */
char *the_request;
/** HTTP/0.9, "simple" request (e.g. GET /foo\n w/no headers) */
int assbackwards;
/** A proxy request (calculated during post_read_request/translate_name)
* possible values PROXYREQ_NONE, PROXYREQ_PROXY, PROXYREQ_REVERSE,
* PROXYREQ_RESPONSE
*/
int proxyreq;
/** HEAD request, as opposed to GET */
int header_only;
/** Protocol string, as given to us, or HTTP/0.9 */
char *protocol;
/** Protocol version number of protocol; 1.1 = 1001 */
int proto_num;
/** Host, as set by full URI or Host: */
const char *hostname;
/** Time when the request started */
apr_time_t request_time;
/** Status line, if set by script */
const char *status_line;
/** Status line */
int status;
/* Request method, two ways; also, protocol, etc.. Outside of protocol.c,
* look, but don't touch.
*/
/** Request method (eg. GET, HEAD, POST, etc.) */
const char *method;
/** M_GET, M_POST, etc. */
int method_number;
};
#define SHOW_SIZE(s) \
printf("sizeof(" #s "):\t%d\n", sizeof(s))
#define SHOW_OFFSET(t, f) \
printf("offsetof(" #f "):\t%d\n", offsetof(t, f))
int main(void)
{
SHOW_SIZE(void *);
SHOW_SIZE(request_rec);
SHOW_OFFSET(request_rec, proxyreq);
SHOW_OFFSET(request_rec, proto_num);
SHOW_OFFSET(request_rec, hostname);
SHOW_OFFSET(request_rec, request_time);
SHOW_OFFSET(request_rec, status_line);
SHOW_OFFSET(request_rec, status);
SHOW_OFFSET(request_rec, method);
return 0;
}
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
