Errors when cross-compiling the kernel

actually its more of a boundary problem. The 'bottom boundary' is defined by ether the hardware or the operating system and its libraries and the 'top boundary' is defined by the user or other interface. Those are the bits that HAVE to conform to spec other wise it doesn't work.

Its the middle ware where all the choices are. And the hard work is

longjmp() is not goto, it takes you somewhere old, (not somewhere new) and it's dynamically targeted (not s destination fixed at compile time)

structured programming doesn't work for real life situations unless you can have exception handling, longjmp() is a good way to implement that in C.

and its fearfully efficient. simply load the stack pointer and RET.

If your intention is to carry an error code up through a deep nest of subroutines it achieves that result very efficiently

I know, I was being facetious.

Yes that looks good! It should be possible to integrate that in syslogd or some pre-processor that captures and holds items for later optional release to syslogd.

Unfortunately it makes resource management a mess. It is customary in C to allocate dynamic memory and allocate other resources (like file handles) in functions and release them before return. Using setjump causes memory and descriptor leaks in that case.

In languages like perl, where resources are automatically released when they go out of scope, there is no such concern.

If it does you're doing it wrong. the right way is to use longjmp to intercept the exception and release your resources, or to use stack storage for temporary allocations (alloca()), another option is a one-way ticket out of the application and let the operating-system clean up the hanging resources.

Yes,. I didn't use dynamic allocation in the example given - just stack/static.

You can of course regsister each memory block and its size in a structure, and free them as a linked list.

Agreed at a certain point the complexity of doing that negates the whole purpose of the exercise!

basically making the point it's a tool like any other, and needs to be thought out whatever.

Finally, it's compiled, and I've been able to get the new kernel across the the RPi via its SD card. My notes:

Many thanks for all the help!

I'm glad it works for you. And thanks for documenting everything publicly and thus providing a great resource for others.

gregor

-- Old timers my know about the 70s dual between: European: algol -> Pascal and US: C [actually originated from UK B]

Many C-users said "Oberon [Pascal's descendant] doesn't work", because when they test-compiled the eg. compiler, there was no grinding-wheels-and-smoke. It just wrote . Because it was DONE!

No. Interactive programming is like when you walk into your darkened room and you know how to reach out and toggle the light-switch, for immediate feed-back; vs filling-in-forms to send to HQ. Also the writing-near-english-notes-to-man-in-box, instead of a multi switch point of view, impedes understanding.

This is caused by *evolving* the systems, by just adding layers; instead of re-starting from fundamentals, which IMO are the 'human attributes'. Eg. short term memory limited to 3 items and recognition is cheaper than memory..etc. Therefore menu-based systems are very efficient.

Correct.

===> PS. here's a further example confirming your point of layers-of-office-boys concealing the underlying physical reality:- I want the actual byte-sequence of eg. #1234 -> r0 [loadImediate 1234 into register0] r0 -> memN [store contents of reg0 to memoryN] br Relative:Here [branch to here; to prevent running into next bytes]

Apparently ARM-asm stores the constants at the end of the code-area, for optimisation. So `#1234 -> r0` doesn't exist as a single instruction. I just want the actual byte-strings for a few such pseudo-instructions to be able to debug using only the shell & `dd`.

I refuse to open another canOworms: asm-tool-chain; but googling for ARM+asm+listing, gives me the same old office-boys-filling-out-forms. They don't want to EXPOSE the actual bytes.

Where's the forum for people who came up via hardware, registers, hex-code instead of came down from english-literature to filling-out-forms?

Please do not feed the troll.

Oh, we're here. But some of us have better things to do than be a free keypunch service for someone who refuses to learn anything; I had first boot of my Cortex-M3 port of CP/M-68K this weekend.

We've shown you were to find the documents you need and how to get assembly listings. You'd be better served by cracking the books than whining about how no one will help you muddle through in your quest to remain ignorant.

Hex code? What's wrong with good old Octal?

Indeed. "Dog" or whatever made up nomenclature that poster is currently using doesn't appear the slightest bit interested in learning anything about how the ARM chips work or how to program them.

Instead it seems to be obsessed with with it's own muddled code structure and demanding that people give it details on how to map that to its out-dated 8-bit world of confusion.

