|
|
 | | Re: Library use in LegOS
|
| (...) Not sure of the details, but the linker takes the .o file, and the symbol file LegOS.lds, created during the kernel compile, and produces two files; .ds1 & .ds2, which are then passed to makelx to produce the lx file. So it seems the linker (...) (24 years ago, 27-Mar-01, to lugnet.robotics.rcx.legos)
| | | | | Re: .lx format
|
| (...) One other possibility is to not use the lx files at all - just stick to the srec format as (I think) LegOS used to (version 0.1.x?). A bit less efficient downloading the kernel all the time, but removes the need to dabble with lx format at (...) (24 years ago, 27-Mar-01, to lugnet.robotics.rcx.legos)
| | | | | Declarations in header files
|
| Hi! This is very technical, but: does the declaration of an "extern inline const void" function really make sense? GCC accepts it, but that is a VERY lenient compiler. An extern function should be definition not have a definition, and 'const void' (...) (24 years ago, 27-Mar-01, to lugnet.robotics.rcx.legos)
| | | | | Re: .lx format
|
| (...) So in effect, it is dependent on the gcc loader mechanism. Ungh! The idea of using two symbolsrec files: one could be kernel, the other the program. Would make sense for kernel call resolution. (...) I looked at it, and it mainly outputs (...) (24 years ago, 27-Mar-01, to lugnet.robotics.rcx.legos)
| | | | | Re: Library use in LegOS
|
| (...) OK. How are the calls to the kernel resolved? By the makelx program, or by some magical stuff in the linking. I can imagine compiling the kernel, getting a symbol table out, and then when compiling user programs, you use a linker DEFINE or (...) (24 years ago, 27-Mar-01, to lugnet.robotics.rcx.legos)
|
|
