June 2008 - Darwin-dev - lists.apple.com

Re: Odd GCC Behavior
by Clark Cox 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=kT4wzd/HeZPHYfsnoKcNhJIyRp27O9s9KzzR8S7mkCY=; b=hos5vaEeVWLLHFlb75tFCRMhH4dFMfgSrfa6mFbZNFrF7utP27vuTtLvrJiNNpEg6r a3I+ektA3eYGLfZIRC15VW2su8YprErphn3xPkKozh1zdxd20W6C1NfEh0Ho8FMBNCXi ycoI+Beug+kkMx6pYEFcGIo361romrMWzYjrc= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=p3SbpZHVlT2d/t9UOIpsr10t0/QBkjWhZ2xw7X+7DoBiERWEbS/aOdR8OcgB552OQv 0gwi+CamIPl4HKYR/vJzRSFaGkYK9am9Pf7iyQg3E1k362yKYp+IXgpXJAuhPjdJaWXT 5yTNOurh5ztpHeEend6xltcTZldOmtRjXBy7Y= On Mon, Jun 30, 2008 at 6:38 AM, J. Aaron Pendergrass <james.pendergrass(a)jhuapl.edu> wrote: > I'm aware that this is undefined. > I did explicitly say that the C spec leaves this unspecified. > But {1,2,7,4} seems like such an odd choice. Especially when looking at the > disassembly: > > lwz r2,56(r30) > addi r2,r2,-8 > lwz r9,0(r2) > lwz r2,56(r30) > addi r0,r2,-4 > stw r0,56(r30) > lwz r2,56(r30) > lwz r0,0(r2) > add r0,r9,r0 > lwz r2,56(r30) > addi r2,r2,-8 > stw r0,0(r2) > > which really seems to be going out of its way to implement a fairly > unintuitive semantics > for this piece of undefined behavior and I was curious what the motivation > behind this behavior might be. With undefined behavior, there is no such thing as an "odd choice". There is no choice to be made. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd GCC Behavior
by Jim Jagielski 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mutt/1.4.2.3i On Mon, Jun 30, 2008 at 09:38:09AM -0400, J. Aaron Pendergrass wrote: > I'm aware that this is undefined. > I did explicitly say that the C spec leaves this unspecified. > But {1,2,7,4} seems like such an odd choice. Well, I don't see the conflict between the result being "an odd choice" with an impl which is undefined and unspecified. Isn't that kind of what undefined/unspecified means? :) -- =========================================================================== Jim Jagielski [|] jim(a)jaguNET.com [|] http://www.jaguNET.com/ "Great is the guilt of an unnecessary war" ~ John Adams _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd GCC Behavior
by J. Aaron Pendergrass 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com lwz r2,56(r30) addi r2,r2,-8 lwz r9,0(r2) lwz r2,56(r30) addi r0,r2,-4 stw r0,56(r30) lwz r2,56(r30) lwz r0,0(r2) add r0,r9,r0 lwz r2,56(r30) addi r2,r2,-8 stw r0,0(r2) -Aaron On Jun 30, 2008, at 9:28 AM, Jim Jagielski wrote: On Jun 30, 2008, at 9:21 AM, J. Aaron Pendergrass wrote: Here's some sample code that demonstrates the behavior: { long stack[4] = {1,2,3,4}; long *sp = test + 4; /* top of stack is at (sp - 1) */ /* add the top of stack to the next element and pop */ *(sp - 2) += *(--sp); } One might expect this to result in a stack like: {1, 2, 7, 4} Actually, one might expect anything since: *(sp - 2) += *(--sp); is really undefined within C... just check out K&R 2.12 for example. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I'm aware that this is undefined. I did explicitly say that the C spec leaves this unspecified. But {1,2,7,4} seems like such an odd choice. Especially when looking at the disassembly: which really seems to be going out of its way to implement a fairly unintuitive semantics for this piece of undefined behavior and I was curious what the motivation behind this behavior might be. Hello list, I just ran into what seems to be fairly peculiar behavior of Apple's GCC (v4.0.1 PPC) that seemed worth pointing out. It is hard to say if it is really a bug since the C spec is fairly non-deterministic, but it is peculiar. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd GCC Behavior
by Jim Jagielski 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jun 30, 2008, at 9:21 AM, J. Aaron Pendergrass wrote: Here's some sample code that demonstrates the behavior: { long stack[4] = {1,2,3,4}; long *sp = test + 4; /* top of stack is at (sp - 1) */ /* add the top of stack to the next element and pop */ *(sp - 2) += *(--sp); } One might expect this to result in a stack like: {1, 2, 7, 4} Actually, one might expect anything since: *(sp - 2) += *(--sp); is really undefined within C... just check out K&R 2.12 for example. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Hello list, I just ran into what seems to be fairly peculiar behavior of Apple's GCC (v4.0.1 PPC) that seemed worth pointing out. It is hard to say if it is really a bug since the C spec is fairly non-deterministic, but it is peculiar. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd GCC Behavior
by Andrew Pinski 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:x-mailer:mime-version:subject :content-transfer-encoding:date:cc; bh=Xjgee/8fyIKMX2DNvb/JFfhrSFFyN4UUdvYDPfg3BP0=; b=MeHkHd78OvdZX+SwQ6A5iezOUzQQ2yREluxV1MXrLyq5n0FHthgQWwwAd2N2VVeZrU mJz73NwoNasKXazN+n//2/+MI2iF9yIscWiGedqjQNnKuqLFsCBQn9iOpE3P+QpQeUyt 99ucANcBCe0tzrQAnGpjw1AzPDomyEUy+/cos= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type:x-mailer :mime-version:subject:content-transfer-encoding:date:cc; b=Tc/zCKJqdTon+p71Nm4cCbP6/Umt00WqJAf10xIsExTjYKT+NZkwNNPsFQJXykwM81 hNYAuaDN5tZeFiZHHRCNV6X94HMH+1iUstVBsNZ0e9mjSffYP8WfsAhj3BCE2hzN83PM +j7vE12eTnIbxaKTgiigdPHJdW0pu2Z/1/0m4= Thanks, Andrew Pinski Sent from my iPhone Here's some sample code that demonstrates the behavior: { long stack[4] = {1,2,3,4}; long *sp = test + 4; /* top of stack is at (sp - 1) */ /* add the top of stack to the next element and pop */ *(sp - 2) += *(--sp); } One might expect this to result in a stack like: {1, 2, 7, 4} {1, 6, 3, 4} But in fact it results in: {1, 7, 3, 4} This just seems bizarre to me. The most bizarre part in my mind is that one might think the program above should be identical to: { long stack[4] = {1,2,3,4} int sp = 4; stack[sp-2] += stack[--sp]; } but this snippet actually results in {1,2,7,4}. Does anyone have insight into this? Thanks, -Aaron _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/pinskia%40gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This code is undefined as you are acessing and modifying a variable with a sequence point inbetween the acess and modification. Try compiling with warnings turned on. -Wsequence-point should get you a warning. On Jun 30, 2008, at 6:21, "J. Aaron Pendergrass" <james.pendergrass(a)jhuapl.edu > wrote: Hello list, I just ran into what seems to be fairly peculiar behavior of Apple's GCC (v4.0.1 PPC) that seemed worth pointing out. It is hard to say if it is really a bug since the C spec is fairly non-deterministic, but it is peculiar. This is the behavior of GNU GCC (v 4.2.3 on Ubuntu x86-32) and Apple GCC (v4.0.1) on Intel. Another reasonable guess might be that the prefix- decrement would be evaluated before the lhs is resolved to a value which should result in: Again, I'm not sure that this is really a bug since the C spec is annoyingly vague about exactly when prefix increment/decrement is supposed to happen. But it seems like it should at least be consistent between the two cases. This email sent to pinskia(a)gmail.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd GCC Behavior
by Andrew Pinski 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:x-mailer:mime-version:subject :content-transfer-encoding:date:cc; bh=hpiIk/HZJiJ5bb5gLfoAwsjSc1fGYA85DXqG0rMp7NA=; b=LnVV7lkXxRmsuPiuPD+jTg4hW+tK/WN4CL/CBiDB2/vZP1EWimC/tHppSJKoEUD9G6 X2xS9gDnqicSM1WquGvD8V6lpUDw9/XoSM14ARTmThAG83OGDWzb/2n30qExCHw19j1K 3tT9/gJgtnpIypq3FJgXJ2rKqtL2nzvR5MkPI= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type:x-mailer :mime-version:subject:content-transfer-encoding:date:cc; b=nvX7CqUXL2NjmhQ8WAxKH0EjjGZM29LG3bkc3Yov6PGyL9zC0puCdUTwxbR3PElNw4 IRSz5Y7W1b7sWzG8ZQCcCJRtcvYxAs/Ms+WQtz0t3Uu2jqgs09S3151YuhouW8nmFQ97 vYI3Nwv8Sk48VO7SxbTkJtoML+Ba3/HNm/d2c= Sent from my iPhone Here's some sample code that demonstrates the behavior: { long stack[4] = {1,2,3,4}; long *sp = test + 4; /* top of stack is at (sp - 1) */ /* add the top of stack to the next element and pop */ *(sp - 2) += *(--sp); } One might expect this to result in a stack like: {1, 2, 7, 4} {1, 6, 3, 4} But in fact it results in: {1, 7, 3, 4} This just seems bizarre to me. The most bizarre part in my mind is that one might think the program above should be identical to: { long stack[4] = {1,2,3,4} int sp = 4; stack[sp-2] += stack[--sp]; } but this snippet actually results in {1,2,7,4}. Does anyone have insight into this? Thanks, -Aaron _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/pinskia%40gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Jun 30, 2008, at 6:21, "J. Aaron Pendergrass" <james.pendergrass(a)jhuapl.edu > wrote: Hello list, I just ran into what seems to be fairly peculiar behavior of Apple's GCC (v4.0.1 PPC) that seemed worth pointing out. It is hard to say if it is really a bug since the C spec is fairly non-deterministic, but it is peculiar. This is the behavior of GNU GCC (v 4.2.3 on Ubuntu x86-32) and Apple GCC (v4.0.1) on Intel. Another reasonable guess might be that the prefix- decrement would be evaluated before the lhs is resolved to a value which should result in: Again, I'm not sure that this is really a bug since the C spec is annoyingly vague about exactly when prefix increment/decrement is supposed to happen. But it seems like it should at least be consistent between the two cases. This email sent to pinskia(a)gmail.com This email sent to site_archiver(a)lists.apple.com

