Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On Sat, 19 Nov 2011 12:01:50 +0200 Gleb Kurtsou wrote: > Hi, > > I was lucky to write a bit of code which gcc 4.2 fails to compile > correctly with -O2. Too keep long story short the code fails for gcc > from base system and last gcc 4.2 snapshot from ports. It works with > gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. > -O and -Os optimization levels are fine (I've tried with all -f* flags > mentioned in documentation) > > -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I > presume i386 should be fine. These options are also used for > compilation of kernel (with debugging enabled) and modules. > > I'm not able to share the code, but have a test case reproducing the > bug. I've encountered the issue over a week ago and tried narrowing > it down to a simple test I could share but without much success. > > The code itself is very common: initialize two structs on stack, call > a function with pointers to those stucts as arguments. A number of > inlined assertion functions. gcc fails to correctly optimize struct > assignments with -fno-omit-frame-pointer, I have a number of small > structs assigned, gcc decides not to use data coping but to assign > fields directly. I've tried disabling sra, tweaking sra parameters -- > no luck in forcing it to copy data. Replacing one particular > assignment with memcpy produces correct code, but that's not a > solution. > > -O2 -fno-omit-frame-pointer -fno-inline is buggy > -O2 -fno-omit-frame-pointer -frename-registers is buggy > > I found similar issue with gcc 4.6, but I'm not able to reproduce it > with gcc test case: > https://bugzilla.redhat.com/show_bug.cgi?id=679924 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 > > I'll be glad to help debugging it and will be hanging on #bsddev > during weekend as glk. > > > Thanks, > Gleb. > ___ It should take about ten times less time than this thread took already to isolate _short_ test case demonstrating the problem, yet nothing of the sort has shown up yet from anyone involved. Am I missing something? -- Alexander Kabaev signature.asc Description: PGP signature
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On 12/08/11 03:01, Piotr Nowak wrote: We're working on PowerPC target using GCC 4.2.1 and FreeBSD 6.1. It seems like we have similar problem. In our case GCC sometimes very unfortunately optimize code with -fno-omit-frame-pointer. Example shown below covers file sys/powerc/booke/pmap.c and function pmap_kenter. If we disassemble kernel binary we have: c019998c: 4b ec 6a ed bl c0060478<_mtx_unlock_spin_flags> c010: 81 61 00 00 lwz r11,0(r1) c014: 80 0b 00 04 lwz r0,4(r11) c018: 7d 61 5b 78 mr r1,r11 c01c: 82 ab ff d4 lwz r21,-44(r11) c01999a0: 7c 08 03 a6 mtlrr0 c01999a4: 82 cb ff d8 lwz r22,-40(r11) c01999a8: 82 eb ff dc lwz r23,-36(r11) c01999ac: 83 0b ff e0 lwz r24,-32(r11) c01999b0: 83 2b ff e4 lwz r25,-28(r11) c01999b4: 83 4b ff e8 lwz r26,-24(r11) c01999b8: 83 6b ff ec lwz r27,-20(r11) As you can see stack pointer on R1 is being updated before stashed data were pulled off stack. (mr r1,r11) As a result of this we have chance to get crash when any interrupt hit shortly after stack pointer update. The interrupt prologue will override not yet pulled off pmap_kenter function data. The problem occures only with -fno-omit-frame-pointer and not every branch returns are beeing corrupted. Do you think this issue may be somehow related to yours? Are there any patches/solutions to fix it? Should we turn off -fno-omit-frame-frame-pointer on PPC then? It's enabled in default kernel builds. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: USB Texas Instruments CDCE modem not recognized by cdce
On Thursday 08 December 2011 16:54:40 Lorenzo Cogotti wrote: > Eventually, should I send a patch to someone so that I am not the only > one to benefit from your help? If you want this quirk permanently you could try to add an entry to: /sys/dev/usb/quirk/usb_quirk.c You should use the quirk: UQ_CFG_INDEX_1 --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: USB Texas Instruments CDCE modem not recognized by cdce
On Thursday 08 December 2011 16:35:47 Lorenzo Cogotti wrote:
> Il giorno gio, 08/12/2011 alle 15.39 +0100, Hans Petter Selasky ha
>
> scritto:
> > Typically you need to select configuration 1 for dual RNDIS/CDCE devices
> > to work.
> >
> > 1) Locate your device:
> >
> > usbconfig
> >
> > 2) Set config 1
> >
> > usbconfig -d X.Y set_config 1
> >
> > To permanently do this, you can set the configuration index 1 quirk for
> > your device.
>
> I tried editing if_cdce.c adding to the static array mentioned in my
> first mail:
>
> {USB_VPI(USB_VENDOR_TI, 0x6060, 0)},
>
> obviously if this edit is necessary, a nice good little #define for
> 0x6060 should be added where appropriate.
>
> The device get detected and properly claimed by the cdce module.
> It is all good unless I actually try to connect with:
> dhclient ue0
>
> When I try this, the DHCP request just hangs and times out.
>
> I tried usbconfig -d 0.2 set_config 1
> This produces:
>
> cdce0: at uhub0, port 3, addr 2 (disconnected)
> cdce0: on usbus0
> ue0: on cdce0
> ue0: Ethernet address: 00:e1:a7:76:76:81
> cdce1: on usbus0
> cdce1: No valid alternate setting found
> device_attach: cdce1 attach returned 6
> cdce1: on usbus0
> cdce1: No valid alternate setting found
> device_attach: cdce1 attach returned 6
>
> Despite this moltitude of scary messages, dhclient now works good and I
> can surf with my USB modem on FreeBSD, which is as awesome as it sounds.
>
Hi,
> So, the questions now are:
> 1) was the if_cdce.c edit necessary, or the usbconfig is more than
> enough?
The usbconfig is more than enough.
> 2) how/should could this stuff be made in an automagic way by FreeBSD?
> Since everything I have on this desktop has been detected flawlessly,
> this was the only thing that made me suffer.
The easiest way would be to create a devd config file:
cat << EOF > /usr/local/etc/devd/myusbdevice.conf
notify 100 {
match "system" "USB";
match "subsystem" "DEVICE";
match "type""ATTACH";
match "vendor" "0x";
match "product" "0x";
action "usbconfig -d $cdev set_config 1"
};
EOF
/etc/rc.d/devd restart
The "vendor" is idVendor and "product" is idProduct. See output from this
command:
usbconfig -d X.Y dump_device_desc
--HPS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: USB Texas Instruments CDCE modem not recognized by cdce
Il giorno gio, 08/12/2011 alle 16.35 +0100, Lorenzo Cogotti ha scritto:
> I tried editing if_cdce.c adding to the static array mentioned in my
> first mail:
>
> {USB_VPI(USB_VENDOR_TI, 0x6060, 0)},
>
I tried to remove this edit and recompile the kernel module, the scary
messages faded away, leaving a nice and happy:
cdce0 on usbus0
ue0: on cdce0
ue0: Ethernet address: ...
This is just perfect.
So it appears that the edit is absolutely not necessary.
The only thing that seems to be necessary is setting the configuration
to 1 as a quirk.
Where should I look to do that?
Eventually, should I send a patch to someone so that I am not the only
one to benefit from your help?
--
Lorenzo Cogotti
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: USB Texas Instruments CDCE modem not recognized by cdce
Il giorno gio, 08/12/2011 alle 15.39 +0100, Hans Petter Selasky ha
scritto:
> Typically you need to select configuration 1 for dual RNDIS/CDCE devices to
> work.
>
> 1) Locate your device:
>
> usbconfig
>
> 2) Set config 1
>
> usbconfig -d X.Y set_config 1
>
> To permanently do this, you can set the configuration index 1 quirk for your
> device.
>
I tried editing if_cdce.c adding to the static array mentioned in my
first mail:
{USB_VPI(USB_VENDOR_TI, 0x6060, 0)},
obviously if this edit is necessary, a nice good little #define for
0x6060 should be added where appropriate.
The device get detected and properly claimed by the cdce module.
It is all good unless I actually try to connect with:
dhclient ue0
When I try this, the DHCP request just hangs and times out.
I tried usbconfig -d 0.2 set_config 1
This produces:
cdce0: at uhub0, port 3, addr 2 (disconnected)
cdce0: on usbus0
ue0: on cdce0
ue0: Ethernet address: 00:e1:a7:76:76:81
cdce1: on usbus0
cdce1: No valid alternate setting found
device_attach: cdce1 attach returned 6
cdce1: on usbus0
cdce1: No valid alternate setting found
device_attach: cdce1 attach returned 6
Despite this moltitude of scary messages, dhclient now works good and I
can surf with my USB modem on FreeBSD, which is as awesome as it sounds.
So, the questions now are:
1) was the if_cdce.c edit necessary, or the usbconfig is more than
enough?
2) how/should could this stuff be made in an automagic way by FreeBSD?
Since everything I have on this desktop has been detected flawlessly,
this was the only thing that made me suffer.
--
Lorenzo Cogotti
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: USB Texas Instruments CDCE modem not recognized by cdce
On Thursday 08 December 2011 14:09:47 Lorenzo Cogotti wrote: > Dear all, > > I am new to this list and to FreeBSD in general, so first of all hi > everyone and thank you for providing this awesome and rock solid OS. > > I have a CDC compliant (at least this is what the manufacturer claims) > USB Modem, which doesn't get detected by cdce module. > > /var/log/messages reports: > root: Unknown USB device: vendor 0x0451 product 0x6060 bus uhub0 > kernel: ugen0.2: at usbus0 > > usbconfig list reports: > ugen0.2: > at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON > > I tested this with FreeBSD 8.2 and FreeBSD 9.0RC2, the situation doesn't > change. > I tested this modem on Linux, which is able to detect and properly use > this modem via USB with module: cdc_ether > > I suspect that some trivial changes to cdce module would get this modem > up and running, but I am too newbie to do this on my own, so I thought > to ask this ML for help on this topic. > > I took a look to cdce, on kernel sources included with FreeBSD 8.2 > release, more precisely to: > dev/usb/net/if_cdce.c > Hi, > I assume that a device specific entry to: Typically you need to select configuration 1 for dual RNDIS/CDCE devices to work. 1) Locate your device: usbconfig 2) Set config 1 usbconfig -d X.Y set_config 1 To permanently do this, you can set the configuration index 1 quirk for your device. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
USB Texas Instruments CDCE modem not recognized by cdce
Dear all, I am new to this list and to FreeBSD in general, so first of all hi everyone and thank you for providing this awesome and rock solid OS. I have a CDC compliant (at least this is what the manufacturer claims) USB Modem, which doesn't get detected by cdce module. /var/log/messages reports: root: Unknown USB device: vendor 0x0451 product 0x6060 bus uhub0 kernel: ugen0.2: at usbus0 usbconfig list reports: ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON I tested this with FreeBSD 8.2 and FreeBSD 9.0RC2, the situation doesn't change. I tested this modem on Linux, which is able to detect and properly use this modem via USB with module: cdc_ether I suspect that some trivial changes to cdce module would get this modem up and running, but I am too newbie to do this on my own, so I thought to ask this ML for help on this topic. I took a look to cdce, on kernel sources included with FreeBSD 8.2 release, more precisely to: dev/usb/net/if_cdce.c I assume that a device specific entry to: static const struct usb_device_id cdce_devs[] would do the trick, wouldn't it? How should I edit this file in a sane way and test if this device get recognized? I tried some USB_VPI combinations adding the afore mentioned identifiers from /var/log/messages, the device got recognized correctly by cdce, but the dhclient command hanged as if the communication with the device failed. I am currently on a fresh, just installed, FreeBSD 8.2 AMD64 system. Sorry if I missed to report some crucial information, if so, please let me know. Regards. -- Lorenzo Cogotti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [SOLVED]Re: 64bit build errors - use gcc46
On 12/08/11 19:58, Tom Evans wrote: On Thu, Dec 8, 2011 at 6:05 AM, Da Rock wrote: Just to let the list know, I changed as - ./configure --as=/usr/local/bin/as. I still had the exact same error oddly enough. I then had to install gcc46; and the error changed. I then had to update the configure script to comment out the v4l videodev headers (weird). Bingo! I had success. So, it begs the question did the as option change things? Or does gcc46 imply the use of it anyway? I'll have to try again without the option to see for sure, but for now I have another project that I need to keep the status quo for. Yes, sometimes as is invoked via gcc, and if you are using the stock gcc, it uses the stock as, and you still get the errors. You need both gcc46 and binutils from ports. Sorry, forgot that bit :o Confirmed. Built without --as and only --cc arguments. Great learning experience for me anyway... :) Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
We're working on PowerPC target using GCC 4.2.1 and FreeBSD 6.1. It seems like we have similar problem. In our case GCC sometimes very unfortunately optimize code with -fno-omit-frame-pointer. Example shown below covers file sys/powerc/booke/pmap.c and function pmap_kenter. If we disassemble kernel binary we have: c019998c: 4b ec 6a ed bl c0060478 <_mtx_unlock_spin_flags> c010: 81 61 00 00 lwz r11,0(r1) c014: 80 0b 00 04 lwz r0,4(r11) c018: 7d 61 5b 78 mr r1,r11 c01c: 82 ab ff d4 lwz r21,-44(r11) c01999a0: 7c 08 03 a6 mtlrr0 c01999a4: 82 cb ff d8 lwz r22,-40(r11) c01999a8: 82 eb ff dc lwz r23,-36(r11) c01999ac: 83 0b ff e0 lwz r24,-32(r11) c01999b0: 83 2b ff e4 lwz r25,-28(r11) c01999b4: 83 4b ff e8 lwz r26,-24(r11) c01999b8: 83 6b ff ec lwz r27,-20(r11) As you can see stack pointer on R1 is being updated before stashed data were pulled off stack. (mr r1,r11) As a result of this we have chance to get crash when any interrupt hit shortly after stack pointer update. The interrupt prologue will override not yet pulled off pmap_kenter function data. The problem occures only with -fno-omit-frame-pointer and not every branch returns are beeing corrupted. Do you think this issue may be somehow related to yours? Are there any patches/solutions to fix it? Regards, Piotr ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [SOLVED]Re: 64bit build errors - use gcc46
On Thu, Dec 8, 2011 at 6:05 AM, Da Rock wrote: > > Just to let the list know, I changed as - ./configure > --as=/usr/local/bin/as. I still had the exact same error oddly enough. > > I then had to install gcc46; and the error changed. > > I then had to update the configure script to comment out the v4l videodev > headers (weird). Bingo! I had success. > > So, it begs the question did the as option change things? Or does gcc46 > imply the use of it anyway? > > I'll have to try again without the option to see for sure, but for now I > have another project that I need to keep the status quo for. Yes, sometimes as is invoked via gcc, and if you are using the stock gcc, it uses the stock as, and you still get the errors. You need both gcc46 and binutils from ports. Sorry, forgot that bit :o Cheers Tom ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On (08/12/2011 10:01), Piotr Nowak wrote: > We're working on PowerPC target using GCC 4.2.1 > and FreeBSD 6.1. It seems like we have similar > problem. In our case GCC sometimes very unfortunately > optimize code with -fno-omit-frame-pointer. > > Example shown below covers file sys/powerc/booke/pmap.c > and function pmap_kenter. If we disassemble kernel binary > we have: > > c019998c: 4b ec 6a ed bl c0060478 <_mtx_unlock_spin_flags> > c010: 81 61 00 00 lwz r11,0(r1) > c014: 80 0b 00 04 lwz r0,4(r11) > c018: 7d 61 5b 78 mr r1,r11 > c01c: 82 ab ff d4 lwz r21,-44(r11) > c01999a0: 7c 08 03 a6 mtlrr0 > c01999a4: 82 cb ff d8 lwz r22,-40(r11) > c01999a8: 82 eb ff dc lwz r23,-36(r11) > c01999ac: 83 0b ff e0 lwz r24,-32(r11) > c01999b0: 83 2b ff e4 lwz r25,-28(r11) > c01999b4: 83 4b ff e8 lwz r26,-24(r11) > c01999b8: 83 6b ff ec lwz r27,-20(r11) > > As you can see stack pointer on R1 is being updated > before stashed data were pulled off stack. (mr r1,r11) > As a result of this we have chance to get crash when > any interrupt hit shortly after stack pointer update. > The interrupt prologue will override not yet pulled off > pmap_kenter function data. > > The problem occures only with -fno-omit-frame-pointer > and not every branch returns are beeing corrupted. > > Do you think this issue may be somehow related to yours? > Are there any patches/solutions to fix it? Adding -finline-functions fixed/masked issue for me. Unfortunately building kernel with -finline-functions is not supported. You can try tweaking conf/files to change build options for this file only. Issue not sra-related, but sra is also known to be buggy in gcc 4.2. > > Regards, > Piotr ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On 2011-12-07, at 21:28, Arnaud Lacombe wrote: > Hi, > > On Sat, Nov 19, 2011 at 5:01 AM, Gleb Kurtsou wrote: >> Hi, >> >> I was lucky to write a bit of code which gcc 4.2 fails to compile >> correctly with -O2. Too keep long story short the code fails for gcc >> from base system and last gcc 4.2 snapshot from ports. It works with gcc >> 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and >> -Os optimization levels are fine (I've tried with all -f* flags >> mentioned in documentation) >> >> -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I >> presume i386 should be fine. These options are also used for >> compilation of kernel (with debugging enabled) and modules. >> >> I'm not able to share the code, but have a test case reproducing the >> bug. I've encountered the issue over a week ago and tried narrowing it down >> to a simple test I could share but without much success. >> >> The code itself is very common: initialize two structs on stack, call a >> function with pointers to those stucts as arguments. A number of inlined >> assertion functions. gcc fails to correctly optimize struct assignments >> with -fno-omit-frame-pointer, I have a number of small structs assigned, >> gcc decides not to use data coping but to assign fields directly. I've >> tried disabling sra, tweaking sra parameters -- no luck in forcing it >> to copy data. Replacing one particular assignment with memcpy produces >> correct code, but that's not a solution. >> >> -O2 -fno-omit-frame-pointer -fno-inline is buggy >> -O2 -fno-omit-frame-pointer -frename-registers is buggy >> >> I found similar issue with gcc 4.6, but I'm not able to reproduce it >> with gcc test case: >> https://bugzilla.redhat.com/show_bug.cgi?id=679924 >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 >> > this PR seems highly irrelevant, the cause has been identified to a > commit made in mid-2010, that's 3 years older than gcc in base. > >> I'll be glad to help debugging it and will be hanging on #bsddev during >> weekend as glk. >> > at least, can you share the testcase and miscompilation details ? I believe we suffer from a very similar issue on PowerPC as well, we'll provide detailed information shortly. Rafal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
