• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Ancillary data and 32/64 bit processes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ancillary data and 32/64 bit processes


  • Subject: Re: Ancillary data and 32/64 bit processes
  • From: Terry Lambert <email@hidden>
  • Date: Mon, 4 Feb 2008 13:33:43 -0800

On Feb 4, 2008, at 12:20 PM, Michael Tuexen wrote:
Hi Kevin,

see my comments in-line.

Best regards
Michael

On Feb 4, 2008, at 7:18 AM, Kevin Van Vechten wrote:

On Feb 3, 2008, at 11:15 AM, Michael Tuexen wrote:

I habe a problem using ancillary data on 64-bit processes...

The macro CMSG_DATA ist defined in /usr/include/sys/socket.h as

#define CMSG_DATA(cmsg) ((unsigned char *)(cmsg) + \
__DARWIN_ALIGN(sizeof(struct cmsghdr)))


__DARWIN_ALIGN behaves different on 32-bit processes and 64-bit processes.
Therefore the offset of the CMSG_DATA is 12 bytes on 32-bit processes
and 16 byte on 64-bit processes. However, the kernel ignores this difference
and puts the CMSG_DATA at a 12 byte offset.

User processes may be 32-bit or 64-bit, but the kernel always executes in a 32-bit address space.
Yes, that is the cause of the problem.


Therefore programs using ancillary data work, when compiled for 32- bit,
but do not work when compiled for 64-bit.


I can provide a simple UDP discard server which shows this bug.

Is this a known bug?

Please file a bug <http://developer.apple.com/bugreporter/>. Even if it's a known issue, additional reports help us gauge the overall impact of the issue. (A quick check didn't find any issues reported against CMSG_DATA or DARWIN_ALIGN.)
Done, Bug ID# 5723161


Should it be fixed by changing the CMSG_DATA
macros to behave the same on 32-bit and 64-bit processes or should
the kernel be changed to adjust the ancillary data?

I suspect the former, since that would preserve the binary compatibility expectations of 64-bit processes with today's kernel.
OK, sounds fine.


This problem is crucial for our SCTP NKE, which uses ancillary
data a lot...

As a workaround, you could define your own CMSG_DATA macro.
Yes, for the code we write... To enable a programmer to use the macros we need
to patch /usr/include/sys/socket.h...


#pragma pack(4)
struct cmsghdr {
socklen_t cmsg_len; /* [XSI] data byte count, including hdr */
int cmsg_level; /* [XSI] originating protocol */
int cmsg_type; /* [XSI] protocol-specific type */
/* followed by unsigned char cmsg_data[]; */
};
#pragma pack()


You never have an array of cmsghdr, due to cmsg_data[]. If this were strict C99 code, it wouldn't compile in CodeWarrior, which doesn't grok correct C99 syntax, but cmsg_data[] would be there as an unsized array for use with __offsetof() (probably named __cmsg_data[] to keep it out of the POSIX namespace and make it visible to the macros that POSIX requires).

If you don't do the packing, then the offset of the header will differ between the 64 bit user space and the 32 bit kernel space, and you will effectively start 4 bytes late in the 64 bit code, which will still cause you problems.

-- Terry

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Ancillary data and 32/64 bit processes
      • From: Michael Tuexen <email@hidden>
References: 
 >Ancillary data and 32/64 bit processes (From: Michael Tuexen <email@hidden>)
 >Re: Ancillary data and 32/64 bit processes (From: Kevin Van Vechten <email@hidden>)
 >Re: Ancillary data and 32/64 bit processes (From: Michael Tuexen <email@hidden>)

  • Prev by Date: Re: Ancillary data and 32/64 bit processes
  • Next by Date: Re: Ancillary data and 32/64 bit processes
  • Previous by thread: Re: Ancillary data and 32/64 bit processes
  • Next by thread: Re: Ancillary data and 32/64 bit processes
  • Index(es):
    • Date
    • Thread