1 0

Odd GCC Behavior
by J. Aaron Pendergrass 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Here's some sample code that demonstrates the behavior: { long stack[4] = {1,2,3,4}; long *sp = test + 4; /* top of stack is at (sp - 1) */ /* add the top of stack to the next element and pop */ *(sp - 2) += *(--sp); } One might expect this to result in a stack like: {1, 2, 7, 4} {1, 6, 3, 4} But in fact it results in: {1, 7, 3, 4} This just seems bizarre to me. The most bizarre part in my mind is that one might think the program above should be identical to: { long stack[4] = {1,2,3,4} int sp = 4; stack[sp-2] += stack[--sp]; } but this snippet actually results in {1,2,7,4}. Does anyone have insight into this? Thanks, -Aaron _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Hello list, I just ran into what seems to be fairly peculiar behavior of Apple's GCC (v4.0.1 PPC) that seemed worth pointing out. It is hard to say if it is really a bug since the C spec is fairly non-deterministic, but it is peculiar. This is the behavior of GNU GCC (v 4.2.3 on Ubuntu x86-32) and Apple GCC (v4.0.1) on Intel. Another reasonable guess might be that the prefix-decrement would be evaluated before the lhs is resolved to a value which should result in: Again, I'm not sure that this is really a bug since the C spec is annoyingly vague about exactly when prefix increment/decrement is supposed to happen. But it seems like it should at least be consistent between the two cases. This email sent to site_archiver(a)lists.apple.com

