Re: Google SoC 2009 Idea
On Thu, Feb 26, 2009 at 5:10 AM, Tim Kientzle kient...@freebsd.org wrote: Siddharth Prakash Singh wrote: I am a student from India. I am willing to contribute to FreeBSD as a google soc participant this year. I would like to suggest an idea. Title: Multicore Aware Process Scheduler. I have not gone through the process scheduler code of Free BSD. Hence, I am not yet aware about the current support for Multicore Architectures. Since you posted to a lot of different lists, I think you probably don't already use FreeBSD. (If you did, why would you post to NetBSD and DragonflyBSD lists?) Scheduler work is quite complex and interacts heavily with the rest of the system; it may not be a good choice for someone who doesn't already have a lot of experience with FreeBSD. You should probably tell us a little more about yourself: What kind of student? Graduate? Undergraduate? Are you in a CS program or some other engineering program? I am junior undergraduate student at CS department of Indian Institute Of Technology, India. Do you use FreeBSD? How long have you used it? What do you do with it? No, I haven't really used FreeBSD much. I have been using Linux since long! Have you read Kirk McKusick's book on FreeBSD internals? No. But I have sound knowledge of Linux and Minix Kernel. Have you built and installed a FreeBSD system from source code? No, But I have built and installed a Linux system from source code. Have you taken classes on OS internals? Yes, I have taken a course on OS internal last semester only. Ans I worked on Pintos Kernel as a part of the course. How much C programming have you done? I have a tremendous experience of C coding. What areas of FreeBSD have you had the most problems with? How would you make those areas better? Tim Kientzle I am aware that I am new to FreeBSD, but that doesn't really mean I am not qualified. -- Siddharth Prakash Singh http://www.spsneo.com ___ 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: Google SoC 2009 Idea
On Thu, 26 Feb 2009 17:53:48 +0530 Siddharth Prakash Singh sps...@gmail.com wrote: Do you use FreeBSD? __How long have you used it? What do you do with it? No, I haven't really used FreeBSD much. I have been using Linux since long! Have you read Kirk McKusick's book on FreeBSD internals? No. But I have sound knowledge of Linux and Minix Kernel. Having done development on both FreeBSD and Linux I can authoritatively state that they're totally different animals. But just because you only have Linux knowledge doesn't exclude you from doing FreeBSD development. It will just take a while to get up to speed. --- Gary Jennejohn ___ 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: Google SoC 2009 Idea
On Wed, 25 Feb 2009, Tim Kientzle wrote: I have not gone through the process scheduler code of Free BSD. Hence, I am not yet aware about the current support for Multicore Architectures. Since you posted to a lot of different lists, I think you probably don't already use FreeBSD. (If you did, why would you post to NetBSD and DragonflyBSD lists?) Scheduler work is quite complex and interacts heavily with the rest of the system; it may not be a good choice for someone who doesn't already have a lot of experience with FreeBSD. All the things you say are true, but let's not be too hard on the new guy, however -- many of our GSoC students don't have previous FreeBSD kernel-hacking experience. However, it does mean that they have to pick project ideas that are well-suited to a significant warmup and investigation period on the front end of the project. I'm also not convinced that a scheduler project along these lines would be the most successful, but I wonder if a more experimental-spin proposal for looking at how to investigate poor scheduling decisions using dtrace, instrumentation and metrics to help us understand performance on NUMA systems, and exploring the impact of heuristics might go a long way. As our ULE scheduler has most of the non-NUMA features suggested in the original already, it would actually be a nice starting point for this. I understand Jeff Roberson has been doing some initial looking at NUMA, but more from a memory placement and less from a scheduling perspective? Robert N M Watson Computer Laboratory University of Cambridge You should probably tell us a little more about yourself: What kind of student? Graduate? Undergraduate? Are you in a CS program or some other engineering program? Do you use FreeBSD? How long have you used it? What do you do with it? Have you read Kirk McKusick's book on FreeBSD internals? Have you built and installed a FreeBSD system from source code? Have you taken classes on OS internals? How much C programming have you done? What areas of FreeBSD have you had the most problems with? How would you make those areas better? Tim Kientzle ___ 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 ___ 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: Google SoC 2009 Idea
Robert Watson wrote: On Wed, 25 Feb 2009, Tim Kientzle wrote: I have not gone through the process scheduler code of Free BSD. Hence, I am not yet aware about the current support for Multicore Architectures. Since you posted to a lot of different lists, I think you probably don't already use FreeBSD. (If you did, why would you post to NetBSD and DragonflyBSD lists?) Scheduler work is quite complex and interacts heavily with the rest of the system; it may not be a good choice for someone who doesn't already have a lot of experience with FreeBSD. All the things you say are true, but let's not be too hard on the new guy, however -- many of our GSoC students don't have previous FreeBSD kernel-hacking experience. However, it does mean that they have to pick project ideas that are well-suited to a significant warmup and investigation period on the front end of the project. I apologize to Siddharth and others if I came off overly harsh. My intention was to caution him that he should plan for a lot of work prior to GSoC if he wants to tackle something that's at the core of the OS like this. I'm also not convinced that a scheduler project along these lines would be the most successful, but I wonder if a more experimental-spin proposal for looking at how to investigate poor scheduling decisions using dtrace, instrumentation and metrics to help us understand performance on NUMA systems, and exploring the impact of heuristics might go a long way. That's a good idea. The thing that's always impressed me about scheduling work is how very difficult it is to test. It's easy to change the scheduler code; it's much harder to measure whether those changes have made the scheduler better or not. Some testing support would help. Ideally, something non-intrusive that could be easily run on a lot of different machines so as to collect better information about the impacts of scheduler changes: * Load balancing: How effectively are all cores being used? * CPU switching: What percentage of the time does a thread stay on the same core? * NUMA statistics: How often does a thread get scheduled on a different processor from it's allocated memory? * Priority inversion: How often is a higher-priority thread idle while a lower-priority thread is running? A student who built such a tool and then ran some tests with a variety of hardware and workloads could really do a lot to advance scheduler development. Eventually, turning such a tool into something that anyone could run and upload data to a central collection site could be a huge advance. Certainly something to think about... Tim ___ 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: Google SoC 2009 Idea
On Thu, Feb 26, 2009 at 9:19 AM, Tim Kientzle kient...@freebsd.org wrote: Robert Watson wrote: On Wed, 25 Feb 2009, Tim Kientzle wrote: I have not gone through the process scheduler code of Free BSD. Hence, I am not yet aware about the current support for Multicore Architectures. Since you posted to a lot of different lists, I think you probably don't already use FreeBSD. (If you did, why would you post to NetBSD and DragonflyBSD lists?) Scheduler work is quite complex and interacts heavily with the rest of the system; it may not be a good choice for someone who doesn't already have a lot of experience with FreeBSD. All the things you say are true, but let's not be too hard on the new guy, however -- many of our GSoC students don't have previous FreeBSD kernel-hacking experience. However, it does mean that they have to pick project ideas that are well-suited to a significant warmup and investigation period on the front end of the project. I apologize to Siddharth and others if I came off overly harsh. My intention was to caution him that he should plan for a lot of work prior to GSoC if he wants to tackle something that's at the core of the OS like this. I'm also not convinced that a scheduler project along these lines would be the most successful, but I wonder if a more experimental-spin proposal for looking at how to investigate poor scheduling decisions using dtrace, instrumentation and metrics to help us understand performance on NUMA systems, and exploring the impact of heuristics might go a long way. That's a good idea. The thing that's always impressed me about scheduling work is how very difficult it is to test. It's easy to change the scheduler code; it's much harder to measure whether those changes have made the scheduler better or not. Some testing support would help. Ideally, something non-intrusive that could be easily run on a lot of different machines so as to collect better information about the impacts of scheduler changes: * Load balancing: How effectively are all cores being used? * CPU switching: What percentage of the time does a thread stay on the same core? * NUMA statistics: How often does a thread get scheduled on a different processor from it's allocated memory? * Priority inversion: How often is a higher-priority thread idle while a lower-priority thread is running? A student who built such a tool and then ran some tests with a variety of hardware and workloads could really do a lot to advance scheduler development. Eventually, turning such a tool into something that anyone could run and upload data to a central collection site could be a huge advance. Speaking from experience, this is the way to go. If you don't do this you'll end up producing a potential black hole in terms of time and resources, which doesn't help your reputation on the project. Some food for thought. Cheers, -Garrett ___ 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
Renaming all symbols in libmp(3)
Hello all, As you may have read some days ago, work has started to make the FreeBSD base system compile better with clang, the BSD licensed C compiler from the LLVM project. One of the reasons why we can't compile the base system yet, is because some applications in the base system (keyserv, newkey, chkey, libtelnet) won't compile, because a library they depend (libmp)on has a function called pow(). By default, LLVM has a built-in prototype of pow(), similar to GCC. Unlike GCC, LLVM raises a compiler error by default. The manual page also mentions this issue. After some talking on IRC, I think the best solution would be to rename all functions in libmp. Even though this may sound very awful at first, it seems the competition has done this as well: http://docs.sun.com/app/docs/doc/819-2246/mp-3mp?a=view I'm not saying that if the Solaris developers jump off a cliff, we should do the same, but looking at the amount of applications that depend on libmp (almost none), I think it's the only definitive solution. So this is the patch I propose to commit to SVN one of these days: http://80386.nl/pub/mp.diff Because this also reduces some warnings when compiling stuff with GCC, I've increased WARNS in various Makefiles. I've also increased the SHLIB_MAJOR and __FreeBSD_version. Any comments? -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpvxZAZH3Q4P.pgp Description: PGP signature
Re: x11 status
On 2009-Feb-25 07:53:08 +0100, Ed Schouten e...@80386.nl wrote: The XFree86 project has been dying ever since almost all the active development moved to the Xorg-project. Xorg has many new features that XFree86 doesn't have, like hardware compositing and improved device detection. And along the way, they've dropped things like integration testing, avoiding regressions and avoiding POLA violations. latest cvs image from Xfree86, and it built FAR easier that xorg, far faster, far simpler to configure ... Why should it matter how easy it is to build a piece of software? You can just run `make -C /usr/ports/x11/xorg install clean' or `pkg_add -r xorg'. Note that Chuck also mentioned faster (the conversion from imake to configure added something like 30% to the time to build X.org for absolutely no benefit - some pieces of X.org now take 4 times as long to configure as to build) and easier to configure. Whilst the ease of building a port doesn't really affect the end user, it does affect the port maintainer - a port that needs lots of tender care and feeding will lead to more rapid maintainer burnout. -- Peter Jeremy pgpd2mAZyFtJx.pgp Description: PGP signature
Re: Renaming all symbols in libmp(3)
On Thu, 26 Feb 2009, Ed Schouten wrote: Hello all, As you may have read some days ago, work has started to make the FreeBSD base system compile better with clang, the BSD licensed C compiler from the LLVM project. One of the reasons why we can't compile the base system yet, is because some applications in the base system (keyserv, newkey, chkey, libtelnet) won't compile, because a library they depend (libmp)on has a function called pow(). By default, LLVM has a built-in prototype of pow(), similar to GCC. Unlike GCC, LLVM raises a compiler error by default. The manual page also mentions this issue. After some talking on IRC, I think the best solution would be to rename all functions in libmp. Even though this may sound very awful at first, it seems the competition has done this as well: http://docs.sun.com/app/docs/doc/819-2246/mp-3mp?a=view I'm not saying that if the Solaris developers jump off a cliff, we should do the same, but looking at the amount of applications that depend on libmp (almost none), I think it's the only definitive solution. So this is the patch I propose to commit to SVN one of these days: http://80386.nl/pub/mp.diff Because this also reduces some warnings when compiling stuff with GCC, I've increased WARNS in various Makefiles. I've also increased the SHLIB_MAJOR and __FreeBSD_version. Why don't you add symbol versioning to libmp, so that old binaries will still work, but new ones will get the new symbols by default. Hmm, will that work without bumping SHLIB_MAJOR? You might want to play around with it and see. -- DE ___ 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: Renaming all symbols in libmp(3)
* Daniel Eischen deisc...@freebsd.org wrote: Why don't you add symbol versioning to libmp, so that old binaries will still work, but new ones will get the new symbols by default. Hmm, will that work without bumping SHLIB_MAJOR? You might want to play around with it and see. Well, even without symbol versioning this could be done, by just making a __strong_reference() between the symbols, but I decided not to do so. I think solutions like these are perfect when just renaming/removing a couple of symbols, but because we're basically touching everything, I thought we'd better just use the old approach. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpRgi8CMXTsD.pgp Description: PGP signature
Re: Renaming all symbols in libmp(3)
On Thu, 26 Feb 2009, Ed Schouten wrote: * Daniel Eischen deisc...@freebsd.org wrote: Why don't you add symbol versioning to libmp, so that old binaries will still work, but new ones will get the new symbols by default. Hmm, will that work without bumping SHLIB_MAJOR? You might want to play around with it and see. Well, even without symbol versioning this could be done, by just making a __strong_reference() between the symbols, but I decided not to do so. I think solutions like these are perfect when just renaming/removing a couple of symbols, but because we're basically touching everything, I thought we'd better just use the old approach. Well, as long as you're in there, maybe you should add symbol versioning anyway, even after a library version bump. Seems like it would be easy since there aren't that many symbols. -- DE ___ 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: Renaming all symbols in libmp(3)
* Daniel Eischen deisc...@freebsd.org wrote: Well, as long as you're in there, maybe you should add symbol versioning anyway, even after a library version bump. Seems like it would be easy since there aren't that many symbols. I assume I should just mark all symbols with version FBSD_1.1? If so, the following patch should be good enough: http://80386.nl/pub/mp.diff -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgphdbc8hCD4J.pgp Description: PGP signature
Re: x11 status
,--- You/Peter (Fri, 27 Feb 2009 05:12:25 +1100) * | And along the way, they've dropped things like integration testing, | avoiding regressions and avoiding POLA violations. Since I don't care about the new X anymore, I can afford to express my opinion bluntly: the Xorg we have in ports now is a disaster. This opinion was arrived to at the cost of more than two weeks undoing the damage to my systems under the circumstances not conductive for such activities. | latest cvs image from Xfree86, and it built FAR easier that xorg, | faster, far simpler to configure ... | | Why should it matter how easy it is to build a piece of software? You | can just run `make -C /usr/ports/x11/xorg install clean' or `pkg_add -r | xorg'. | | Note that Chuck also mentioned faster (the conversion from imake to | configure added something like 30% to the time to build X.org for | absolutely no benefit - some pieces of X.org now take 4 times as long | to configure as to build) and easier to configure. | | Whilst the ease of building a port doesn't really affect the end | user, I strongly disagree: a FreeBSD user is almost by definition somebody who ultimately turns from using built packages to building ports from source, with options of personal preference. So, how things are done build-wise, does affect me, big time. If the only option to get the contributed (ports) software were using packages, I'd be using Debian, not FreeBSD. I have no desire to have HAL on my systems, for example, and FreeBSD had been giving me the option of not having it -- just build it with an appropriate option in /etc/make.conf. And other such things. Struggling with the Xorg 1.5 unfortunate upgrade, and examining the ports make files for Xorg/Gnome moved me to the ultimate decision: don't try to comprehend this mess and stick with something that works. I rolled back everything x11 to xorg-server 1.4.2 and have no plans to upgrade it -- ever, on any of my systems: the old one works, perhaps not perfectly, but predictably, and why would I need a new one? So, for the last month I've been doing weekly rebuilds of ports with everything upgraded -- other that the /usr/ports/x11* trees, which will be frozen until I see that other people stop reporting serious Xorg problems, which may well never happen. This is a testament to the greatness of the ports system and an illustration to my claim: building a port does affect the end user. -- Alex -- alex-goncha...@comcast.net -- ___ 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: Renaming all symbols in libmp(3)
On Thu, Feb 26, 2009, Ed Schouten wrote: One of the reasons why we can't compile the base system yet, is because some applications in the base system (keyserv, newkey, chkey, libtelnet) won't compile, because a library they depend (libmp)on has a function called pow(). By default, LLVM has a built-in prototype of pow(), similar to GCC. Unlike GCC, LLVM raises a compiler error by default. The manual page also mentions this issue. I think most apps that used to use libmp have transitioned to libgmp, so I don't have much of an opinion on this change... However, if the compiler as a builtin for the math.h-style pow() function, and the builtin causes it to choke even when math.h isn't #included, that's a bug in the compiler. The people who are proposing that we make the base system LLVM-compatible should be more forceful in insisting that LLVM be fixed. ;-) What do the LLVM folks propose to do about all the (perfectly legal) programs out there that have a variable called 'exp'? ___ 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: Renaming all symbols in libmp(3)
David Schultz schrieb: On Thu, Feb 26, 2009, Ed Schouten wrote: One of the reasons why we can't compile the base system yet, is because some applications in the base system (keyserv, newkey, chkey, libtelnet) won't compile, because a library they depend (libmp)on has a function called pow(). By default, LLVM has a built-in prototype of pow(), similar to GCC. Unlike GCC, LLVM raises a compiler error by default. The manual page also mentions this issue. I think most apps that used to use libmp have transitioned to libgmp, so I don't have much of an opinion on this change... However, if the compiler as a builtin for the math.h-style pow() function, and the builtin causes it to choke even when math.h isn't #included, that's a bug in the compiler. The people who are proposing that we make the base system LLVM-compatible should be more forceful in insisting that LLVM be fixed. ;-) What do the LLVM folks propose to do about all the (perfectly legal) programs out there that have a variable called 'exp'? No, it's invalid code to have a function named pow() in a hosted environment which is not /The/ pow(). Having a *local* variable named exp is fine, because this declaration shadows the function. A *global* variable on the other hand is not allowed. ___ 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: Renaming all symbols in libmp(3)
Christoph Mallon schrieb:
David Schultz schrieb:
On Thu, Feb 26, 2009, Ed Schouten wrote:
One of the reasons why we can't compile the base system yet, is because
some applications in the base system (keyserv, newkey, chkey, libtelnet)
won't compile, because a library they depend (libmp)on has a function
called pow(). By default, LLVM has a built-in prototype of pow(),
similar to GCC. Unlike GCC, LLVM raises a compiler error by default. The
manual page also mentions this issue.
I think most apps that used to use libmp have transitioned to
libgmp, so I don't have much of an opinion on this change...
However, if the compiler as a builtin for the math.h-style pow()
function, and the builtin causes it to choke even when math.h
isn't #included, that's a bug in the compiler. The people who are
proposing that we make the base system LLVM-compatible should be
more forceful in insisting that LLVM be fixed. ;-) What do the LLVM
folks propose to do about all the (perfectly legal) programs out
there that have a variable called 'exp'?
No, it's invalid code to have a function named pow() in a hosted
environment which is not /The/ pow().
Having a *local* variable named exp is fine, because this declaration
shadows the function. A *global* variable on the other hand is not allowed.
Just a hint, why you really mustn't use global names which are reserved
by the standard:
double pow(double x, double y)
{
abort();
}
int main(void)
{
printf(%f\n, pow(10., 2.));
return 0;
}
%gcc -w bla.c
%./a.out
100.00
%
Yes, GCC does that and it's perfectly valid.
___
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: Renaming all symbols in libmp(3)
On Thu, 26 Feb 2009, Ed Schouten wrote: * Daniel Eischen deisc...@freebsd.org wrote: Well, as long as you're in there, maybe you should add symbol versioning anyway, even after a library version bump. Seems like it would be easy since there aren't that many symbols. I assume I should just mark all symbols with version FBSD_1.1? If so, the following patch should be good enough: http://80386.nl/pub/mp.diff Yeah, looks about right. That was easy :-) -- DE ___ 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: Renaming all symbols in libmp(3)
On Thu, Feb 26, 2009, Christoph Mallon wrote: David Schultz schrieb: On Thu, Feb 26, 2009, Ed Schouten wrote: One of the reasons why we can't compile the base system yet, is because some applications in the base system (keyserv, newkey, chkey, libtelnet) won't compile, because a library they depend (libmp)on has a function called pow(). By default, LLVM has a built-in prototype of pow(), similar to GCC. Unlike GCC, LLVM raises a compiler error by default. The manual page also mentions this issue. I think most apps that used to use libmp have transitioned to libgmp, so I don't have much of an opinion on this change... However, if the compiler as a builtin for the math.h-style pow() function, and the builtin causes it to choke even when math.h isn't #included, that's a bug in the compiler. The people who are proposing that we make the base system LLVM-compatible should be more forceful in insisting that LLVM be fixed. ;-) What do the LLVM folks propose to do about all the (perfectly legal) programs out there that have a variable called 'exp'? No, it's invalid code to have a function named pow() in a hosted environment which is not /The/ pow(). Having a *local* variable named exp is fine, because this declaration shadows the function. A *global* variable on the other hand is not allowed. The C standard makes no guarantees because it doesn't want to say much about system libraries or how apps are actually linked, but in practice people have found it very useful to do things like link against libraries with special debugging versions of malloc(), and in the past, developers have tried to ensure that this continues to work. (You can find some old threads in the archives.) Of course, people who do this need to take adequate precautions (e.g., linking their programs in the right order, using weak symbols where appropriate), but it does work, and it would be nice if the compiler didn't break it. As for gcc's math builtins, most of them are buggy. They fail to respect the dynamic rounding mode, fail to generate exceptions where appropriate, fail to respect FENV_ACCESS and other pragmas, etc. Also, the complex builtins use simplified formulas that don't get the right answers for complex numbers with inf/nan components. Try running some of the tests in tools/regression/lib/msun without -fno-builtin and see what happens ;-) ___ 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: Renaming all symbols in libmp(3)
David Schultz schrieb: On Thu, Feb 26, 2009, Christoph Mallon wrote: David Schultz schrieb: On Thu, Feb 26, 2009, Ed Schouten wrote: One of the reasons why we can't compile the base system yet, is because some applications in the base system (keyserv, newkey, chkey, libtelnet) won't compile, because a library they depend (libmp)on has a function called pow(). By default, LLVM has a built-in prototype of pow(), similar to GCC. Unlike GCC, LLVM raises a compiler error by default. The manual page also mentions this issue. I think most apps that used to use libmp have transitioned to libgmp, so I don't have much of an opinion on this change... However, if the compiler as a builtin for the math.h-style pow() function, and the builtin causes it to choke even when math.h isn't #included, that's a bug in the compiler. The people who are proposing that we make the base system LLVM-compatible should be more forceful in insisting that LLVM be fixed. ;-) What do the LLVM folks propose to do about all the (perfectly legal) programs out there that have a variable called 'exp'? No, it's invalid code to have a function named pow() in a hosted environment which is not /The/ pow(). Having a *local* variable named exp is fine, because this declaration shadows the function. A *global* variable on the other hand is not allowed. The C standard makes no guarantees because it doesn't want to say much about system libraries or how apps are actually linked, but The C standard is very explicit which identifiers are reserved, see §7.1.3 in practice people have found it very useful to do things like link against libraries with special debugging versions of malloc(), and in the past, developers have tried to ensure that this continues to work. (You can find some old threads in the archives.) Of course, people who do this need to take adequate precautions (e.g., linking their programs in the right order, using weak symbols where appropriate), but it does work, and it would be nice if the compiler didn't break it. As for gcc's math builtins, most of them are buggy. They fail to respect the dynamic rounding mode, fail to generate exceptions where appropriate, fail to respect FENV_ACCESS and other pragmas, etc. Also, the complex builtins use simplified formulas that don't get the right answers for complex numbers with inf/nan components. Try running some of the tests in tools/regression/lib/msun without -fno-builtin and see what happens ;-) pow() is just an example. The compiler may do magic with any call which has semantics defined by the C standard in a hosted environment. ___ 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
portupgrade spurious skips
Hi folks, In the past few months I've noticed a bug in portupgrade. When I update my ports tree and do `portupgrade -a', often a few ports will be skipped, supposedly because another port on which they depend failed to install. However, the apparently failed port actually did not fail, and if I rerun `portupgrade -a', some of the skipped ports will install successfully without complaint. After enough iterations I can eventually get all of them. I'd like to file a PR about this, but it's a little bit tricky coming up with a test case, since the behavior depends on having outdated packages installed, and on the dependencies between them. Moreover, after I run `portupgrade -a' and notice the problem, the state of the installed packages has changed and the same packages aren't skipped the next time. So my question is whether anyone has ideas about how to construct a reasonable test case that could help me make this reproducible and easier to investigate. Any thoughts? Thanks in advance. -- Nate Eldredge neldre...@math.ucsd.edu ___ 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: Renaming all symbols in libmp(3)
On Thu, Feb 26, 2009, Christoph Mallon wrote: David Schultz schrieb: As for gcc's math builtins, most of them are buggy. They fail to respect the dynamic rounding mode, fail to generate exceptions where appropriate, fail to respect FENV_ACCESS and other pragmas, etc. Also, the complex builtins use simplified formulas that don't get the right answers for complex numbers with inf/nan components. Try running some of the tests in tools/regression/lib/msun without -fno-builtin and see what happens ;-) pow() is just an example. The compiler may do magic with any call which has semantics defined by the C standard in a hosted environment. Okay, so first, the world doesn't revolve around the strictest possible interpretation of the C standard. For example, FreeBSD has an extension such that `printf(%s, NULL)' prints (null) instead of having undefined behavior. But gcc translates this into `puts(NULL)', which once again has undefined behavior. You can put on your lawyer hat and counter that the beloved standard doesn't guarantee that any such thing will work, but that's a very contrarian attitude; the bottom line is that it's a POLA violation, and the extension worked just fine for many years. Second, the problems with the math builtins I cited above violate even a strict interpretation of the C standard. Third, this is a digression, and this is the last I'm going to say about it. :-) ___ 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: portupgrade spurious skips
In the last episode (Feb 26), Nate Eldredge said: In the past few months I've noticed a bug in portupgrade. When I update my ports tree and do `portupgrade -a', often a few ports will be skipped, supposedly because another port on which they depend failed to install. However, the apparently failed port actually did not fail, and if I rerun `portupgrade -a', some of the skipped ports will install successfully without complaint. After enough iterations I can eventually get all of them. I'd like to file a PR about this, but it's a little bit tricky coming up with a test case, since the behavior depends on having outdated packages installed, and on the dependencies between them. Moreover, after I run `portupgrade -a' and notice the problem, the state of the installed packages has changed and the same packages aren't skipped the next time. So my question is whether anyone has ideas about how to construct a reasonable test case that could help me make this reproducible and easier to investigate. Any thoughts? me too.. It seems to happen frequently when doing 20 or so ports. Every week or so I upgrade old ports and don't have problems, but after a gnome or xorg update that ends up bumping the portrevision for half my installed ports, it always takes three or four portupgrade -a loops for everything to buid. If you've got ZFS, you can snapshot your filesystems, and if portupgrade fails, roll back to the snapshot and do it again to see if it happens on the same port a second time. Or if you know ruby, you could instrument the code that checks for port build errors and see if it's got a bug in it... -- Dan Nelson dnel...@allantgroup.com ___ 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: Renaming all symbols in libmp(3)
David Schultz schrieb: On Thu, Feb 26, 2009, Christoph Mallon wrote: David Schultz schrieb: As for gcc's math builtins, most of them are buggy. They fail to respect the dynamic rounding mode, fail to generate exceptions where appropriate, fail to respect FENV_ACCESS and other pragmas, etc. Also, the complex builtins use simplified formulas that don't get the right answers for complex numbers with inf/nan components. Try running some of the tests in tools/regression/lib/msun without -fno-builtin and see what happens ;-) pow() is just an example. The compiler may do magic with any call which has semantics defined by the C standard in a hosted environment. Okay, so first, the world doesn't revolve around the strictest possible interpretation of the C standard. For example, FreeBSD So you haven't seen enough crashes and security problems due to sloppy coding in the past decades, yet? I don't agree with everything the standard says (e.g. it tells you that it's a bad idea to call a function strange_quark()), but there's no reason not to avoid a simple name clash. has an extension such that `printf(%s, NULL)' prints (null) instead of having undefined behavior. But gcc translates this into This *is* perfectly valid undefined behaviour. `puts(NULL)', which once again has undefined behavior. You can put And this is, too. I prefer the crash variant (or the one with the demons flying out of the programmers nose), because I've seen quite some programs which showed me (null) where they should have printed something sensible and bugs (sadly) only seem to have a real chance of being fixed in a timely manner, when they are hard crashes. A program limping along with invalid data is very bad and could be a security problem, too - imagine a (null) in an sprintf()ed path or something. on your lawyer hat and counter that the beloved standard doesn't guarantee that any such thing will work, but that's a very contrarian attitude; the bottom line is that it's a POLA violation, and the extension worked just fine for many years. It's a POLA violation in the first place, to have a function named pow(), which does not the real pow() thing. Second, the problems with the math builtins I cited above violate even a strict interpretation of the C standard. GCC is buggy, but that's a totally different story. Third, this is a digression, and this is the last I'm going to say about it. :-) Me, too. ___ 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
