Marcel,
I ran into an alignment problem on our ARM platform. It showed up as =
corrupt
SDP responses. I traced it back to bt_put_unaligned() in bluetooth.h
The attached patch should fix the problem (it does as far as I can =
tell).
The compiler probably thinks both arguments to memcpy() are aligned and =
so
makes an optimization which breaks the copy (because the destination is =
not
actually aligned). Perhaps this is a compiler bug... I'm using gcc =
3.3.3.
After googling and reading some discussion on the topic it seems that =
it's
probably not a compiler bug. I'll leave that for someone else to decide. =
:)
I know I'm behind on the libs version, but I just had a look in CVS and =
the
code in question is the same.
Look reasonable to you?
Regards,
-Daryl.
--- bluez-libs-2.8/include/bluetooth.h 2004-07-07 21:54:33.000000000 =
-0700
+++ bluez-libs-2.8_mod/include/bluetooth.h 2004-08-09
11:27:04.000000000 -0700
@@ -93,10 +93,14 @@
#define bt_put_unaligned(val, ptr) ((void)( *(ptr) =3D (val) ))
#else
#define bt_get_unaligned(ptr) \
- ({ __typeof__(*(ptr)) __tmp; memcpy(&__tmp, (ptr), sizeof(*(ptr)));
__tmp; })
+ ({ __typeof__(*(ptr)) __tmp; \
+ char *__tmp1 =3D (char *)(ptr); \
+ memcpy(&__tmp, __tmp1, sizeof(*(ptr))); \
+ __tmp; })
#define bt_put_unaligned(val, ptr) \
({ __typeof__(*(ptr)) __tmp =3D (val); \
- memcpy((ptr), &__tmp, sizeof(*(ptr))); \
+ char *__tmp1 =3D (char *)(ptr); \
+ memcpy(__tmp1, &__tmp, sizeof(*(ptr))); \
(void)0; })
#endif
=20
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi David,
> I was overriding CFLAGS when I invoked make, because otherwise other
> stuff (like -m32) gets omitted. Can we do this in acinclude.m4?
>
> - CFLAGS="-Wall -O2"
> + if (test "${CFLAGS}" = ""); then
> + CFLAGS="-Wall -O2"
> + fi
> +
I was thinking of something like that, but actually never included it
until now. Fix is in CVS for libs, utils and hcidump.
> OK. I think I'm not supposed to ship a cvs snapshot -- I have to wait
> for 2.10. But I've isolated just the patch in question and added it into
> the bluez-utils-2.9-2 RPM, with the above change to inherit CFLAGS if
> they're already set.
I will use memmove for unaligned access and release libs and utils
tomorrow or the day after tomorrow. I like to test your unaligned code a
little bit more before making a release with it.
> > I did it this way, but there were reports of Sparc platforms where the
> > resulting binary should be run-tested.
>
> Hmmm. Can I revise my original answer.... don't. If the user asks for
> it, do it. Else don't.
>
> Random behavioural changes based on the characteristics of the system we
> _happen_ to build on today are probably a bad thing. Just build as
> configured and don't try to auto-adapt to _anything_ :)
Don't worry. You still have to use --enable-pie to activate it even if
configure finds out that the compile supports it.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Fri, 2004-08-13 at 11:05 +0200, Marcel Holtmann wrote:
> > You also need -fpic in CFLAGS, I believe.
>
> if this is true, then this makes your patch useless.
I was overriding CFLAGS when I invoked make, because otherwise other
stuff (like -m32) gets omitted. Can we do this in acinclude.m4?
- CFLAGS="-Wall -O2"
+ if (test "${CFLAGS}" = ""); then
+ CFLAGS="-Wall -O2"
+ fi
+
> However after doing some research in this area it seems that I must
> use -fPIE and then link with -pie. This actually only works for
> programs, because libtool don't uses these extra flags.
You can also use -fpic instead of -fPIE, apparently.
> Check out the CVS. The patch for that is already included.
OK. I think I'm not supposed to ship a cvs snapshot -- I have to wait
for 2.10. But I've isolated just the patch in question and added it into
the bluez-utils-2.9-2 RPM, with the above change to inherit CFLAGS if
they're already set.
The SRPM and ppc build are already at
ftp://ftp.uk.linux.org/pub/people/dwmw2/fc2-mac/ and the builds for
other less interesting architectures will turn up in rawhide in the
morning.
> > > What is the best way to detect PIE support in the compiler?
> >
> > I hate myself for saying it, but possibly just test whether you can
> > actually build an executable that way?
>
> I did it this way, but there were reports of Sparc platforms where the
> resulting binary should be run-tested.
Hmmm. Can I revise my original answer.... don't. If the user asks for
it, do it. Else don't.
Random behavioural changes based on the characteristics of the system we
_happen_ to build on today are probably a bad thing. Just build as
configured and don't try to auto-adapt to _anything_ :)
--
dwmw2
On Fri, 2004-08-13 at 11:58 +0200, Marcel Holtmann wrote:
> is it verified that this works with every GCC release? Some people still
> use a 2.95 or older.
Should do -- GCC behaviour w.r.t. packed structures has been that way
for as long as I can remember. A quick test on ARM with 2.95.2 shows
that get_unaligned() seems to do the right thing.
--
dwmw2
Hi David,
> These should do it right on all architectures -- I've checked with a gcc
> hacker and verified that at least the get_unaligned() version does the
> right thing on both FR-V and i386. On FR-V it loads each byte and shifts
> it into place, while on i386 it just loads it.
>
> #define get_unaligned(ptr) \
> ({ \
> struct __attribute__((packed)) { \
> typeof(*(ptr)) __v; \
> } *__p = (ptr); \
> __p->__v; \
> })
>
> #define put_unaligned(ptr, val) \
> do { \
> struct __attribute__((packed)) { \
> typeof(*(ptr)) __v; \
> } *__p = (ptr); \
> __p->__v = (val); \
> } while(0)
is it verified that this works with every GCC release? Some people still
use a 2.95 or older.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Fri, 2004-08-13 at 11:05 +0200, Marcel Holtmann wrote:
> if this is true, then this makes your patch useless. However after doing
> some research in this area it seems that I must use -fPIE and then link
> with -pie. This actually only works for programs, because libtool don't
> uses these extra flags.
>
> Check out the CVS. The patch for that is already included.
OK, thanks. I'll try to put a package through the build system today.
> > > And please don't do this
> > >
> > > # Authentication and Encryption
> > > - #auth enable;
> > > - #encrypt enable;
> > > + auth enable;
> > > + encrypt enable;
> > >
> > > in the bluez-utils-2.3-conf.patch. If you do that then you are going to
> > > set your local device in security mode 3 and this is not what you want.
Thanks for the explanation. I'll turn those off in the next build too.
--
dwmw2
Hi David,
> > I looked at the patches from the bluez-utils source RPM and actually I
> > can include optional PIE support for you. A simple patch for that is
> > easy and actually I already did that. From what I saw, this is a GCC 3.4
> > only feature and you give -pie at linking time and not at compile time
> > of the sources itself. Is this correct?
>
> You also need -fpic in CFLAGS, I believe.
if this is true, then this makes your patch useless. However after doing
some research in this area it seems that I must use -fPIE and then link
with -pie. This actually only works for programs, because libtool don't
uses these extra flags.
Check out the CVS. The patch for that is already included.
> > What is the best way to detect PIE support in the compiler?
>
> I hate myself for saying it, but possibly just test whether you can
> actually build an executable that way?
I did it this way, but there were reports of Sparc platforms where the
resulting binary should be run-tested.
> > And please don't do this
> >
> > # Authentication and Encryption
> > - #auth enable;
> > - #encrypt enable;
> > + auth enable;
> > + encrypt enable;
> >
> > in the bluez-utils-2.3-conf.patch. If you do that then you are going to
> > set your local device in security mode 3 and this is not what you want.
>
> Hmmm, OK.... /me refers to Google and then
> http://www.niksula.cs.hut.fi/~jiitv/bluesec.html
This is a nice page, I know, but it is too theoretical ;)
> Don't I want that? If I were to leave it out, would that leave it in
> mode 1, and mean I wouldn't be required to exchange a PIN with _every_
> device before I can communicate with it at all?
The point here is that setting "auth enable" sets the device into
security mode 3. It is the same with "hciconfig hci0 auth". And you
can't have encryption without authentication and so leave this both
disabled.
Even if the Bluetooth specification talks about three security modes, we
can only differ between mode 3 and mode 1/2 on the device level. This
means that we are in security mode 1 or in mode 2 if you don't set this
options.
The difference between mode 1 and 2 are that in security mode 1 or
device will never initiate the security mechanism, but it will respond
to it if the other device asks. For example a mobile phone.
In security mode 2 the mechanism will be triggerd before the service is
usable. In general these are done by the daemons that implement the
profile. Look at pand and dund for example. This is why it is called
service level security.
The reason behind security mode 1/2 and mode 3 are that in mode 1 and 2
you can request SDP information without authentication, but in security
mode 3 the authentication is enforced right after the link creation on
the HCI level and you must even authenticate for SDP information.
And some device don't really like connections from hosts with security
mode 3. It will work in some way, but it causes more troubles than it is
good for.
> The gnome-bluetooth program has been known to register its OBEX file
> receive service and then just dump stuff into the user's home directory
> -- even files with names like .rhosts :) If I make the requested change,
> would that mean that _anyone_ can exploit this, rather than only devices
> with which we're already paired?
If this is possible, then this is a misdesign in the program. You can't
rely on the Bluetooth security mechanism for everything. Look at the
reports about hacking into a mobile phone. I wrote one of that papers ;)
> Or am I getting confused? Can we do security mode 2?
You can enforce authentication with the correct option to dund and pand
for example. Otherwise we go with security mode 1, but this does not
mean that we never have to authenticate.
> I have a _vague_ recollection that there were devices I couldn't
> communicate with unless I enabled those -- but it was a long time ago
> and perhaps it was just that I thought authentication and encryption
> sounded like good things so I should probably enable them :)
You will be always able to communicate to all devices if you are in
security mode 1/2, but there are some that expect something and you
don't get any feedback. The best example is the Apple keyboard. If
connect to it the first time it expects that you input a PIN on the
numeric keys. If you don't do this in time the connectio is terminated
and you don't see why. Even hcidump don't gives you any clues. You must
know how these devices work. The stupid thing behind this is that Apple
uses security mode 3 for the mouse and the keyboard. And how would you
input a PIN with a mouse. The only other security mode 3 device is the
old Nokia 6210 and that is it. Every other device I have seen so far is
using service based security.
And I never checked this, but I think the CSR based mice don't have a
default PIN or something like that and so you won't be able to connect
these devices (every mice except the Apple one) to a host in security
mode 3. Investigate this before your think about enabling this again.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, 2004-08-12 at 15:36 +0200, Marcel Holtmann wrote:
> I looked at the patches from the bluez-utils source RPM and actually I
> can include optional PIE support for you. A simple patch for that is
> easy and actually I already did that. From what I saw, this is a GCC 3.4
> only feature and you give -pie at linking time and not at compile time
> of the sources itself. Is this correct?
You also need -fpic in CFLAGS, I believe.
> What is the best way to detect PIE support in the compiler?
I hate myself for saying it, but possibly just test whether you can
actually build an executable that way?
> And please don't do this
>
> # Authentication and Encryption
> - #auth enable;
> - #encrypt enable;
> + auth enable;
> + encrypt enable;
>
> in the bluez-utils-2.3-conf.patch. If you do that then you are going to
> set your local device in security mode 3 and this is not what you want.
Hmmm, OK.... /me refers to Google and then
http://www.niksula.cs.hut.fi/~jiitv/bluesec.html
Don't I want that? If I were to leave it out, would that leave it in
mode 1, and mean I wouldn't be required to exchange a PIN with _every_
device before I can communicate with it at all?
The gnome-bluetooth program has been known to register its OBEX file
receive service and then just dump stuff into the user's home directory
-- even files with names like .rhosts :) If I make the requested change,
would that mean that _anyone_ can exploit this, rather than only devices
with which we're already paired?
Or am I getting confused? Can we do security mode 2?
I have a _vague_ recollection that there were devices I couldn't
communicate with unless I enabled those -- but it was a long time ago
and perhaps it was just that I thought authentication and encryption
sounded like good things so I should probably enable them :)
--
dwmw2
Hi David,
> > is it worth to include such a patch and make it optional?
>
> Yes, I suspect it would. I'll have a look at it when I get a spare
> moment and offer you a patch.
I looked at the patches from the bluez-utils source RPM and actually I
can include optional PIE support for you. A simple patch for that is
easy and actually I already did that. From what I saw, this is a GCC 3.4
only feature and you give -pie at linking time and not at compile time
of the sources itself. Is this correct? What is the best way to detect
PIE support in the compiler?
And please don't do this
# Authentication and Encryption
- #auth enable;
- #encrypt enable;
+ auth enable;
+ encrypt enable;
in the bluez-utils-2.3-conf.patch. If you do that then you are going to
set your local device in security mode 3 and this is not what you want.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, 2004-08-12 at 12:22 +0200, Marcel Holtmann wrote:
> For now I will use memmove, but we need clarification on this. I lost my
> Sun Ultra system, so I can't do any tests.
>
> Please send me the additional compiler defines for architectures that
> can do unaligned access by themself.
These should do it right on all architectures -- I've checked with a gcc
hacker and verified that at least the get_unaligned() version does the
right thing on both FR-V and i386. On FR-V it loads each byte and shifts
it into place, while on i386 it just loads it.
#define get_unaligned(ptr) \
({ \
struct __attribute__((packed)) { \
typeof(*(ptr)) __v; \
} *__p = (ptr); \
__p->__v; \
})
#define put_unaligned(ptr, val) \
do { \
struct __attribute__((packed)) { \
typeof(*(ptr)) __v; \
} *__p = (ptr); \
__p->__v = (val); \
} while(0)
--
dwmw2
Hi David,
> > The loading of the firmware for the 3Com PCMCIA card and the BlueFRITZ!
> > USB dongle are done through request_firmware(). The Broadcom based
> > dongles are an exception. I personal prefer to use the bcm203x kernel
> > driver for loading the firmware, but this is a 2.6 only feature.
>
> 2.6-only is _fine_. Isn't 2.4 dead yet? I'll make sure we build the
> bcm203x driver and just drop bluez-bluefw.
I don't know if 2.4 is dead, but I think for Fedora Core it makes sense
only to package up bluez-firmware and don't compile and install bcm203x
tool from bluez-utils. Actually this is what SuSE did.
> > The bluez-firmware package only contains the Broadcom firmware files and
> > it will install them by default under /lib/firmware. You need a modified
> > firmware.agent script that also looks for firmware files in that place.
> > We agreed on that path, but this change is not upstream at the moment.
> > Check the Debian packages for an example of a modified script.
>
> The standard place to put firmware files is /usr/lib/hotplug/firmware
> isn't it? Is there a reason for using a different path? Can you
> elaborate on the meaning of 'We' in the above context?
The problem with that path was if you need the firmware before /usr is
mounted and so we decided to use /lib/firmware.
This is the thread about it on the linux-hotplug mailing list:
http://sourceforge.net/mailarchive/message.php?msg_id=8064672
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, 2004-08-12 at 13:49 +0200, Marcel Holtmann wrote:
> is it worth to include such a patch and make it optional?
Yes, I suspect it would. I'll have a look at it when I get a spare
moment and offer you a patch.
> The loading of the firmware for the 3Com PCMCIA card and the BlueFRITZ!
> USB dongle are done through request_firmware(). The Broadcom based
> dongles are an exception. I personal prefer to use the bcm203x kernel
> driver for loading the firmware, but this is a 2.6 only feature.
2.6-only is _fine_. Isn't 2.4 dead yet? I'll make sure we build the
bcm203x driver and just drop bluez-bluefw.
> The bluez-firmware package only contains the Broadcom firmware files and
> it will install them by default under /lib/firmware. You need a modified
> firmware.agent script that also looks for firmware files in that place.
> We agreed on that path, but this change is not upstream at the moment.
> Check the Debian packages for an example of a modified script.
The standard place to put firmware files is /usr/lib/hotplug/firmware
isn't it? Is there a reason for using a different path? Can you
elaborate on the meaning of 'We' in the above context?
> I think it is too late for Debian Sarge and SuSE 9.2 and maybe even for
> Fedora Core 3, but actually we should really talk about it.
OK... well what I've done is split into four separate init scripts, each
of which can be separately enabled or disabled with chkconfig or
whichever pretty tool the user likes for selecting which services are
run in each runlevel. I have removed dund, hidd and pand into their own
scripts. As I said, I'd like to remove the need for running pand as a
daemon like that anyway -- it should be handled by the network
ifup/ifdown scripts like pppd is. I have never really looked at dund but
I suspect the same goes for that.
--
dwmw2
Hi David,
> > I am not familiar with PIE. Is it correct that it stands for "position
> > independent executables"?
>
> Indeed -- and that's about as much as I know too, I'm afraid. It's to
> allow random load addresses, to reduce the chance of successful buffer
> overflow attacks -- if the executable is loaded at a random address, you
> don't have known functions at known addresses which the shellcode can
> call. I think.
is it worth to include such a patch and make it optional?
> > Looks fine so far. I hope you checked the new --enable commands in
> > bluez-utils-2.9, because I made many stuff optional.
>
> Briefly. I think I enabled everything, and made a note to look closer at
> the firmware stuff.
I put myself an --enable-all option in for testing ;)
> > The bluez-bluefw is deprecated. Please use bluez-firmware instead and
> > enable bcm203x program in bluez-utils if you need it (for 2.4 kernels
> > only). Splitting up a bluez-utils-bcm203x could be useful.
>
> I looked very briefly at that -- does it also support loading firmware
> in the PCMCIA cards? Is this the future instead of request_firmware()?
> Why so?
The loading of the firmware for the 3Com PCMCIA card and the BlueFRITZ!
USB dongle are done through request_firmware(). The Broadcom based
dongles are an exception. I personal prefer to use the bcm203x kernel
driver for loading the firmware, but this is a 2.6 only feature. You can
also load the firmware with a userspace program. The bluefw was too
messy to stay any time longer and so I rewrote it to only support the
Broadcom dongles and the result is the bcm203x tool.
The bluez-firmware package only contains the Broadcom firmware files and
it will install them by default under /lib/firmware. You need a modified
firmware.agent script that also looks for firmware files in that place.
We agreed on that path, but this change is not upstream at the moment.
Check the Debian packages for an example of a modified script.
> > Actually even Debian and SuSE ship other init scripts and that is fine
> > for me. Do you think a --disable-initscripts option would make the life
> > of the package maintainers easier?
>
> I don't think it makes a lot of difference, to be honest -- although if
> so many distributions are shipping separate initscripts perhaps we
> should collaborate a bit more closely?
I think it is too late for Debian Sarge and SuSE 9.2 and maybe even for
Fedora Core 3, but actually we should really talk about it.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, 2004-08-12 at 13:00 +0200, Marcel Holtmann wrote:
> I am not familiar with PIE. Is it correct that it stands for "position
> independent executables"?
Indeed -- and that's about as much as I know too, I'm afraid. It's to
allow random load addresses, to reduce the chance of successful buffer
overflow attacks -- if the executable is loaded at a random address, you
don't have known functions at known addresses which the shellcode can
call. I think.
> Do you have a link to the source and binary RPM's for me?
http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/SRPMS/
http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/
> Looks fine so far. I hope you checked the new --enable commands in
> bluez-utils-2.9, because I made many stuff optional.
Briefly. I think I enabled everything, and made a note to look closer at
the firmware stuff.
> The bluez-bluefw is deprecated. Please use bluez-firmware instead and
> enable bcm203x program in bluez-utils if you need it (for 2.4 kernels
> only). Splitting up a bluez-utils-bcm203x could be useful.
I looked very briefly at that -- does it also support loading firmware
in the PCMCIA cards? Is this the future instead of request_firmware()?
Why so?
> Actually even Debian and SuSE ship other init scripts and that is fine
> for me. Do you think a --disable-initscripts option would make the life
> of the package maintainers easier?
I don't think it makes a lot of difference, to be honest -- although if
so many distributions are shipping separate initscripts perhaps we
should collaborate a bit more closely?
> > /me shudders. Autocrap considered harmful. You break cross-compilation
> > if you try to do that. I'd much prefer just to write portable code.
>
> You are right. I forgot to think about cross-compilation.
Users of autoconf often do -- when porting the distro to embedded
machines and trying to cross-build it, autoconf was the single largest
problem I encountered.
--
dwmw2
Hi David,
> > btw what is the status of BlueZ for Fedora Core. Currently I know the
> > status of them for Debian and SuSE. Are there any extra patches that I
> > must know of?
>
> We have a patch to make various daemons build PIE and we mangle the
> defaults in some config files -- other than that nothing interesting. I
> went through it all quite recently and made sure you had the one or two
> other patches that made sense.
I am not familiar with PIE. Is it correct that it stands for "position
independent executables"?
Do you have a link to the source and binary RPM's for me?
> > How do you split the bluez-utils into different packages?
>
> We have these packages:
> bluez-bluefw-1.0-5.ppc.rpm
> bluez-hcidump-1.10-1.ppc.rpm
> bluez-libs-2.9-1.ppc.rpm
> bluez-libs-devel-2.9-1.ppc.rpm
> bluez-pin-0.23-2.ppc.rpm
> bluez-utils-2.9-1.ppc.rpm
> bluez-utils-cups-2.9-1.ppc.rpm
Looks fine so far. I hope you checked the new --enable commands in
bluez-utils-2.9, because I made many stuff optional.
The bluez-bluefw is deprecated. Please use bluez-firmware instead and
enable bcm203x program in bluez-utils if you need it (for 2.4 kernels
only). Splitting up a bluez-utils-bcm203x could be useful.
> We do split the bluez-utils init scripts up, as discussed a few weeks
> ago. I have patches outstanding for initscripts which make 'ifup bnep0'
> responsible for starting pand, to make it just like a normal interface
> -- even pppd is started that way, not by an initscript.
Actually even Debian and SuSE ship other init scripts and that is fine
for me. Do you think a --disable-initscripts option would make the life
of the package maintainers easier?
> > > Autocrap considered harmful; I'd rather let the compiler do it.
> >
> > Actually I meant to let autoconf compile some test code, then run it and
> > analyse that result.
>
> /me shudders. Autocrap considered harmful. You break cross-compilation
> if you try to do that. I'd much prefer just to write portable code.
You are right. I forgot to think about cross-compilation.
> > For now I will use memmove, but we need clarification on this. I lost my
> > Sun Ultra system, so I can't do any tests.
>
> We keep our compiler-dudes in the US mostly so they're sleeping. I'll
> poke one when they wake up.
That would be great.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, 2004-08-12 at 12:22 +0200, Marcel Holtmann wrote:
> btw what is the status of BlueZ for Fedora Core. Currently I know the
> status of them for Debian and SuSE. Are there any extra patches that I
> must know of?
We have a patch to make various daemons build PIE and we mangle the
defaults in some config files -- other than that nothing interesting. I
went through it all quite recently and made sure you had the one or two
other patches that made sense.
> How do you split the bluez-utils into different packages?
We have these packages:
bluez-bluefw-1.0-5.ppc.rpm
bluez-hcidump-1.10-1.ppc.rpm
bluez-libs-2.9-1.ppc.rpm
bluez-libs-devel-2.9-1.ppc.rpm
bluez-pin-0.23-2.ppc.rpm
bluez-utils-2.9-1.ppc.rpm
bluez-utils-cups-2.9-1.ppc.rpm
We do split the bluez-utils init scripts up, as discussed a few weeks
ago. I have patches outstanding for initscripts which make 'ifup bnep0'
responsible for starting pand, to make it just like a normal interface
-- even pppd is started that way, not by an initscript.
> > Autocrap considered harmful; I'd rather let the compiler do it.
>
> Actually I meant to let autoconf compile some test code, then run it and
> analyse that result.
/me shudders. Autocrap considered harmful. You break cross-compilation
if you try to do that. I'd much prefer just to write portable code.
> For now I will use memmove, but we need clarification on this. I lost my
> Sun Ultra system, so I can't do any tests.
We keep our compiler-dudes in the US mostly so they're sleeping. I'll
poke one when they wake up.
--
dwmw2
Hi Steve,
> > I am not an expert when it comes to specific compiler stuff and I can't
> > make the best decision with my limited information. What I realized is
> > that we need our own unaligned access implementation, because we can't
> > rely on the asm/unaligned.h. So I started to put our own in bluetooth.h
> > for general access. If this was wrong, please correct me.
>
> I don't think this is wrong, in the absence of a system-supplied one.
> This is the basic problem if you ask me: <asm/unaligned.h> _should_ be a
> user-space header file (provided by glibc or something) because
> unaligned access _is_ something that people who write network programs
> need.
I must agree, but it seems that nobody provides a generic include for
unaligned access. So we don't have a choise at the moment :(
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi David,
> > I am not an expert when it comes to specific compiler stuff and I can't
> > make the best decision with my limited information. What I realized is
> > that we need our own unaligned access implementation, because we can't
> > rely on the asm/unaligned.h. So I started to put our own in bluetooth.h
> > for general access. If this was wrong, please correct me.
>
> No, that was entirely correct. I may even have prodded you to do it
> after packaging bluez-utils for all the Fedora architectures.
btw what is the status of BlueZ for Fedora Core. Currently I know the
status of them for Debian and SuSE. Are there any extra patches that I
must know of? How do you split the bluez-utils into different packages?
> > Some platforms can do unaligned access by themself and some are not. At
> > the moment only the i386 is listed, but we should list others like AMD64
> > and PowerPC. Patches and hints are welcome. For the rest the generic way
> > is to use memcpy, but actually every architecture uses memmove, because
> > of the GCC __builtin_memcpy problem. Some of them like Alpha and ARM are
> > using specific implementations, but using the macro with memmove seems
> > also to work fine there. I like to keep the unaligned macros as short as
> > possible.
> >
> > Do anyone wrote an autoconf macro for checking if memmove works like
> > expected or if it gets optimized by the compiler?
>
> Autocrap considered harmful; I'd rather let the compiler do it.
Actually I meant to let autoconf compile some test code, then run it and
analyse that result.
> The reason the compiler isn't doing what you want with memcpy is because
> it 'knows' the source pointer is aligned, because it was a pointer to,
> for example, an int, and it knows that such pointers have certain
> alignment. You need to stop the compiler from 'knowing' that. Ways of
> achieving this include __attribute__((packed)) -- you could try
> something like this:
>
> #define put_unaligned(ptr, val) { \
> struct { typeof(*ptr) __v } __attribute__((packed)) __p; \
> __p = (void *)(ptr); \
> __p->__v = (val); \
> }
>
> Now gcc will know that the object '__v' it's loading from the packed
> structure may not be aligned, and it should emit code optimal for the
> architecture in question.
>
> The above was typed into the email -- it probably won't even compile,
> let alone work. But variations on the theme should work. In fact I'm not
> entirely sure we even need the structure -- we might be able to get away
> with
> (typeof (*ptr)) *__p __attribute__((packed));
> *__p = (val);
For now I will use memmove, but we need clarification on this. I lost my
Sun Ultra system, so I can't do any tests.
Please send me the additional compiler defines for architectures that
can do unaligned access by themself.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Thu, 2004-08-12 at 10:27, Marcel Holtmann wrote:
> Hi David,
>
> > > this is what the Linux kernel is using and we will notice it if some
> > > compiler version will optimize it in future. I committed that change to
> > > CVS.
> >
> > The Linux kernel isn't the best example to follow when it comes to
> > relying on undocumented and unguaranteed compiler behaviour. Don't be so
> > sure the kernel would notice -- we have to fix up alignment trap in the
> > kernel _anyway_ so the use of get_unaligned() is only an optimisation
> > there.
> >
> > I'd be more inclined to play with using char * pointers in the memcpy,
> > and/or __attribute__((packed)).
>
> I am not an expert when it comes to specific compiler stuff and I can't
> make the best decision with my limited information. What I realized is
> that we need our own unaligned access implementation, because we can't
> rely on the asm/unaligned.h. So I started to put our own in bluetooth.h
> for general access. If this was wrong, please correct me.
I don't think this is wrong, in the absence of a system-supplied one.
This is the basic problem if you ask me: <asm/unaligned.h> _should_ be a
user-space header file (provided by glibc or something) because
unaligned access _is_ something that people who write network programs
need.
Later,
Steve
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
On Thu, 2004-08-12 at 11:27 +0200, Marcel Holtmann wrote:
> I am not an expert when it comes to specific compiler stuff and I can't
> make the best decision with my limited information. What I realized is
> that we need our own unaligned access implementation, because we can't
> rely on the asm/unaligned.h. So I started to put our own in bluetooth.h
> for general access. If this was wrong, please correct me.
No, that was entirely correct. I may even have prodded you to do it
after packaging bluez-utils for all the Fedora architectures.
> Some platforms can do unaligned access by themself and some are not. At
> the moment only the i386 is listed, but we should list others like AMD64
> and PowerPC. Patches and hints are welcome. For the rest the generic way
> is to use memcpy, but actually every architecture uses memmove, because
> of the GCC __builtin_memcpy problem. Some of them like Alpha and ARM are
> using specific implementations, but using the macro with memmove seems
> also to work fine there. I like to keep the unaligned macros as short as
> possible.
>
> Do anyone wrote an autoconf macro for checking if memmove works like
> expected or if it gets optimized by the compiler?
Autocrap considered harmful; I'd rather let the compiler do it.
The reason the compiler isn't doing what you want with memcpy is because
it 'knows' the source pointer is aligned, because it was a pointer to,
for example, an int, and it knows that such pointers have certain
alignment. You need to stop the compiler from 'knowing' that. Ways of
achieving this include __attribute__((packed)) -- you could try
something like this:
#define put_unaligned(ptr, val) { \
struct { typeof(*ptr) __v } __attribute__((packed)) __p; \
__p = (void *)(ptr); \
__p->__v = (val); \
}
Now gcc will know that the object '__v' it's loading from the packed
structure may not be aligned, and it should emit code optimal for the
architecture in question.
The above was typed into the email -- it probably won't even compile,
let alone work. But variations on the theme should work. In fact I'm not
entirely sure we even need the structure -- we might be able to get away
with
(typeof (*ptr)) *__p __attribute__((packed));
*__p = (val);
--
dwmw2
Hi David,
> > this is what the Linux kernel is using and we will notice it if some
> > compiler version will optimize it in future. I committed that change to
> > CVS.
>
> The Linux kernel isn't the best example to follow when it comes to
> relying on undocumented and unguaranteed compiler behaviour. Don't be so
> sure the kernel would notice -- we have to fix up alignment trap in the
> kernel _anyway_ so the use of get_unaligned() is only an optimisation
> there.
>
> I'd be more inclined to play with using char * pointers in the memcpy,
> and/or __attribute__((packed)).
I am not an expert when it comes to specific compiler stuff and I can't
make the best decision with my limited information. What I realized is
that we need our own unaligned access implementation, because we can't
rely on the asm/unaligned.h. So I started to put our own in bluetooth.h
for general access. If this was wrong, please correct me.
Some platforms can do unaligned access by themself and some are not. At
the moment only the i386 is listed, but we should list others like AMD64
and PowerPC. Patches and hints are welcome. For the rest the generic way
is to use memcpy, but actually every architecture uses memmove, because
of the GCC __builtin_memcpy problem. Some of them like Alpha and ARM are
using specific implementations, but using the macro with memmove seems
also to work fine there. I like to keep the unaligned macros as short as
possible.
Do anyone wrote an autoconf macro for checking if memmove works like
expected or if it gets optimized by the compiler?
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2004-08-11 at 21:31 +0200, Marcel Holtmann wrote:
> this is what the Linux kernel is using and we will notice it if some
> compiler version will optimize it in future. I committed that change to
> CVS.
The Linux kernel isn't the best example to follow when it comes to
relying on undocumented and unguaranteed compiler behaviour. Don't be so
sure the kernel would notice -- we have to fix up alignment trap in the
kernel _anyway_ so the use of get_unaligned() is only an optimisation
there.
I'd be more inclined to play with using char * pointers in the memcpy,
and/or __attribute__((packed)).
--
dwmw2
Hi David,
> > Why are these macros even here? ISTR Max having some reason not to use
> > <asm/unaligned.h> but surely that's what it's there for...
>
> No, asm/unaligned.h is there for kernel code only.
the rule is to not include headers from the kernel source code in any
user space program or library. Even if some people try to bend this rule
I will follow as much as I can.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Daryl,
> Actually just using memmove instead of memcpy was the first thing I tried
> that worked. Someone else here suggested that.
>
> But I thought I read somewhere that the compiler is allowed to optimize
> memmove in the same way. Though I don't know if gcc ever does (and
> apparently it doesn't in this case). But if it is allowed to, then some
> future version of gcc may. Perhaps I misread it.
this is what the Linux kernel is using and we will notice it if some
compiler version will optimize it in future. I committed that change to
CVS.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
Actually just using memmove instead of memcpy was the first thing I tried
that worked. Someone else here suggested that.
But I thought I read somewhere that the compiler is allowed to optimize
memmove in the same way. Though I don't know if gcc ever does (and
apparently it doesn't in this case). But if it is allowed to, then some
future version of gcc may. Perhaps I misread it.
-Daryl.
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Marcel Holtmann
> Sent: August 11, 2004 12:13 AM
> To: Daryl Van Vorst
> Cc: 'BlueZ Mailing List'
> Subject: Re: [Bluez-devel] Alignment issue
>
>
> Hi Daryl,
>
> > The attached patch should fix the problem (it does as far
> as I can tell).
> > The compiler probably thinks both arguments to memcpy() are
> aligned and so
> > makes an optimization which breaks the copy (because the
> destination is not
> > actually aligned). Perhaps this is a compiler bug... I'm
> using gcc 3.3.3.
> > After googling and reading some discussion on the topic it
> seems that it's
> > probably not a compiler bug. I'll leave that for someone
> else to decide. :)
>
> after checking some more resources, you may be right and the compiler
> optimizes here where it should not. I found a comment about gcc and
> using its __builtin_memcpy. Try to replace the memcpy with memmove and
> see if this works.
>
> --- bluetooth.h 2004/07/04 15:38:11 1.14
> +++ bluetooth.h 2004/08/11 07:07:12 1.15
> @@ -93,10 +93,10 @@ enum {
> #define bt_put_unaligned(val, ptr) ((void)( *(ptr) = (val) ))
> #else
> #define bt_get_unaligned(ptr) \
> - ({ __typeof__(*(ptr)) __tmp; memcpy(&__tmp, (ptr),
> sizeof(*(ptr))); __tmp; })
> + ({ __typeof__(*(ptr)) __tmp; memmove(&__tmp, (ptr),
> sizeof(*(ptr))); __tmp; })
> #define bt_put_unaligned(val, ptr) \
> ({ __typeof__(*(ptr)) __tmp = (val); \
> - memcpy((ptr), &__tmp, sizeof(*(ptr))); \
> + memmove((ptr), &__tmp, sizeof(*(ptr))); \
> (void)0; })
> #endif
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
On Wed, 2004-08-11 at 10:20 +0100, Stephen Crane wrote:
> Why are these macros even here? ISTR Max having some reason not to use
> <asm/unaligned.h> but surely that's what it's there for...
No, asm/unaligned.h is there for kernel code only.
--
dwmw2
Hi Daryl, Marcel,
On Wed, 2004-08-11 at 00:12, Marcel Holtmann wrote:
> Hi Daryl,
>
> > I ran into an alignment problem on our ARM platform. It showed up as corrupt
> > SDP responses. I traced it back to bt_put_unaligned() in bluetooth.h
> >
> > The attached patch should fix the problem (it does as far as I can tell).
> > The compiler probably thinks both arguments to memcpy() are aligned and so
> > makes an optimization which breaks the copy (because the destination is not
> > actually aligned). Perhaps this is a compiler bug... I'm using gcc 3.3.3.
> > After googling and reading some discussion on the topic it seems that it's
> > probably not a compiler bug. I'll leave that for someone else to decide. :)
>
> I am not an expert in this area. I thought that this method of getting
> unaligned support was compatible accross the platforms. Looking at the
> kernel unaligned for ARM shows me that this is actually more different.
> I need verification of that patch with GCC 2.95 and from PowerPC and
> SPARC platforms. I would do it by myself for SPARC, but the harddrive of
> my Sun machine is dead.
Why are these macros even here? ISTR Max having some reason not to use
<asm/unaligned.h> but surely that's what it's there for...
Steve
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
Hi Daryl,
> The attached patch should fix the problem (it does as far as I can tell).
> The compiler probably thinks both arguments to memcpy() are aligned and so
> makes an optimization which breaks the copy (because the destination is not
> actually aligned). Perhaps this is a compiler bug... I'm using gcc 3.3.3.
> After googling and reading some discussion on the topic it seems that it's
> probably not a compiler bug. I'll leave that for someone else to decide. :)
after checking some more resources, you may be right and the compiler
optimizes here where it should not. I found a comment about gcc and
using its __builtin_memcpy. Try to replace the memcpy with memmove and
see if this works.
--- bluetooth.h 2004/07/04 15:38:11 1.14
+++ bluetooth.h 2004/08/11 07:07:12 1.15
@@ -93,10 +93,10 @@ enum {
#define bt_put_unaligned(val, ptr) ((void)( *(ptr) = (val) ))
#else
#define bt_get_unaligned(ptr) \
- ({ __typeof__(*(ptr)) __tmp; memcpy(&__tmp, (ptr), sizeof(*(ptr))); __tmp; })
+ ({ __typeof__(*(ptr)) __tmp; memmove(&__tmp, (ptr), sizeof(*(ptr))); __tmp; })
#define bt_put_unaligned(val, ptr) \
({ __typeof__(*(ptr)) __tmp = (val); \
- memcpy((ptr), &__tmp, sizeof(*(ptr))); \
+ memmove((ptr), &__tmp, sizeof(*(ptr))); \
(void)0; })
#endif
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Daryl,
> I ran into an alignment problem on our ARM platform. It showed up as corrupt
> SDP responses. I traced it back to bt_put_unaligned() in bluetooth.h
>
> The attached patch should fix the problem (it does as far as I can tell).
> The compiler probably thinks both arguments to memcpy() are aligned and so
> makes an optimization which breaks the copy (because the destination is not
> actually aligned). Perhaps this is a compiler bug... I'm using gcc 3.3.3.
> After googling and reading some discussion on the topic it seems that it's
> probably not a compiler bug. I'll leave that for someone else to decide. :)
I am not an expert in this area. I thought that this method of getting
unaligned support was compatible accross the platforms. Looking at the
kernel unaligned for ARM shows me that this is actually more different.
I need verification of that patch with GCC 2.95 and from PowerPC and
SPARC platforms. I would do it by myself for SPARC, but the harddrive of
my Sun machine is dead.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sun, 2005-01-23 at 16:22 +0100, Marcel Holtmann wrote:
> and what is the prefered one? I would use __typeof__, because the
> previous version did so. However I am not a compiler expert.
It doesn't matter. I prefer the one without underscores.
--
dwmw2
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi David,
> > patch is now in the CVS and everything seems fine again. Btw what is the
> > difference between typeof and __typeof__. The latter one is used by the
> > previous macro and you used the other?
>
> There's no difference. It's just like 'inline' and '__inline__'.
and what is the prefered one? I would use __typeof__, because the
previous version did so. However I am not a compiler expert.
> > Fine with me, but then I simply replace it with bt_{get|put}unaligned
> > and remove the complete stuff. There is no external user
> > sdp_interal.h.
All done by now :)
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sun, 2005-01-23 at 15:40 +0100, Marcel Holtmann wrote:
> patch is now in the CVS and everything seems fine again. Btw what is the
> difference between typeof and __typeof__. The latter one is used by the
> previous macro and you used the other?
There's no difference. It's just like 'inline' and '__inline__'.
> Fine with me, but then I simply replace it with bt_{get|put}unaligned
> and remove the complete stuff. There is no external user
> sdp_interal.h.
Even better.
--
dwmw2
Hi David,
> > your patch results in a lot of "initialization from incompatible
> > pointer type" errors in the utils and hcidump. Basically in
> > conjunction with functions like ntohs() etc. How do we fix this?
>
> Mea culpa... forgot to cast when we deliberately use an integer pointer
> as a pointer to our packed structure containing the same type of int.
patch is now in the CVS and everything seems fine again. Btw what is the
difference between typeof and __typeof__. The latter one is used by the
previous macro and you used the other?
> We might as well also switch sdp_internal.h to use the same macros while
> we're at it.
Fine with me, but then I simply replace it with bt_{get|put}unaligned
and remove the complete stuff. There is no external user sdp_interal.h.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sun, 2005-01-23 at 12:39 +0100, Marcel Holtmann wrote:
> your patch results in a lot of "initialization from incompatible
> pointer type" errors in the utils and hcidump. Basically in
> conjunction with functions like ntohs() etc. How do we fix this?
Mea culpa... forgot to cast when we deliberately use an integer pointer
as a pointer to our packed structure containing the same type of int.
We might as well also switch sdp_internal.h to use the same macros while
we're at it.
Index: include/bluetooth.h
===================================================================
RCS file: /cvsroot/bluez/libs/include/bluetooth.h,v
retrieving revision 1.18
diff -u -r1.18 bluetooth.h
--- include/bluetooth.h 20 Jan 2005 18:14:19 -0000 1.18
+++ include/bluetooth.h 23 Jan 2005 12:26:50 -0000
@@ -92,7 +92,7 @@
({ \
struct __attribute__((packed)) { \
typeof(*(ptr)) __v; \
- } *__p = (ptr); \
+ } *__p = (void *)(ptr); \
__p->__v; \
})
@@ -100,7 +100,7 @@
do { \
struct __attribute__((packed)) { \
typeof(*(ptr)) __v; \
- } *__p = (ptr); \
+ } *__p = (void *)(ptr); \
__p->__v = (val); \
} while(0)
Index: include/sdp_internal.h
===================================================================
RCS file: /cvsroot/bluez/libs/include/sdp_internal.h,v
retrieving revision 1.3
diff -u -r1.3 sdp_internal.h
--- include/sdp_internal.h 3 Apr 2004 09:21:06 -0000 1.3
+++ include/sdp_internal.h 23 Jan 2005 12:26:50 -0000
@@ -55,102 +55,8 @@
#define SDP_UUID_SEQ_SIZE 256
#define SDP_MAX_ATTR_LEN 65535
-/*
- * SDP unaligned access.
- * based on linux/asm-<arch>/unaligned.h
- */
-#if defined(__i386__)
-
-#define sdp_get_unaligned(ptr) (*(ptr))
-#define sdp_put_unaligned(val, ptr) ((void)( *(ptr) = (val) ))
-
-#else
-
-struct __una_u64 { uint64_t x; } __attribute__((packed));
-struct __una_u32 { uint32_t x; } __attribute__((packed));
-struct __una_u16 { uint16_t x; } __attribute__((packed));
-
-static inline unsigned long long __uldq(const unsigned long *r11)
-{
- const struct __una_u64 *ptr = (const struct __una_u64 *) r11;
- return ptr->x;
-}
-
-static inline unsigned long __uldl(const unsigned int * r11)
-{
- const struct __una_u32 *ptr = (const struct __una_u32 *) r11;
- return ptr->x;
-}
-
-static inline unsigned long __uldw(const unsigned short * r11)
-{
- const struct __una_u16 *ptr = (const struct __una_u16 *) r11;
- return ptr->x;
-}
-
-static inline void __ustq(unsigned long r5, unsigned long * r11)
-{
- struct __una_u64 *ptr = (struct __una_u64 *) r11;
- ptr->x = r5;
-}
-
-static inline void __ustl(unsigned long r5, unsigned int * r11)
-{
- struct __una_u32 *ptr = (struct __una_u32 *) r11;
- ptr->x = r5;
-}
-
-static inline void __ustw(unsigned long r5, unsigned short * r11)
-{
- struct __una_u16 *ptr = (struct __una_u16 *) r11;
- ptr->x = r5;
-}
-
-static inline unsigned long long __sdp_get_unaligned(const void *ptr, size_t size)
-{
- unsigned long long val = 0;
- switch (size) {
- case 1:
- val = *(const unsigned char *)ptr;
- break;
- case 2:
- val = __uldw((const unsigned short *)ptr);
- break;
- case 4:
- val = __uldl((const unsigned int *)ptr);
- break;
- case 8:
- val = __uldq((const unsigned long *)ptr);
- break;
- }
- return val;
-}
-
-static inline void __sdp_put_unaligned(unsigned long val, void *ptr, size_t size)
-{
- switch (size) {
- case 1:
- *(unsigned char *)ptr = (val);
- break;
- case 2:
- __ustw(val, (unsigned short *)ptr);
- break;
- case 4:
- __ustl(val, (unsigned int *)ptr);
- break;
- case 8:
- __ustq(val, (unsigned long *)ptr);
- break;
- }
-}
-
-#define sdp_get_unaligned(ptr) \
- ((__typeof__(*(ptr)))__sdp_get_unaligned((ptr), sizeof(*(ptr))))
-
-#define sdp_put_unaligned(x,ptr) \
- __sdp_put_unaligned((unsigned long)(x), (ptr), sizeof(*(ptr)))
-
-#endif
+#define sdp_get_unaligned bt_get_unaligned
+#define sdp_put_unaligned bt_put_unaligned
#if __BYTE_ORDER == __BIG_ENDIAN
#define ntoh64(x) x
--
dwmw2
Hi David,
> > why using a do-while for put_unaligned() and not for get_unaligned().
>
> Because get_unaligned() returns a value, and put_unaligned() does not.
>
> > Is this supposed to work with each GCC version?
>
> Yes.
>
> > Will it also work with other compilers?
>
> Don't know; don't care. Remember, the existing code isn't guaranteed to
> work even with gcc, let alone other compilers. Does the rest of the
> BlueZ code compile with non-gcc compilers? Probably not... you have 122
> other instances of '__attribute__((packed))' in the source. Including
> the alignment stuff in include/sdp_internal.h which does it the way I'm
> suggesting, albeit with a gratuitous '#ifdef __i386__'.
>
> > What about performance? If a platform can do unaligned
> > access by itself it should be faster than compiler tricks.
>
> If the platform can do unaligned access by itself, then GCC knows that
> and emits a direct load/store instruction. It's only if the platform
> _can't_ do it by itself that GCC does anything different. That's why the
> #ifdef __i386__ in include/sdp_internal.h is pointless -- GCC should
> emit the same code even if the other version is used.
your patch results in a lot of "initialization from incompatible pointer
type" errors in the utils and hcidump. Basically in conjunction with
functions like ntohs() etc. How do we fix this?
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi David,
> > Your patch is now in (after I reworked the tab vs. space problem). And
> > everyone should start testing these on various platforms.
>
> OK. Do you want to apply this one too so we can release bluez-libs-2.15
> without changing the soname?
I re-added the functions hci_{local|remote}_name(). However I will wait
a little bit before I release bluez-libs-2.15, because people shouldn't
use them and maybe the 2.14 release will help to clean up the code of
others.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, 2005-01-20 at 19:14 +0100, Marcel Holtmann wrote:
> Your patch is now in (after I reworked the tab vs. space problem). And
> everyone should start testing these on various platforms.
OK. Do you want to apply this one too so we can release bluez-libs-2.15
without changing the soname?
--- bluez-libs-2.14/src/hci.c.compat 2005-01-20 12:21:11.000000000 +0000
+++ bluez-libs-2.14/src/hci.c 2005-01-20 12:21:17.000000000 +0000
@@ -850,6 +850,11 @@ int hci_disconnect(int dd, uint16_t hand
return 0;
}
+int hci_local_name(int dd, int len, char *name, int to)
+{
+ return hci_read_local_name(dd, len, name, to);
+}
+
int hci_read_local_name(int dd, int len, char *name, int to)
{
read_local_name_rp rp;
@@ -891,6 +896,11 @@ int hci_write_local_name(int dd, const c
return 0;
}
+int hci_remote_name(int dd, const bdaddr_t *bdaddr, int len, char *name, int to)
+{
+ return hci_read_remote_name(dd, bdaddr, len, name, to);
+}
+
int hci_read_remote_name(int dd, const bdaddr_t *bdaddr, int len, char *name, int to)
{
evt_remote_name_req_complete rn;
--- bluez-libs-2.14/include/hci_lib.h.compat 2005-01-20 12:21:11.000000000 +0000
+++ bluez-libs-2.14/include/hci_lib.h 2005-01-20 12:21:17.000000000 +0000
@@ -66,8 +66,11 @@ int hci_devinfo(int dev_id, struct hci_d
int hci_devba(int dev_id, bdaddr_t *bdaddr);
int hci_devid(const char *str);
+/* deprecated: preserve compatibility */
+int hci_local_name(int dd, int len, char *name, int to);
int hci_read_local_name(int dd, int len, char *name, int to);
int hci_write_local_name(int dd, const char *name, int to);
+int hci_remote_name(int dd, const bdaddr_t *bdaddr, int len, char *name, int to);
int hci_read_remote_name(int dd, const bdaddr_t *bdaddr, int len, char *name, int to);
int hci_read_remote_features(int dd, uint16_t handle, uint8_t *features, int to);
int hci_read_remote_version(int dd, uint16_t handle, struct hci_version *ver, int to);
--
dwmw2
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi David,
> > Will it also work with other compilers?
>
> Don't know; don't care. Remember, the existing code isn't guaranteed to
> work even with gcc, let alone other compilers. Does the rest of the
> BlueZ code compile with non-gcc compilers? Probably not... you have 122
> other instances of '__attribute__((packed))' in the source. Including
> the alignment stuff in include/sdp_internal.h which does it the way I'm
> suggesting, albeit with a gratuitous '#ifdef __i386__'.
oh yes, there is other stuff that must be cleaned up.
> > What about performance? If a platform can do unaligned
> > access by itself it should be faster than compiler tricks.
>
> If the platform can do unaligned access by itself, then GCC knows that
> and emits a direct load/store instruction. It's only if the platform
> _can't_ do it by itself that GCC does anything different. That's why the
> #ifdef __i386__ in include/sdp_internal.h is pointless -- GCC should
> emit the same code even if the other version is used.
Your patch is now in (after I reworked the tab vs. space problem). And
everyone should start testing these on various platforms.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, 2005-01-20 at 15:45 +0100, Marcel Holtmann wrote:
>
> why using a do-while for put_unaligned() and not for get_unaligned().
Because get_unaligned() returns a value, and put_unaligned() does not.
> Is this supposed to work with each GCC version?
Yes.
> Will it also work with other compilers?
Don't know; don't care. Remember, the existing code isn't guaranteed to
work even with gcc, let alone other compilers. Does the rest of the
BlueZ code compile with non-gcc compilers? Probably not... you have 122
other instances of '__attribute__((packed))' in the source. Including
the alignment stuff in include/sdp_internal.h which does it the way I'm
suggesting, albeit with a gratuitous '#ifdef __i386__'.
> What about performance? If a platform can do unaligned
> access by itself it should be faster than compiler tricks.
If the platform can do unaligned access by itself, then GCC knows that
and emits a direct load/store instruction. It's only if the platform
_can't_ do it by itself that GCC does anything different. That's why the
#ifdef __i386__ in include/sdp_internal.h is pointless -- GCC should
emit the same code even if the other version is used.
--
dwmw2
Hi David,
> > > The attached patch should fix the problem (it does as far as I can tell).
> > > The compiler probably thinks both arguments to memcpy() are aligned and so
> > > makes an optimization which breaks the copy (because the destination is not
> > > actually aligned). Perhaps this is a compiler bug... I'm using gcc 3.3.3.
> > > After googling and reading some discussion on the topic it seems that it's
> > > probably not a compiler bug. I'll leave that for someone else to decide. :)
> >
> > after checking some more resources, you may be right and the compiler
> > optimizes here where it should not. I found a comment about gcc and
> > using its __builtin_memcpy. Try to replace the memcpy with memmove and
> > see if this works.
>
> That isn't guaranteed to work either. This is the patch I've been
> testing in the Fedora RPM since August. It lets the compiler know what's
> happening so it can generate optimal code.
why using a do-while for put_unaligned() and not for get_unaligned(). Is
this supposed to work with each GCC version? Will it also work with
other compilers? What about performance? If a platform can do unaligned
access by itself it should be faster than compiler tricks.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2004-08-11 at 09:13 +0200, Marcel Holtmann wrote:
> > The attached patch should fix the problem (it does as far as I can tell).
> > The compiler probably thinks both arguments to memcpy() are aligned and so
> > makes an optimization which breaks the copy (because the destination is not
> > actually aligned). Perhaps this is a compiler bug... I'm using gcc 3.3.3.
> > After googling and reading some discussion on the topic it seems that it's
> > probably not a compiler bug. I'll leave that for someone else to decide. :)
>
> after checking some more resources, you may be right and the compiler
> optimizes here where it should not. I found a comment about gcc and
> using its __builtin_memcpy. Try to replace the memcpy with memmove and
> see if this works.
That isn't guaranteed to work either. This is the patch I've been
testing in the Fedora RPM since August. It lets the compiler know what's
happening so it can generate optimal code.
--
dwmw2