1 0

Building Python SDK from Darwin sources
by David Geldreich 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi all, I would like to have a Py_DEBUG version of the Python 2.3 SDK. So I : Thanks in advance. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… - got python 2.3 sources from : http://www.opensource.apple.com/darwinsource/10.5/ - modified Makefile : Extra_Configure_Flags = ... --disable-toolbox- glue --with-pydebug - mkdir -p /tmp/python/Debug - make OBJROOT=/tmp/obj SRCROOT=`pwd` DSTROOT=/tmp/python install But then the Headers are not installed in the Python.framework. Is there a way to build "SDK" version of the Framework (vs "runtime" version) ? This email sent to site_archiver(a)lists.apple.com

1 0

RE: USB Mass Storage: command size limits
by Andy Green 27 Jun '08

27 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcjXqjKdl+atJKepQJeMOf9A6CwrHQAynxSwAADaF4A= Thread-topic: USB Mass Storage: command size limits > > Hi Chris, > > let me just check I've got the right end of the stick.... > > > > You should check the IOUSBMassStorageClass code which > allows you to specify keys in the SCSI > > Device Charateristics dictionary including max block count > or max byte count (i.e. you don't > > have to write any code to do this). > > > >> I was wondering if I could tweak this for our > USB device, which can > >> support bigger commands. However it looks like > the traffic is limited by > >> IOBlockStorageDriver. > > > > > > Yes, you can and should. > > > >> How could I change the behaviour of > IOBlockStorageDriver? I can subclass > >> and instantiate IOBlockStorageServices from a > custom LUN driver, but how > >> could I cause a subclass of > IOBlockStorageDriver to be loaded for my > >> device? > > > > > > Refer to the IOUSBMassStorageClass and you can look at > information in AppleStorageDrivers > > plugins that shows how some device overrides enable > different I/O sizes... > > > I've got a working plist that installs a subclass of > IOUSBMassStorageDevice (I know you said I don't have to write > code but it's easier to tell if it matched my plist if I > subclass... I'll change that later). > In the plist I've included the SCSI Device Characteristics > dictionary, containing IOMaximumByteCountRead, > IOMaximumBlockCountRead, IOMaximumByteCountWrite, > IOMaximumBlockCountWrite > > They now appear in IOReg explorer, and are transported up to > the PeripheralDeviceNub and the LUN driver. However they > don't appear in the IOBlockStorageServices object or any > further up the food chain. The IOBlockStorageServices object > also has IOMaximumSegmentCountRead/Write properties set to > 32, which I guess is 128kB. > > Am I on the right track? > A follow-up to previous... This is an excerpt from my pList, with arbitrary numbers for the maxes. The keys look right to me, but in ioreg explorer, the two 'read' keys are duplicated, and the 'write' keys are absent. MacOS 10.4.11, MacPro1,1. Any ideas? <key>OurUSB</key> <dict> <key>CFBundleIdentifier</key> <string>com.us.driver.OurBundle</string> <key>IOClass</key> <string>com_us_USB</string> <key>IOProviderClass</key> <string>IOUSBInterface</string> <key>Physical Interconnect</key> <string>USB</string> <key>Physical Interconnect Location</key> <string>External</string> <key>Read Time Out Duration</key> <integer>30000</integer> <key>Write Time Out Duration</key> <integer>30000</integer> <key>bInterfaceClass</key> <integer>8</integer> <key>bInterfaceSubClass</key> <integer>6</integer> <key>bInterfaceProtocol</key> <integer>80</integer> <key>SCSI Device Characteristics</key> <dict> <key>IOMaximumBlockCountWrite</key> <string>32767</string> <key>IOMaximumByteCountWrite</key> <string>1048576</string> <key>IOMaximumBlockCountRead</key> <string>32767</string> <key>IOMaximumByteCountRead</key> <string>1048576</string> </dict> </dict> _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

