Errors when cross-compiling the kernel

Martin,

I'm running on a quad-core Windows 7/64 system, and judging the time taken to compile the 9 programs in the NTP suite using Visual Studi0

On the RPi I have used Lazarus which is similar, and allows almost common code between Windows and Linux programs.

Cards were used by the Computer Department at university when they bought an IBM 360, and a room full of card punches was rather noisy! I can't recall now whether it was noisier than the room full of 8-track paper tape Flexowriters we at the Engineering Department were using, and yes, we did patch those by hand at times. Almost all of the access to the IBM 1130 we had was hands-on by the researchers and some undergraduates.

Leaving debug code is a good idea, except when it accounts for 90% of the program's execution time as seen by a real-time profiler. I do still try and make my own code as compact as possible, but particularly as fast as possible, and the profiler has been a big help there. I haven't done any serious debugging on the RPi, though - it's been more struggling with things like GNU radio build taking 19 hours and then failing!

I find that instant grahpical interface make a change, compile and run ebcourages the youngsters to try ANYTHING to fix problem and not use any form of version control. Then they go off fixing everything else they have now broken because they did not acquire data first, to find out where the problem maybe then use debugs or other data to prove the area of fault, then prove what the fault is if necessary using pencil, paper and a bit of grey matter.

Most people want to put any old code down first, not interested in algorithm or design etc..

On 17/12/2013 10:01, Paul wrote: []

If that's the case, surely they should be better trained in using the tools, rather than deliberately making the tools slower and more difficult to use? Give points for algorithm design!

(That originally came out as "give pints" - might be something in that!)

Certainly training would help, but the critical missing ingredient--necessitated by cumbersome tools--is the development of engineering discipline...and that is always in short supply.

I don't know about Lazarus: but the C source is identical on the RPi since it uses the same GNU C compiler and make that all Linux systems use.

I used those at Uni, but they were feeding an Elliott 503, a set of huge grey boxes housing solid state electronics but made entirely with discrete transistors. It compiled Algol 60 direct from paper tape and, embarrassingly, no matter what I tried on the 1902S, I was never able to come near the Ellott's compile times: just shows the inherent superiority of 50 microsecond core backing store over 2800 rpm disk drives.

I that case it was done very badly. The trick of minimising overhead is the be able to use something like:

if (debug) { /* debug tests and displays */ }

rather than leaving, e.g. assertions, inline in live code or, worse, having debugging code so interwoven with the logic that it can't be disabled during normal operation. I agree that the overheads of that approach are high, where the overheads of several "if (debug)..." statement are about as low as its possible to get.

I think you mean if (unlikely(debug)) { debug stuff }

If you want low impact, then tell the compiler it isn't likely so it can twiddle the branch prediction stuff.

I don't know which compiler you use, but in mine assert is only compiled into code in debug builds. There's nothing left in a non-debug build.

Andy

Normally in C you use the preprocessor to eliminate all debug code at compile time when it is no longer required, so even the overhead of the if (debug) and the size of the code in the if statement is no longer there.

Not necessarily bad, just doing a lot of stuff not necessary to the production version. But now it's as you recommend - optional - using conditional compile or boolean variables as you show.

In comp.sys.raspberry-pi message , Tue, 17 Dec 2013 22:55:04, Martin Gregorie posted:

At one stage, I used an Elliott 905, with only paper tape - a 250 char/sec reader, and a punch (and console TTY, maybe?).

By sticking to the end of the Algol compiler a short program, the compiler could be persuaded to read from a BS4421 interface, initially with a 1000 char/sec reader. By instead connecting the BS4421 to the site Network, a speed of (IIRC) about 6000 char/sec could be obtained.

Earlier, I used an ICT/ICL 1905. Its CPU had two features not commonly found in modern machines :

(1) A machine-code instruction "OBEY", (2) A compartment which in ours stored the site engineer's lunch.

This build of which you speak is the problem with that approach: you'll have to recompile the program before you can start debugging the problem while I can simply I can ask the user to set the debug flag, do it again and unset the debug flag.

Your recompile to turn assertions back on can take days in a real life situation because you may need to do full release tests and get management buy-in before you can let your user run it on live data. Alternatively, it can take at least as long to work out what combo of data and user action is needed to duplicate the bug and then make it happen on a testing system. Bear in mind that Murphy will make sure this happens on sensitive data and that as a consequence you'll have hell's delight getting enough access to the live system to work out what happened, let alone being able to get hold of sufficient relevant data to reproduce the problem.

Two real world examples. In both cases we left debugging code in the production system:

(1) The BBC's Orpheus system dealt with very complex musical data and was used by extremely bright music planning people. I provided a debug control screen for them so they could instantly turn on debug, repeat the action and turn debug off: probably took 15-20 seconds to do and I'd get the diagnostic output the next day. A significant number of times the problem was finger trouble, easy to spot because I had their input and easy to talk them through it too. If it was a genuine bug or something that needed enhancement, such as searching for classical music works by name, I had absolutely all the information we needed to design and implement the change: input, program flow, DB access, and output.

(2) We also left debugging in a very high volume system that handled call detail records for a UK telco. This used exactly the debug enabling method I showed earlier and yet it still managed to process 8000 CDRs/sec (or 35,000 phone number lookups/sec if you prefer) and that was back in

My conclusion is that recompiling to remove well designed debugging code, without measuring the effectiveness doing it, is yet another example of premature optimization.

Indeed, but why bother unless you have actual measurements that let you quantify the trade-off between the performance increase of removing it and improved problem resolution in the live environment?

You may have bugs, I don't! :-)

On Wed, 18 Dec 2013 23:45:02 +0000, mm0fmf declaimed the following:

It's an undocumented feature...

In exams they do and for documentation, but most coders and the like especially studenst are lazy with that and want to play with code, not writiung things down.

It is not the tools but the tool using them no matter what training.

that!)

I don't propose to make tools slower, maybe a bit more difficult to use yes. What I don't like is singlestepping etc. That encourages fixing boundary errors by just adding a check or an offset, and also makes developers believe that they can get a correct algorithm by just trying test cases until it looks ok.

The 'IPCC' approach to coding... ..I'll get my coat..

Many thanks for that, Gregor. I'll have a play. I did see that

Why not insist on them writing proper test cases before writing or compiling any code. 'Proper' involves specifying both inputs and outputs (if trextual output, to the letter) and including corner cases and erroneous inputs as well as straight forward clean path tests.

I routinely do that for my own code: write a test harness and scripts for it. These scripts include expected results either as comments or as expected results fields which the test harness checks.

Either thats pure bullshit or you don't test your code properly.