In message <gg4h90$do9$02$1@news.t-online.com>, Hans-Bernhard Br�ker <HBBroeker@t-online.de> writes>FreeRTOS.org wrote: >> You are liable only if you have been neglegent. > >Well, as the saying goes: At court and on the open sea, we're all in >God's hand. > >You are liable if you are *found* negligent in a court of law. Now in >an ideal world people would only be found negligent if they actually >did neglect significant parts of their duties. But ours is, of course, >not an ideal world. > >> Somebody very high up in the FAA once said to me - "its impossible to >>validate a compiler as there are an infinite number of inputs" [BTW: >>I don't buy that statement myself]. > >On a similar note, it's impossible to validate any chip with more than >about 60 pins, simply on the grounds that even a test of all possible >combinations of static binary inputs to its pins (not to mention analog >inputs, voltage thresholds, timing, sequence, ...) would never finish >during the earth's life expectancy.So you have to take "reasonable steps" to validate. As the industry norm is to use certain test suites as part of it that is the standard. If you can find another test suite of similar coverage (Perennial is some 70,000 tests for a C compiler, written by known people who also develop the standard) quite apart from the build and regression test suites etc along with showing that care has been taken in the development of the compiler (ie the process, specifications and documentation etc) that that is OK. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
ARM IDE
Started by ●November 12, 2008
Reply by ●November 21, 20082008-11-21
Reply by ●November 21, 20082008-11-21
In message <IuudncF2mMiaQ7jUnZ2dnUVZ8umdnZ2d@lyse.net>, David Brown <david.brown@hesbynett.removethisbit.no> writes> >I understand all about these support issues, and the reasons why it is >often undesirable to allow users direct contact with developers. I >have also been on the other side of the equation. Yes, we *do* have >end users who talk directly to myself and other software developers - >not many, but some experienced and technically competent end users have >direct contact. It can be of great benefit to both parties. I've also >had occasional direct contact with developers of hardware parts we buy >- again, it benefits both sides.This is true for compiler companies also. Some customers do get though to the developers (though often the support team is more appropriate) The trouble is "everyone" thinks they are an expert.>The important thing here is that we are talking about expert users - >not average users, and certainly not the "idiots, simpletons, and those >who seem unable to read the manual".How do you tell them apart.... you the first line support weed them out. BTW in many companies the developers do a spell on first line support, in others the developers see the support calls on cc. Usually If you can't get past first line support there is a reason for that. The developers probably are aware of you and told support they don't want to talk to you. Sorry if that hurts.>For almost all open source projects, many low-cost tools, and a fair >number of high-cost tools, a major source of support is from public web >forums, newsgroups, or mailing lists. A good public support forum is >frequented by the tools developers, as well as expert users who enjoy >using the tool, and are happy to help other users.This is true. The developers usually go on these under fake names. Some of the "expert users" are the developers. :-)> Clearly there are times when conventional technical support, either >directly to the suppliers or via a distributor, is better suited - for >example, you can't sign an NDA with a public forum.Quite so.>I have always been a fan of choosing the best tool for the job, and >that choice depends on many factors - technical support is only one of >them.A lot of it is where you have come from and where you want to go as much as what you want to do now.>>>> More to the point with the complete version control they have they >>>>can tell me EXACTLY who did which source file when and the full >>>>history. Also they have all the supporting documentation. I doubt >>>>you can do this with any version of GCC >>> I don't need to ask - I can simply look at the publicly available >>>source code repository: >>> http://gcc.gnu.org/viewcvs/ >> For EVERY version of GCC? >> You know what all the code does and why it is there? >> > >The quality of the logs and comments probably varies somewhat, as it >does in any project from any developers. But the history goes back a >fair way - look at <http://gcc.gnu.org/viewcvs?view=rev&revision=1>. > >Of course, that particular source code repository is for the main FSF >gcc tree. There are a great many other gcc development trees for >different targets, experimental branches, or alternative development >branches.This is my point you can possibly validate a specific GCC binary but not GCC per say. Nor GCC for "arm" or GCC from a part particular supplier.> Some of these will be directly open to the public, others will be >internal to their developers (the GPL license requires you to make the >source code available along with binary releases, but makes no >requirements on the source history).When we validate compilers we normally have to sign an NDA and have an internal view of their development> If you are getting your gcc binaries ready-made (such as from >CodeSourcery) rather than checking out and building your own copy, you >might want to ask your particular supplier about their source code >tracking and logging.This would be essential. I am sure Code Sorcery can supply this. However you would only be validating that part ticular version of the binary form CS. Not GCC or the source.> Of course, CodeSourcery commit most of their changes back to the main >FSF tree, so you can look them up there."Most" that is the problem. GCC is developed asynchronously by multiple sources who may or may not feed their changes back to the FSF -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●November 21, 20082008-11-21
In message <4925D675.633DEAB6@bytecraft.com>, Walter Banks <walter@bytecraft.com> writes> > >"FreeRTOS.org" wrote: > >> Out of interest, I have seen most bugs in generated code where non standard >> features are used (like __interrupt qualifiers, etc.) and particularly >> subtle stack frame problems that can be very reliant on particual events >> occurring just at the wrong moment (temporal effects) - for example an >> interrupt being taken just as another interrupt is being exited. The >> interrupt entry/exit code being very hardware specific. Do the Plum Hall >> tests pick up on that sort of thing? > >No. Plum Hall and Perennial are language conformance tests. The kind of >feature you are describing is implementation specific and not covered. > >Plum Hall and Perennial both are well respected as independent >test suites that validate language implementation against the standards. >Both companies are part if WG-14 and offer an independent view >of how the standard should be interpreted. > >There is a lot of confusion about the meaning of successfully running >these test suites. Compiler companies run these as one of several >standard and private tests to validate and release compilers.My point has been there are no comparable tests done on the GCC compilers in general. One or two specific versions from specific vendors are tested well but that only covers the specific binary tested. NOT the source code. SO in general GCC is not as a family validatable Just specific binaries if you can get access to the company that does that binary. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●November 21, 20082008-11-21
In message <C5idnS6fWt4aS7jUnZ2dnUVZ8r6dnZ2d@lyse.net>, David Brown <david.brown@hesbynett.removethisbit.no> writes>> Statistically I have found it worse amongst those who say "If I had >>the source I could fix it" which is why I am very unconvinced when >>people say having the course of a compiler is useful >> > >You do realise he is talking about the source to the *library* here, >not the compiler? An experienced developer of a high level is going to >be just as capable of understanding, debugging and correcting a >toolkit's library as the library developers are - assuming there is >decent information available about things like calling and naming >conventions in the library.Possibly, maybe and not normally. That said several commercial compilers do make the library source available its just not FOSS.> They are not going to be as skilled at specific tasks such as writing >the library code in a way that it compiles properly for all its >targets, and perhaps they are not going to write code as optimally or >portably. And they are certainly not going to be able to run all the >tests and qualifications.So you have an untested and unqualified non-standard library....>But in situations like this one (and cases I have seen myself), the >user is perfectly capable of finding and correcting a bug in the >library source code if he has access to it.The problem is that will out the full regression tests the user has no idea if he has fixed the bug without causing any other problems. See the definition of debugging :-) http://www.phaedsys.com/resources/posters/define.pdf> The fact is that some (by no means all) compiler support lines cannot >deal appropriately with this situation. They either assume that the >user is the problem, or they follow rigid and inappropriate routines >such as asking for complete examples of the problem.Normally They don't assume the user is the problem . Asking for a complete example is not inappropriate. Often what the user reports and what they are actually doing and what they are trying to do are three different things.>I agree that having the source to the *compiler* is not helpful to most >users when it comes to finding or fixing bugsI am glad that we agree on that. You are there to USE the tools to develop you products. Not to develop the tools>(it can be useful for other things, such as for changing development >platform,I don t see how. See above.> archiving tools,Not really. You need to archive the actual binary you are using,. (Possibly with a PC to run it on.> or as a safety net in case the compiler developers stop development on >the tools).Why would you need the source here?> But no one is talking about compiler source code here.? What were you talking about? -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●November 21, 20082008-11-21
Hi there, Chris H wrote:> In message <C5idnS6fWt4aS7jUnZ2dnUVZ8r6dnZ2d@lyse.net>, David Brown >>> Statistically I have found it worse amongst those who say "If I had >>> the source I could fix it" which is why I am very unconvinced when >>> people say having the course of a compiler is useful >> >> You do realise he is talking about the source to the *library* here, >> not the compiler? An experienced developer of a high level is going >> to be just as capable of understanding, debugging and correcting a >> toolkit's library as the library developers are - assuming there is >> decent information available about things like calling and naming >> conventions in the library. > > Possibly, maybe and not normally. That said several commercial > compilers do make the library source available its just not FOSS.Why "not normally"? Why do you always assume users are incompetent? I know that (unfortunately) many are, but I don't want to get a lobotomy to be allowed to talk to support. Hence I try to give the support guy enough clues that I know what I'm talking about. The more frustrating it is to get bounced off for formal reason ("no FS image included") without anyone actually having *read* the problem.>> They are not going to be as skilled at specific tasks such as writing >> the library code in a way that it compiles properly for all its >> targets, and perhaps they are not going to write code as optimally or >> portably. And they are certainly not going to be able to run all the >> tests and qualifications. > > So you have an untested and unqualified non-standard library....Right. And that's the reason why I want my library bug fixes approved by a support guy. Plus, there usually are contracts that don't allow me to ship modified code. For a FOSS library, I'd fix the thing, send the patch to the mailing list, and could in theory forget about it.>> But in situations like this one (and cases I have seen myself), the >> user is perfectly capable of finding and correcting a bug in the >> library source code if he has access to it. > > The problem is that will out the full regression tests the user has no > idea if he has fixed the bug without causing any other problems.I had posted a code snippet. Can you give an example where my "fixed" version is wrong? In this case, I had the ATAPI specs on my side which claim that there is a 32-bit little-endian value. You do not assemble those with possibly signed chars.>> The fact is that some (by no means all) compiler support lines cannot >> deal appropriately with this situation. They either assume that the >> user is the problem, or they follow rigid and inappropriate routines >> such as asking for complete examples of the problem. > > Normally > They don't assume the user is the problem . > Asking for a complete example is not inappropriate.If I can make one, I do. In the case I used as an example, the problem was in the interoperation of a huge software stack. A complete, self-contained example would just be inappropriate. In particular, I would have the work to make it, the support guy would have a lot of work to understand it, and to find that the problem is actually in his code, not in my big example. Take a different, simpler example. Let's assume you find an unchecked 'malloc' in library source. Under very tight memory constraints, the system could crash because 'malloc' returns 0. How would you report that? Would you build a system tweaked so much to exercise that case, or would you just say "Function build_filename() in file open.c does not check the malloc() in line 127 for return value NULL and crashes in this case".>> I agree that having the source to the *compiler* is not helpful to >> most users when it comes to finding or fixing bugs > > I am glad that we agree on that. You are there to USE the tools to > develop you products. Not to develop the toolsUnfortunately, I've spent too much time "debugging" the tools. If I had tools source, I'd probably take a peep. But I don't insist on it. However, I think when I spend two days trying to make a self-contained example showing off a compiler bug, having the source *could* help. Stefan
Reply by ●November 21, 20082008-11-21
In message <gg6f0a.8c.1@stefan.msgid.phost.de>, Stefan Reuther <stefan.news@arcor.de> writes>Hi there, > >Chris H wrote: >> So you have an untested and unqualified non-standard library.... > >Right. And that's the reason why I want my library bug fixes approved by >a support guy. Plus, there usually are contracts that don't allow me to >ship modified code. > >For a FOSS library, I'd fix the thing, send the patch to the mailing >list, and could in theory forget about it.Exactly my point.... you skipped the full documentation and full regression testing bits. Let alone the language testing (eg Perennial) -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●November 21, 20082008-11-21
David Brown <david.brown@hesbynett.removethisbit.no> writes:> I understand all about these support issues, and the reasons why it is > often undesirable to allow users direct contact with developers. I have > also been on the other side of the equation. Yes, we *do* have end > users who talk directly to myself and other software developers - not > many, but some experienced and technically competent end users have > direct contact. It can be of great benefit to both parties. I've also > had occasional direct contact with developers of hardware parts we buy - > again, it benefits both sides. > > The important thing here is that we are talking about expert users - not > average users, and certainly not the "idiots, simpletons, and those who > seem unable to read the manual". > > For almost all open source projects, many low-cost tools, and a fair > number of high-cost tools, a major source of support is from public web > forums, newsgroups, or mailing lists. A good public support forum is > frequented by the tools developers, as well as expert users who enjoy > using the tool, and are happy to help other users. Clearly there are > times when conventional technical support, either directly to the > suppliers or via a distributor, is better suited - for example, you > can't sign an NDA with a public forum.What's more than annoying is to have an NDA in place with a hardware manufacturer and then not be able to make contact with anyone with knowledge of the product in question. Or contact is made and the contact never replies.
Reply by ●November 21, 20082008-11-21
Chris H <chris@phaedsys.org> wrote:> In message <IuudncF2mMiaQ7jUnZ2dnUVZ8umdnZ2d@lyse.net>, David Brown > <david.brown@hesbynett.removethisbit.no> writes >> If you are getting your gcc binaries ready-made (such as from >>CodeSourcery) rather than checking out and building your own copy, you >>might want to ask your particular supplier about their source code >>tracking and logging. > This would be essential. I am sure Code Sorcery can supply this. However > you would only be validating that part ticular version of the binary > form CS. Not GCC or the source.So the really awesome thing about closed-source compilers is that you buy a validated binary but the really awful thing about open-source compilers is that you buy a validated binary? -a
Reply by ●November 22, 20082008-11-22
In message <gg7h7h$tcn$1@aioe.org>, Anders.Montonen@kapsi.spam.stop.fi.invalid writes>Chris H <chris@phaedsys.org> wrote: >> In message <IuudncF2mMiaQ7jUnZ2dnUVZ8umdnZ2d@lyse.net>, David Brown >> <david.brown@hesbynett.removethisbit.no> writes >>> If you are getting your gcc binaries ready-made (such as from >>>CodeSourcery) rather than checking out and building your own copy, you >>>might want to ask your particular supplier about their source code >>>tracking and logging. >> This would be essential. I am sure Code Sorcery can supply this. However >> you would only be validating that part ticular version of the binary >> form CS. Not GCC or the source. > >So the really awesome thing about closed-source compilers is that you >buy a validated binary but the really awful thing about open-source >compilers is that you buy a validated binary?This is the sort of problem with discussions like this they get clouded by religious bigotry I did not mention closed or open source. We were discussing the problems of validating GCC compilers. GCC being a very large collection of compilers from many sources that has minimal control and trace ability. The other point was that if you validate for example a Byte craft compiler (since Walter is partaking of this thread) you have the complete compiler development and history in one place and the binary only comes from one place and all the Byte Craft compilers of that version for that target are validated. For GCC you can not validate "GCC compilers for a specific target" just a specific variant from a specific supplier if you can get the full history and the version you are validation is under similar control to the Bytecraft compiler. Ie if you validated the GCC arm compiler from Code Sourcery it would have no impact or relevance to any other GCC ARM compiler. OR for that matter any Code Sorcery compiler built from source by some one else (even if it was the same version as the one tested) SOME GCC suppliers can do this and validate their compilers others can't but the vast majority of GCC compilers are virtually impossible to validate. Recently I was talking to a company doing a safety critical project who decided after some investigation that it would be far more cost effective both in time and money to use a commercial compiler at about 4K USD per seat for their developers rather than a "supported" GCC compiler as the cost of validating the GCC would be far in excess of validating the commercial compiler. This has nothing to do with open or closed source. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●November 22, 20082008-11-22
Chris H wrote:> In message <4925D675.633DEAB6@bytecraft.com>, Walter Banks > <walter@bytecraft.com> writes >> >> >> "FreeRTOS.org" wrote: >> >>> Out of interest, I have seen most bugs in generated code where non >>> standard >>> features are used (like __interrupt qualifiers, etc.) and particularly >>> subtle stack frame problems that can be very reliant on particual events >>> occurring just at the wrong moment (temporal effects) - for example an >>> interrupt being taken just as another interrupt is being exited. The >>> interrupt entry/exit code being very hardware specific. Do the Plum >>> Hall >>> tests pick up on that sort of thing? >> >> No. Plum Hall and Perennial are language conformance tests. The kind of >> feature you are describing is implementation specific and not covered. >> >> Plum Hall and Perennial both are well respected as independent >> test suites that validate language implementation against the standards. >> Both companies are part if WG-14 and offer an independent view >> of how the standard should be interpreted. >> >> There is a lot of confusion about the meaning of successfully running >> these test suites. Compiler companies run these as one of several >> standard and private tests to validate and release compilers. > > My point has been there are no comparable tests done on the GCC > compilers in general. One or two specific versions from specific vendors > are tested well but that only covers the specific binary tested. NOT the > source code. > > SO in general GCC is not as a family validatable Just specific binaries > if you can get access to the company that does that binary. >I think we all agree on that - Plum Hall (and Perennial) validation is only possible on for *any* compiler and *any* company when run on a specific binary with specific libraries. Some compiler developers make a big marketing point out of validating everything and making sure their compilers pass as many of the tests as possible. Other compiler developers use these as tools to test and improve the quality of their compilers, and will do specific tests and validations for specific compiler versions as and when required. GCC is the "GNU Compiler Collection", and consists of a number of language front-ends, a middle-end in various versions, and a large number of official back-end targets, and a very large number of unofficial back-ends. Then there are a number of development branches and vendor-specific branches, and lots of different libraries. Add to this the large number of different host environments and it is perfectly clear that gcc is not one single compiler, and the idea of using Plum Hall to "validate gcc" is meaningless.