RE: USB Mass Storage: command size limits
by Andy Green 27 Jun '08

27 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcjXqjKdl+atJKepQJeMOf9A6CwrHQAynxSw Thread-topic: USB Mass Storage: command size limits Hi Chris, let me just check I've got the right end of the stick.... > You should check the IOUSBMassStorageClass code which allows you to specify keys in the SCSI > Device Charateristics dictionary including max block count or max byte count (i.e. you don't > have to write any code to do this). > >> I was wondering if I could tweak this for our USB device, which can >> support bigger commands. However it looks like the traffic is limited by >> IOBlockStorageDriver. > > > Yes, you can and should. > >> How could I change the behaviour of IOBlockStorageDriver? I can subclass >> and instantiate IOBlockStorageServices from a custom LUN driver, but how >> could I cause a subclass of IOBlockStorageDriver to be loaded for my >> device? > > > Refer to the IOUSBMassStorageClass and you can look at information in AppleStorageDrivers > plugins that shows how some device overrides enable different I/O sizes... I've got a working plist that installs a subclass of IOUSBMassStorageDevice (I know you said I don't have to write code but it's easier to tell if it matched my plist if I subclass... I'll change that later). In the plist I've included the SCSI Device Characteristics dictionary, containing IOMaximumByteCountRead, IOMaximumBlockCountRead, IOMaximumByteCountWrite, IOMaximumBlockCountWrite They now appear in IOReg explorer, and are transported up to the PeripheralDeviceNub and the LUN driver. However they don't appear in the IOBlockStorageServices object or any further up the food chain. The IOBlockStorageServices object also has IOMaximumSegmentCountRead/Write properties set to 32, which I guess is 128kB. Am I on the right track? Cheers, Andy _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0