Screwy behavior in ports framework
I just installed FreeBSD 9.0-BETA2 last night, now I try to build ports starting with Perl 5.14.1 (successful), then Python 2.7 fails on something dubious, but when I try to build Lynx, ports framework can't find a directory right under its nose. Problem is with dependency libiconv-1.13.1_1. I am using the ports tree from BETA1, from portsnap, hence ports directory is /BETA1/usr/ports, BETA1 being the BETA1 partition/file system. My /etc/make.conf is PORTSDIR=/BETA1/usr/ports PACKAGES=/usr/packages WRKDIR=workb2 # added by use.perl 2011-09-13 02:49:43 PERL_VERSION=5.14.1 Error screen shows, copied with the mouse, thanks to moused: amelia2# ls workb2 .extract_done.libiconv._usr_local libiconv-1.13.1 amelia2# ls workb2/libiconv-1.13.1/ ABOUT-NLS Makefile.devel aclocal.m4 gnulib-localsrc AUTHORS Makefile.in autogen.sh include srclib COPYING NEWSbuild-aux lib srcm4 COPYING.LIB NOTES config.h.in libcharset tests ChangeLog PORTS configure m4 tools DEPENDENCIESREADME configure.acman windows DESIGN README.djgppdjgpp os2 woe32dll HACKING README.woe32doc po INSTALL.generic THANKS extras preload amelia2# make package-recursive |& tee build.log ===> Patching for libiconv-1.13.1_1 ===> Applying distribution patches for libiconv-1.13.1_1 patch: can't cd to workb2/libiconv-1.13.1: No such file or directory *** Error code 1 Stop in /BETA1/usr/ports/converters/libiconv. *** Error code 1 Stop in /BETA1/usr/ports/converters/libiconv. amelia2# pwd /BETA1/usr/ports/converters/libiconv amelia2# (end of quote) FreeBSD system or ports system can't find a directory right under its nose! I had gone into directory /BETA1/usr/ports/converters/libiconv to build that dependency before returning to lynx, but now seem stuck, or am I overlooking something hopelessly simple? Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT (BETA1) zfs pool recognized as corrupted
On Wed, 7 Sep 2011 23:55:23 +0200 Sebastian Chmielewski wrote: > hi > I've tried to import my zfs pool on: > FreeBSD-9.0-BETA1-amd64-memstick.img > My system currently runs 9.0-BETA1 and pool works correctly. > zpool import returns: > > pool: zroot > id: 3239789026273107181 > state: FAULTED > status: One or more devices contains corrupted data. > action: The pool cannot be imported due to damaged devices or data. > The pool may be active on another system, but can be imported using > the '-f' flag. >see: http://www.sun.com/msg/ZFS-8000-5E > config: > > zroot FAULTED corrupted data > 9327291201483595311 UNAVAIL corrupted data > The same symptoms are for FreeBSD-9.0-BETA2-amd64-memstick.img. Andriy Gapon suggests that it's the same as issue described in this thread, http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024888.html I've checked that mounting root and importing pool from command line doesn't work. Pool can be imported and used on 8.2 and I'm running 9.0 r225439M, only when booted from memstick I can't import it. best regards, -- Sebastian Chmielewski * jid:chmielss...@gmail.com * gg:3336919 * icq:224161389 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Has ath(4) ever worked one release and not worked another, please poke me..
On Sep 12, 2011, at 8:01 AM, Daniel Eischen wrote: > On Mon, 12 Sep 2011, Adrian Chadd wrote: > >> Hi all, >> >> I've had reports here and there from users who have said ath(4) worked >> for them in a previous release, and then suddenly stopped working. >> Either it stopped probing at all during boot, or it would probe but >> then spit out errors when trying to get allocated resources. >> >> There's been some recent commits to -HEAD which hopefully have >> resolved a class of problems that cardbus users have seen. But I'd >> like to know if this has popped up for anyone else. >> >> So, if you're "anyone else", and you've got an example piece of >> equipment and an ath(4) NIC which used to work and now doesn't, please >> step forward. Please only do so if you're willing to help diagnose the >> problem by downloading/compiling/running older kernel images and >> wrangling verbose boot messages from it all. It's likely going to be >> time consuming and quite tedious. >> >> I'd like to try and nail whatever lingering issues can be tracked down >> before 9.0-RELEASE if possible. Yes, this even means for older NICs >> (ie, the non-11n ones.) > > As described in previous email to -current, part of r222753 > needs to be backed out in order for my cardbus ath to work. That's not an ath(4) issue, but a cardbus(4) issue. I'll take care of it after the funeral when I return home, likely next week. Of course, John can take care of it sooner if he wants. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Serial Port Configuration does not work
On Mon, 12 Sep 2011 12:07:56 +0200 Ed Schouten wrote: > * Boris Samorodov , 20110912 07:33: > > Thanks Jilles! That did it: > Thanks for reporting/testing. Fixed in r225506! Confirmed, r225506 works fine. Thanks! -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0 no longer attaches, cardbus problems?
On Saturday, September 10, 2011 8:13:23 am Daniel Eischen wrote:
> On Fri, 9 Sep 2011, Warner Losh wrote:
>
> >
> > On Sep 9, 2011, at 1:22 PM, Daniel Eischen wrote:
> >
> >> I found the commit that broke ath for me, r222753,
> >> specifically, the change to /dev/cardbus/cardbus_cis.c.
> >>
> >> To be sure, I updated to head using svn, and applied
> >> the patch included below. ath attaches and works. Without
> >> the patch, ath does not attach.
> >>
> >> On another note, I've no idea why updating from a local
> >> CVS repo lead me down a wrong path. It seems wrong that
> >> a 'cvs update -P -d -A -D "31 Mar 2011"' works and
> >> a 'cvs update -P -d -A -D "1 Apr 2011"' does not work.
> >> r222753 did not occur until much later (June 6).
> >> Once John asked me to try r220195, I switched to using
> >> svn. When that worked, it seemed strange to me because
> >> nothing else committed after that on Mar 31 should have
> >> broke ath.
> >>
> >> Anyway, culprit found. Now what is the correct fix?
> >
> > Do you need both chunks? The second one seems redundant given the
definition of bus_alloc_reosurce_any does exactly that.
>
> I tried it separately with the 2 chunks, and only the first
> chunk is needed. To be pedantic, this was the change that
> made ath work again.
>
> Index: sys/dev/cardbus/cardbus_cis.c
> ===
> --- sys/dev/cardbus/cardbus_cis.c (revision 225463)
> +++ sys/dev/cardbus/cardbus_cis.c (working copy)
> @@ -441,6 +441,7 @@
> {
> if (res != CIS_CONFIG_SPACE) {
> bus_release_resource(child, SYS_RES_MEMORY, rid, res);
> + bus_delete_resource(child, SYS_RES_MEMORY, rid);
> }
> }
>
> While debugging the problem a couple of weeks ago, I did
> seem to notice ath was trying to attach twice. I seem to
> recall it was at different addresses. Could this possibly
> cause the problem without the above patch?
No, but your patch is confusing to me. Can a BAR change to a different
size after we read the CIS? Or perhaps it should now be prefetchable when
it wasn't before?
Hmm, the bus_delete_resource() doesn't make us re-probe the BAR (perhaps
it should?). I'm still not sure how exactly this fixes it. However, I do
think this probably is more correct.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0 beta2 & the new bsdinstaller
Hello, Fbsd8. You wrote 12 сентября 2011 г., 17:57:41: > 3.Following the keyboard language menu screen is the "set host name" > screen. It seems that the keyboard language selected in the previous > menu is now in effect and if the keys layout does not line up with > the keyboard you have, then what ever you enter for the host name is > scrambled, (IE. type in "home" and "dwkc" is what shows on the screen). > There is no option to return to previous keyboard language > menu screen to select different keyboard language. Only option is to > reboot and start all over again from the beginning of the new bsdinstaller. Oh, yes. Select "Russian (KOI-8R)" and you cannot enter hostname or filename system or any other line in English (I've tried almost all special keys combinations to find language switch, but with no luck). -- // Black Lion AKA Lev Serebryakov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
9.0 beta2 & the new bsdinstaller
Here are some problems that I fell need to be addressed in the 9.0 bsdinstaller. 1. During the transitional phase to using the new installer, the bsdinstaller welcome screen should have option to select to use the old sysinstall instead of continuing with the new bsdinstaller. Selecting the shell option and entering sysinstall on the command line does launch the previous installer but it does not really work. 2. On the select a keyboard language menu screen, there are 9 options for USA and none of them identify the standard 101 keyboard layout. I've been installing FBSD since release 4.0 and have never changed the keyboard from what ever the default was. This keyboard menu should list the first entry in the list as (default and use the keyboard language as used in all previous releases 'us.iso.acc.kbd'. Also the keymap= statement that is placed in /etc/rc.conf should have a default setting in /etc/defaults/rc.conf. The system hangs if the keymap= statement is missing from /etc/rc.conf on boot. 3.Following the keyboard language menu screen is the "set host name" screen. It seems that the keyboard language selected in the previous menu is now in effect and if the keys layout does not line up with the keyboard you have, then what ever you enter for the host name is scrambled, (IE. type in "home" and "dwkc" is what shows on the screen). There is no option to return to previous keyboard language menu screen to select different keyboard language. Only option is to reboot and start all over again from the beginning of the new bsdinstaller. 4. Distribution selection menu screen. The games & ports options are checked with an asterisk meaning these are the defaults. All the options on this menu should be blank so user has to make selection. Default should be no selections. 5. Final configuration screen has the first line "add user" option and the OK button highlighted. Hitting keyboard enter key takes you into add user function as the default. The exit option should be first in the list so its highlighted and hitting enter on your keyboard moves you to next menu screen just like all the other bsdinataller screens do. 6. At the "Complete screen" when the reboot option is selected the cd/dvd drive should automatically open so the install media can be removed just like sysinstall does. If disc1.iso or dvd.iso was installed to memstick and used to boot from to install the system, then a message screen should pop out saying the memstick has to be removed now before the reboot starts. Don't let the reboot occur until the memstick is removed. 7. On the partition editor screen the option should be the first in the list (ie; left most side) so if user accepts this config, hitting enter moves to next menu screen instead of having to tab over taking more time and effort. 8. No where in the bsdinstaller is any help available. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dump cannot do incremental backups when device name is too long
Hi all, I added this to the PR DB, because it was requested: http://www.freebsd.org/cgi/query-pr.cgi?pr=160678 Cc to freebsd-geom. Original report on freebsd-current: http://freebsd.1045724.n5.nabble.com/dump-cannot-do-incremental-backups-when-device-name-is-too-long-td4791131.html -- Martin Sugioarto signature.asc Description: PGP signature
Re: Has ath(4) ever worked one release and not worked another, please poke me..
On Mon, 12 Sep 2011, Adrian Chadd wrote: Hi all, I've had reports here and there from users who have said ath(4) worked for them in a previous release, and then suddenly stopped working. Either it stopped probing at all during boot, or it would probe but then spit out errors when trying to get allocated resources. There's been some recent commits to -HEAD which hopefully have resolved a class of problems that cardbus users have seen. But I'd like to know if this has popped up for anyone else. So, if you're "anyone else", and you've got an example piece of equipment and an ath(4) NIC which used to work and now doesn't, please step forward. Please only do so if you're willing to help diagnose the problem by downloading/compiling/running older kernel images and wrangling verbose boot messages from it all. It's likely going to be time consuming and quite tedious. I'd like to try and nail whatever lingering issues can be tracked down before 9.0-RELEASE if possible. Yes, this even means for older NICs (ie, the non-11n ones.) As described in previous email to -current, part of r222753 needs to be backed out in order for my cardbus ath to work. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: archaic/useless CFLAGS options for x86 boot blocks
on 12/09/2011 15:26 John Baldwin said the following: > On Monday, September 12, 2011 8:02:30 am Andriy Gapon wrote: >>> I think the patch is >>> fine, and I'd even prefer to go ahead and drop the extra cruft (like >>> removing >>> nops and aligns as well as -mrtd and -mregparm) from the UFS boot2 as well. >> >> I personally agree, thank you for this suggestion. >> My current plan is to leave boot2 alone until stable/9 is branched, but to >> try to >> get zfs/gpt boot changes into 9.0. What do you think? > > I think this is fine. > Another thing that was suggested to me via private communication is to change -Os to -O1 for those "non-constrained" boot blocks. I do not see anything wrong with that. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: archaic/useless CFLAGS options for x86 boot blocks
On Monday, September 12, 2011 8:02:30 am Andriy Gapon wrote: > > I think the patch is > > fine, and I'd even prefer to go ahead and drop the extra cruft (like > > removing > > nops and aligns as well as -mrtd and -mregparm) from the UFS boot2 as well. > > I personally agree, thank you for this suggestion. > My current plan is to leave boot2 alone until stable/9 is branched, but to > try to > get zfs/gpt boot changes into 9.0. What do you think? I think this is fine. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Has ath(4) ever worked one release and not worked another, please poke me..
Hi all, I've had reports here and there from users who have said ath(4) worked for them in a previous release, and then suddenly stopped working. Either it stopped probing at all during boot, or it would probe but then spit out errors when trying to get allocated resources. There's been some recent commits to -HEAD which hopefully have resolved a class of problems that cardbus users have seen. But I'd like to know if this has popped up for anyone else. So, if you're "anyone else", and you've got an example piece of equipment and an ath(4) NIC which used to work and now doesn't, please step forward. Please only do so if you're willing to help diagnose the problem by downloading/compiling/running older kernel images and wrangling verbose boot messages from it all. It's likely going to be time consuming and quite tedious. I'd like to try and nail whatever lingering issues can be tracked down before 9.0-RELEASE if possible. Yes, this even means for older NICs (ie, the non-11n ones.) Thanks, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: archaic/useless CFLAGS options for x86 boot blocks
on 12/09/2011 14:43 John Baldwin said the following: > I suspect some of the recent changes to shave space down for Clang have made > some of the optimization options no longer necessary. Just a note of all the options in question were added long before clang. > I think the patch is > fine, and I'd even prefer to go ahead and drop the extra cruft (like removing > nops and aligns as well as -mrtd and -mregparm) from the UFS boot2 as well. I personally agree, thank you for this suggestion. My current plan is to leave boot2 alone until stable/9 is branched, but to try to get zfs/gpt boot changes into 9.0. What do you think? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: archaic/useless CFLAGS options for x86 boot blocks
On Monday, September 12, 2011 3:36:54 am Andriy Gapon wrote: > > This email is in part inspired by the following problem: > http://article.gmane.org/gmane.os.freebsd.current/135292 > So "harmful" could also be added to the subject line. > > So here is my proposal. > > Part I. ZFS and GPT bootblocks. > > I believe that we do not need here any extra optimizations and happy dances > that > seem to be carried over from boot2. > I think that just the -Os should be sufficient of optimization flags. Maybe > even that is not really required. > Rationale: > - these boot blocks are not as nearly space-constrained as boot2 > - using untypical flags increases chances of hitting compiler bugs, > especially for those compilers where we are stuck with > unsupported / locally-maintained versions or where a compiler is maturing > yet > - assembly / machine code and debugging may become easier > > Additionally, the '/align/d' '/nop/d' filtering of the intermediate assembly > file seems to be not needed for zfsboot. > > Part II. The original boot2. > > My testing shows that -Os -fomit-frame-pointer are sufficient to produce a > small > enough boot2 image (~300 bytes remain available with gcc, 51 bytes for clang). > -mrtd -mregparm=3 do not change size with gcc, but with clang they increase > _available_ space to 79 bytes. > > The '/align/d' '/nop/d' filtering seems to shave off only 7 bytes here. > Not suggesting anything, just an observation... > > Part III. History. > > It seems that all those optimization related options were introduced very long > time ago when the compiler(s) were quite different from what they are now. > So, some re-evaluation may be (long over)due. > For example, -fno-unit-at-a-time is definitely an anti-optmization option and > it > was introduced to fight some gcc bugs way back in 2004 (r132870). Its merits > have never been re-evaluated after switch to gcc 4.2, it seems. > -fno-guess-branch-probability and -mno-align-long-strings are even less > obvious > options (see e.g. r108149). > > > Finally, here is a diff: > http://people.freebsd.org/~avg/boot-cflags.diff > All the boot blocks are boot tested in qemu. > boot2 is also tested with -mrtd -mregparm removed. I suspect some of the recent changes to shave space down for Clang have made some of the optimization options no longer necessary. I think the patch is fine, and I'd even prefer to go ahead and drop the extra cruft (like removing nops and aligns as well as -mrtd and -mregparm) from the UFS boot2 as well. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Call to arms: MPSAFE file systems (was: Re: Removal of Giant from the VFS layer for 10.0)
On Sat, 27 Aug 2011, Attilio Rao wrote: With the aid of kib and rwatson I made a roughly outlined plan about what is left to do in order to have all the filesystems locked (or eventually dropped) before 10.0) and is summarized here: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS Here's a more succinct summary of the key points from the wiki: FreeBSD has supported Giant lock-free file systems for years, and almost all file systems have been shipping "MPSAFE" for several years. However, VFS retains compatibility support for non-MPSAFE file systems. We want to remove that compatibility support, as it adds non-trivial complexity to an already quite complex VFS, simplifying the code and making it easier to maintain and enhance. This means either fixing or removing any file systems that can't operate without compatibility support. Attilio has posted a schedule for the removal of compatibility crutches, which in turn means removing any un-updated file systems. We are looking for volunteers to perform those updates. Here's the schedule: 27 August 2011 Attilio posts plan on arch@ 1 October 2011 Add VFS_GIANT_COMPATIBILITY option (enabled) 1 March 2012Disable VFS_GIANT_COMPATIBILITY option by default 1 September 2012Disconnect non-MPSAFE file systems from build 1 March 2013Garbage collect any un-updated file systems Most of our critical file systems are already done: UFS, ZFS, the NFS client and server (both old and new), unionfs, pseudofs, tmpfs, nullfs, devfs, cd9660, ext2fs, fdescfs, msdosfs, udf, and procfs. However, some remain, and they require owners: File system Owner State codarwatson Non-MPSAFE hpfs??? Non-MPSAFE ntfsattilio Non-MPSAFE nwfs??? Non-MPSAFE portalfs??? Non-MPSAFE smbfs ??? Non-MPSAFE reiserfs??? Non-MPSAFE xfs ??? Non-MPSAFE Any file system that remains on this list will be removed by 10.0 -- so, if you care about one of the above file systems, please help us get them updated. You can find more information here, including on the methodology for making a file system MPSAFE, with worked examples: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Serial Port Configuration does not work
* Boris Samorodov , 20110912 07:33: > Thanks Jilles! That did it: Thanks for reporting/testing. Fixed in r225506! -- Ed Schouten WWW: http://80386.nl/ pgp9eg7BIlocP.pgp Description: PGP signature
Re: issue with old linuxbase.
On 10/09/2011 18:06, Boris Samorodov wrote: > On Sat, 10 Sep 2011 12:33:37 +0100 Veniamin Gvozdikov wrote: > >> I've tried porting a few programs from Linux which's used a >> linuxulator. But I have the problem with old linux base system. My >> ports can't be run with old libstdc++.so.6 >> I have error with run linux apps. >> /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found >>> strings /compat/linux/usr/lib/libstdc++.so.6|grep GLIBCXX >> GLIBCXX_3.4 >> GLIBCXX_3.4.1 >> GLIBCXX_3.4.2 >> GLIBCXX_3.4.3 >> GLIBCXX_3.4.4 >> GLIBCXX_3.4.5 >> GLIBCXX_3.4.6 >> GLIBCXX_3.4.7 >> GLIBCXX_3.4.8 >> GLIBCXX_3.4.9 >> GLIBCXX_3.4.10 >> GLIBCXX_FORCE_NEW >> GLIBCXX_DEBUG_MESSAGE_LENGTH > >> How to fix it > You may try to replace libstdc++ package from the base port by the one > from Fedora 11. But the result is unknown. FreeBSD-emulation is a better > place to speak about the matter. > >> or when'll upgraded linux base system? > When somebody do the actual work. > http://www.leidinger.net/blog/2011/08/29/howto-create-a-new-linux_base-port/ and http://www.leidinger.net/blog/2011/09/01/howto-add-linux-infrastructure-ports-for-a-new-linux_base-port/ Look useful here. If I actually used the linuxulator I'd probably have had a stab but its not something i have used for longer than I can think. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: archaic/useless CFLAGS options for x86 boot blocks
on 12/09/2011 10:36 Andriy Gapon said the following: > > This email is in part inspired by the following problem: > http://article.gmane.org/gmane.os.freebsd.current/135292 > So "harmful" could also be added to the subject line. > > So here is my proposal. I would like to clarify that my intention was to solicit opinions, explanations, discussions, alternative proposals and *testing*. > Part I. ZFS and GPT bootblocks. > > I believe that we do not need here any extra optimizations and happy dances > that > seem to be carried over from boot2. > I think that just the -Os should be sufficient of optimization flags. Maybe > even that is not really required. > Rationale: > - these boot blocks are not as nearly space-constrained as boot2 > - using untypical flags increases chances of hitting compiler bugs, > especially for those compilers where we are stuck with > unsupported / locally-maintained versions or where a compiler is maturing > yet > - assembly / machine code and debugging may become easier > > Additionally, the '/align/d' '/nop/d' filtering of the intermediate assembly > file seems to be not needed for zfsboot. > > Part II. The original boot2. > > My testing shows that -Os -fomit-frame-pointer are sufficient to produce a > small > enough boot2 image (~300 bytes remain available with gcc, 51 bytes for clang). > -mrtd -mregparm=3 do not change size with gcc, but with clang they increase > _available_ space to 79 bytes. > > The '/align/d' '/nop/d' filtering seems to shave off only 7 bytes here. > Not suggesting anything, just an observation... > > Part III. History. > > It seems that all those optimization related options were introduced very long > time ago when the compiler(s) were quite different from what they are now. > So, some re-evaluation may be (long over)due. > For example, -fno-unit-at-a-time is definitely an anti-optmization option and > it > was introduced to fight some gcc bugs way back in 2004 (r132870). Its merits > have never been re-evaluated after switch to gcc 4.2, it seems. > -fno-guess-branch-probability and -mno-align-long-strings are even less > obvious > options (see e.g. r108149). > > > Finally, here is a diff: > http://people.freebsd.org/~avg/boot-cflags.diff > All the boot blocks are boot tested in qemu. > boot2 is also tested with -mrtd -mregparm removed. > -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
archaic/useless CFLAGS options for x86 boot blocks
This email is in part inspired by the following problem: http://article.gmane.org/gmane.os.freebsd.current/135292 So "harmful" could also be added to the subject line. So here is my proposal. Part I. ZFS and GPT bootblocks. I believe that we do not need here any extra optimizations and happy dances that seem to be carried over from boot2. I think that just the -Os should be sufficient of optimization flags. Maybe even that is not really required. Rationale: - these boot blocks are not as nearly space-constrained as boot2 - using untypical flags increases chances of hitting compiler bugs, especially for those compilers where we are stuck with unsupported / locally-maintained versions or where a compiler is maturing yet - assembly / machine code and debugging may become easier Additionally, the '/align/d' '/nop/d' filtering of the intermediate assembly file seems to be not needed for zfsboot. Part II. The original boot2. My testing shows that -Os -fomit-frame-pointer are sufficient to produce a small enough boot2 image (~300 bytes remain available with gcc, 51 bytes for clang). -mrtd -mregparm=3 do not change size with gcc, but with clang they increase _available_ space to 79 bytes. The '/align/d' '/nop/d' filtering seems to shave off only 7 bytes here. Not suggesting anything, just an observation... Part III. History. It seems that all those optimization related options were introduced very long time ago when the compiler(s) were quite different from what they are now. So, some re-evaluation may be (long over)due. For example, -fno-unit-at-a-time is definitely an anti-optmization option and it was introduced to fight some gcc bugs way back in 2004 (r132870). Its merits have never been re-evaluated after switch to gcc 4.2, it seems. -fno-guess-branch-probability and -mno-align-long-strings are even less obvious options (see e.g. r108149). Finally, here is a diff: http://people.freebsd.org/~avg/boot-cflags.diff All the boot blocks are boot tested in qemu. boot2 is also tested with -mrtd -mregparm removed. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