I would pity them, but... really "Read the PDF. It gives you everything you need to know in an easy to understand format." isn't that difficult to comprehend, right?

Each bit is laid out and detailed. The Arm has the neatest instruction set of any processor that I have had to work with.

I seriously doubt this "Dog" (or whatever) can comprehend the simplicity of the "one word per instruction" and simplicity of the code.

You had _cards_??

The first machine I tried to program used a flat panel with holes that was programmed with jumper wires. Oh, the machine _read_ cards, and it punched cards, and it printed from cards, but you programmed it with what looked like an oversized prototyping board. See the "Unit record equipment" section of this Wikipedia entry:

Heck, we had to program it walking six miles through the snow... and it was uphill both ways!

( I like today's embedded systems a _lot_ better. )

Frank McKenney

-- A college degree has become the most reliable way to get ahead in life. ... This is partly the result of genuine changes in the economy. ... A lot of it, however, has rather little to do with economic "need". ...there is, in fact precious little evidence that producing more and more graduates does anything for a country's growth rate. It does, however, change the job market.

The more graduates there are, the more employers hire them in preference to non-graduates. ... Many of the jobs now taken by graduates have not changed their skill requirements since the days when they were done perfectly well by high-school graduates who had never gone to college. But now you need a degree to get hired. All of this generates a self-propelling inflation of degree requirements, with more jobs demanding graduates and more people heading into higher education.

-- Alison Wolf / The XX Factor

-- Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 Munged E-mail: frank uscore mckenney aatt mindspring ddoott com

There was no duel. --^- Algol 60 was in widespread use for scientific and engineering by 1967, which was precisely what it was intended for. Along with FORTRAN it had no real concept of strings or string handling apart from the ability to print string literals. Its other disadvantage was that the Algol 60 Report, which specified the language in 1960, didn't say anything about how i/o was to be implemented. Elliott Algol, which was released in 1962 and which I used in 1967 as part of my thesis material, used reserved words with their own statement syntax to implement i/o but almost every other implementation provided an i/o library which was accessed via procedure calls. This was not entirely surprising since its authors thought one of its main uses was in allowing people to describe algorithms to each other without necessarily involving a computer.

Algol 60 was the first major block-structured language, and so is best thought of as the common ancestor of Pascal, Simula, BCPL, B and C.

Pascal, OTOH is largely the result of Nicholas Wirth throwing teddy out of the pram when, at the end of the 1960s, the Algol Committee decided that it preferred Algol-68 to Wirth's Algol-W as the Algol-60 successor.

Pascal was written in 1968/9 and differed quite a lot in that it did specify how i/o was to be carried out and introduced well-thought string handling and records, similar to C's structs. However, there's at least a hint that Wirth thought of it as a teaching language and a means of communicating algorithms between people. I used Algol 68 much more than I did Pascal and am fairly certain that the Pascal language was specified with little or no thought of support for people developing separately compiled procedure libraries (though I could be wrong here), which is quite unlike Algol-68, (or certainly its R version) which made explicit library support a part of the language. Pascal, OTOH, was agnostic: if the compilation system you were using allowed for the creation and linking of procedure libraries then you could use them.

Nope. BCPL was developed in the Cambridge Computer Labs. K&R saw it, and produced a close derivative called B. However, both were quite limited, though block structured, since they only supported a single variable type which could hold either an integer or a character. C was developed from B by adding, among other things, more elementary data types (longs, shorts, floats and doubles as well as composite data types (struct and its extension typedef).

Well, that statement alone makes it quite obvious that you've never written programs of any size or complexity.

Takes flying guess: you're not, by any chance talking about a 1004 are you? I never met one, but a guy I used to work with had cut his programming teeth on one..

I started out using paper tape and a Flexowriter (the Elliott 503 that fed on the tape demanded upper and lower case code, so no teletypes in its kitchen...). I discovered the joys of cards when I got my first job, which was with ICL.

Guenter has been trolling like this for sometime in many newsgroups and forums. A Google search for snipped-for-privacy@gmail.com is most enlightening!

Look at the software he's using to post. That's not something you use if you don't have much clue about computers, processors, software and computer science.

Walks like a troll, talks like a troll, acts like a troll. It's a troll.