* [ECOS] RE: eCos Loader [not found] <20050426204513.30E1BE5BC7@ws7-2.us4.outblaze.com> @ 2005-04-27 0:21 ` David Bonfrer 2005-04-27 0:33 ` [ECOS] i386 problem Gonçalo Antunes ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: David Bonfrer @ 2005-04-27 0:21 UTC (permalink / raw) To: 'Anthony Tonizzo', ecos-discuss Hi, I'm using ELF executable and shared libs. I know that *diag_printf points to the function diag_printf. The question is: How do I get this in general? I don't want to fill my own tables with: If ("printf"){location = *printf} If ("scanf") {location = *scanf} Etc. Can I get a symbol table from eCos for these functionsymbols? Thanks. P.S. Anthony, I am in a starting stage for this loader. I'm not ready to put it here because it's not finished and it's not very readable source code yet. -----Original Message----- From: Anthony Tonizzo [mailto:atonizzo@lycos.com] Sent: dinsdag 26 april 2005 22:45 To: ecos@bonfrer.com Subject: eCos Loader Hi: I am working on an ecos loader too. Following some conversations with Nick Garnett on the subject, I wanted to create an interface that was more similar to Linux insmod() that to a shared library. In this case, your module gets compiled with a simple gcc -c hello.c and then the loader must act as linker, and resolve relocation and references. I am still involved in the project, but I disagree with DeRocco: Inventing your own linker format is a bad idea. Because you now have to use special linkers to compile your module, or worse you have to write one. eCos libraries are ELF modules, and so should the libraries. As far as resolving external symbols, the only valid approach is a table of this type: struct { char* symbol_name; void (*fp)(void); } symbol; symbol symbol_table[] = { { "diag_printf", diag_printf }, ... which you can then fill up with the values of the functions you need. Since this table would be in memory all the time, you can selectively eliminate the functions you do not need via a CDL option or some other form of compile time option (for example, you only have pointers for kernel and semaphores, and nothing else). This should help in getting a handle on an otherwise huge table. In my application, I do not need to call external functions, but I definitely need relocation and symbol resolution. How far away is your code from prime time? Can I take a look at it to see if I can use it (and act as a beta tester in the process)? I am sorry if I replied to you personally, but the ecoscentric reflector does not seem to like my posting when I am behind my company's firewall. Regards Tony -- _______________________________________________ NEW! Lycos Dating Search. The only place to search multiple dating sites at once. http://datingsearch.lycos.com -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.10.3 - Release Date: 25-4-2005 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] i386 problem 2005-04-27 0:21 ` [ECOS] RE: eCos Loader David Bonfrer @ 2005-04-27 0:33 ` Gonçalo Antunes 2005-04-27 6:05 ` Andrew Lunn 2005-04-27 8:25 ` [ECOS] RE: eCos Loader Andrew Lunn 2005-04-27 10:28 ` Nick Garnett 2 siblings, 1 reply; 16+ messages in thread From: Gonçalo Antunes @ 2005-04-27 0:33 UTC (permalink / raw) To: ecos-discuss Hi I started my config.ecc with the i386realtek template. added the HTTP, CPuload, FreeBSD, networking, and common ethernet packages.. and when I do the 'make tests" I get an error... I'm using the startup method 'FLOPPY' and I get the following error: /home/gmma/config_install/lib/vectors.o:/tmp/ccfRQjJM.s: undefined reference to 'hal_saved_interrupt_state' make: leaving directory '/home/gmma/config_build' collect2: ld returned 1 exit status if I change the startup method to RAM, the error does not appear... I really need to have it running from the FLOPPY... Can you help? Thank you very much. Gonçalo Antunes. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] i386 problem 2005-04-27 0:33 ` [ECOS] i386 problem Gonçalo Antunes @ 2005-04-27 6:05 ` Andrew Lunn 2005-04-30 9:57 ` Gonçalo Antunes 0 siblings, 1 reply; 16+ messages in thread From: Andrew Lunn @ 2005-04-27 6:05 UTC (permalink / raw) To: Gon?alo Antunes; +Cc: ecos-discuss On Wed, Apr 27, 2005 at 01:20:52AM +0100, Gon?alo Antunes wrote: > Hi > > I started my config.ecc with the i386realtek template. > added the HTTP, CPuload, FreeBSD, networking, and common ethernet packages.. Use the net template as a basis and then add http and cpuload. This might help, but it might not. > and when I do the 'make tests" I get an error... > > I'm using the startup method 'FLOPPY' and I get the following error: > > /home/gmma/config_install/lib/vectors.o:/tmp/ccfRQjJM.s: undefined reference > to 'hal_saved_interrupt_state' > make: leaving directory '/home/gmma/config_build' > collect2: ld returned 1 exit status > > if I change the startup method to RAM, the error does not appear... > I really need to have it running from the FLOPPY... What have you found out while debugging the problem? Its been a few days since you posted this the first time so you have had time to do lots of testing.... Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] i386 problem 2005-04-27 6:05 ` Andrew Lunn @ 2005-04-30 9:57 ` Gonçalo Antunes [not found] ` <20050430171810.GA6601@lunn.ch> 2005-05-03 10:14 ` Nick Garnett 0 siblings, 2 replies; 16+ messages in thread From: Gonçalo Antunes @ 2005-04-30 9:57 UTC (permalink / raw) To: ecos-discuss Hello again! I tried to start with a plain net template, changed the HAL_STARTUP to FLOPPY and the error on the "make tests" is the same: >>/home/gmma/config_install/lib/vectors.o:/tmp/ccfRQjJM.s: undefined >>reference >> to 'hal_saved_interrupt_state' >> make: leaving directory '/home/gmma/config_build' >> collect2: ld returned 1 exit status If I put it to RAM, it works fine... When I first installed ecos (without any CVS update), the FLOPPY startup worked fine... What can I do? Thank You very much. ----- Original Message ----- From: "Andrew Lunn" <andrew@lunn.ch> To: "Gon?alo Antunes" <gmma@gmma.net> Cc: <ecos-discuss@sources.redhat.com> Sent: Wednesday, April 27, 2005 6:34 AM Subject: Re: [ECOS] i386 problem > On Wed, Apr 27, 2005 at 01:20:52AM +0100, Gon?alo Antunes wrote: >> Hi >> >> I started my config.ecc with the i386realtek template. >> added the HTTP, CPuload, FreeBSD, networking, and common ethernet >> packages.. > > Use the net template as a basis and then add http and cpuload. > > This might help, but it might not. > >> and when I do the 'make tests" I get an error... >> >> I'm using the startup method 'FLOPPY' and I get the following error: >> >> /home/gmma/config_install/lib/vectors.o:/tmp/ccfRQjJM.s: undefined >> reference >> to 'hal_saved_interrupt_state' >> make: leaving directory '/home/gmma/config_build' >> collect2: ld returned 1 exit status >> >> if I change the startup method to RAM, the error does not appear... >> I really need to have it running from the FLOPPY... > > What have you found out while debugging the problem? Its been a few > days since you posted this the first time so you have had time to do > lots of testing.... > > Andrew > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <20050430171810.GA6601@lunn.ch>]
* Re: [ECOS] i386 problem [not found] ` <20050430171810.GA6601@lunn.ch> @ 2005-05-02 16:12 ` Gonçalo Antunes 2005-05-02 16:30 ` Andrew Lunn 0 siblings, 1 reply; 16+ messages in thread From: Gonçalo Antunes @ 2005-05-02 16:12 UTC (permalink / raw) To: ecos-discuss Hello. I installed eCos again, updated the repository and built some tests again... The problem is really, as Andrew Lunn said, when linking with the pci tests. Everything is alright when HAL_STARTUP is not the Floppy... Is there a way to have a .ecc file with network support and http to run from a floppy? what are the packages needed to do this? How can I check the image size so I can fit it to a floppy? Thank you. Gonçalo Antunes. ----- Original Message ----- From: "Andrew Lunn" <andrew@lunn.ch> To: "Gon?alo Antunes" <gmma@gmma.net> Cc: <ecos-discuss@sources.redhat.com> Sent: Saturday, April 30, 2005 6:18 PM Subject: Re: [ECOS] i386 problem > On Sat, Apr 30, 2005 at 04:32:27AM +0100, Gon?alo Antunes wrote: >> Hello again! >> >> I tried to start with a plain net template, changed the HAL_STARTUP to >> FLOPPY and the error on the "make tests" is the same: >> >> >>/home/gmma/config_install/lib/vectors.o:/tmp/ccfRQjJM.s: undefined >> >>reference >> >>to 'hal_saved_interrupt_state' >> >>make: leaving directory '/home/gmma/config_build' >> >>collect2: ld returned 1 exit status > > I tried this myself: > > $ ecosconfig new pc_rltk8139 net > $ emacs ecos.ecc - FLOPPY startup > $ ecosconfig tree > $ make -s > headers finished > build finished > > $ make tests > > this bombs when linking the pci tests becasue the floppy startup has > restribted memory and the image is too big: > > make[1]: Entering directory `/home/lunn/eCos/work/io/pci/current' > i386-elf-gcc -L/home/lunn/eCos/work/install/lib -Ttarget.ld -o > /home/lunn/eCos/work/install/tests/io/pci/current/tests/pci1 > tests/pci1.o -g -nostdlib -Wl,--gc-sections -Wl,-static > /opt/ecos/gnutools/i386-elf/bin/../lib/gcc-lib/i386-elf/3.2.1/../../../../i386-elf/bin/ld: > address 0xbc1f8 of > /home/lunn/eCos/work/install/tests/io/pci/current/tests/pci1 section .bss > is not within region ram > /opt/ecos/gnutools/i386-elf/bin/../lib/gcc-lib/i386-elf/3.2.1/../../../../i386-elf/bin/ld: > address 0xbc1f8 of > /home/lunn/eCos/work/install/tests/io/pci/current/tests/pci1 section .bss > is not within region ram > collect2: ld returned 1 exit status > > However if i do: > > lunn@londo:~/eCos/work$ (cd hal/common/current/ ; make tests) > i386-elf-gcc -c -I/home/lunn/eCos/work/install/include -I/home/lunn/eCos/anoncvs-clean/packages/hal/common/current > -I/home/lunn/eCos/anoncvs-clean/packages/hal/common/current/src -I/home/lunn/eCos/anoncvs-clean/packages/hal/common/current/tests > -I. -I/home/lunn/eCos/anoncvs-clean/packages/hal/common/current/tests/ -finline-limit=7000 > -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-sections > -fdata-sections -fno-exceptions -Wp,-MD,tests/context.tmp -o > tests/context.o > /home/lunn/eCos/anoncvs-clean/packages/hal/common/current/tests/context.c > i386-elf-gcc -L/home/lunn/eCos/work/install/lib -Ttarget.ld -o > /home/lunn/eCos/work/install/tests/hal/common/current/tests/context > tests/context.o -g -nostdlib -Wl,--gc-sections -Wl,-static > i386-elf-gcc -c -I/home/lunn/eCos/work/install/include -I/home/lunn/eCos/anoncvs-clean/packages/hal/common/current > -I/home/lunn/eCos/anoncvs-clean/packages/hal/common/current/src -I/home/lunn/eCos/anoncvs-clean/packages/hal/common/current/tests > -I. -I/home/lunn/eCos/anoncvs-clean/packages/hal/common/current/tests/ -finline-limit=7000 > -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-sections > -fdata-sections -fno-exceptions -Wp,-MD,tests/basic.tmp -o > tests/basic.o > /home/lunn/eCos/anoncvs-clean/packages/hal/common/current/tests/basic.c > i386-elf-gcc -L/home/lunn/eCos/work/install/lib -Ttarget.ld -o > /home/lunn/eCos/work/install/tests/hal/common/current/tests/basic > tests/basic.o -g -nostdlib -Wl,--gc-sections -Wl,-static > i386-elf-gcc -c -I/home/lunn/eCos/work/install/include -I/home/lunn/eCos/anoncvs-clean/packages/hal/common/current > -I/home/lunn/eCos/anoncvs-clean/packages/hal/common/current/src -I/home/lunn/eCos/anoncvs-clean/packages/hal/common/current/tests > -I. -I/home/lunn/eCos/anoncvs-clean/packages/hal/common/current/tests/ -finline-limit=7000 > -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-sections > -fdata-sections -fno-exceptions -Wp,-MD,tests/cache.tmp -o > tests/cache.o > /home/lunn/eCos/anoncvs-clean/packages/hal/common/current/tests/cache.c > i386-elf-gcc -L/home/lunn/eCos/work/install/lib -Ttarget.ld -o > /home/lunn/eCos/work/install/tests/hal/common/current/tests/cache > tests/cache.o -g -nostdlib -Wl,--gc-sections -Wl,-static > > So the hal tests compile fine.... > > Are you realy sure you have the latest code with no local changes? > > Andrew > > > > -- > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] i386 problem 2005-05-02 16:12 ` Gonçalo Antunes @ 2005-05-02 16:30 ` Andrew Lunn 2005-05-02 16:35 ` Gonçalo Antunes 0 siblings, 1 reply; 16+ messages in thread From: Andrew Lunn @ 2005-05-02 16:30 UTC (permalink / raw) To: Gon?alo Antunes; +Cc: ecos-discuss On Mon, May 02, 2005 at 05:11:36PM +0100, Gon?alo Antunes wrote: > Hello. > > I installed eCos again, updated the repository and built some tests again... > The problem is really, as Andrew Lunn said, when linking with the pci tests. > Everything is alright when HAL_STARTUP is not the Floppy... > > Is there a way to have a .ecc file with network support and http to run > from a floppy? what are the packages needed to do this? How can I check the > image size so I can fit it to a floppy? The network stack allocates a lot of space for packet buffers. You can control this with CYGPKG_NET_MEM_USAGE. I suggest you try different sizes and see what works. You can also try to use the lwip stack instead of the freebsd stack. lwip is much smaller. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] i386 problem 2005-05-02 16:30 ` Andrew Lunn @ 2005-05-02 16:35 ` Gonçalo Antunes 0 siblings, 0 replies; 16+ messages in thread From: Gonçalo Antunes @ 2005-05-02 16:35 UTC (permalink / raw) To: ecos-discuss Thank you, Mr. Andrew Lunn. I will try to work around what you said. Thanks. I will get here back to you if I have any news. Gonçalo Antunes. ----- Original Message ----- From: "Andrew Lunn" <andrew@lunn.ch> To: "Gon?alo Antunes" <gmma@gmma.net> Cc: <ecos-discuss@sources.redhat.com> Sent: Monday, May 02, 2005 5:29 PM Subject: Re: [ECOS] i386 problem > On Mon, May 02, 2005 at 05:11:36PM +0100, Gon?alo Antunes wrote: >> Hello. >> >> I installed eCos again, updated the repository and built some tests >> again... >> The problem is really, as Andrew Lunn said, when linking with the pci >> tests. >> Everything is alright when HAL_STARTUP is not the Floppy... >> >> Is there a way to have a .ecc file with network support and http to run >> from a floppy? what are the packages needed to do this? How can I check >> the >> image size so I can fit it to a floppy? > > > The network stack allocates a lot of space for packet buffers. You can > control this with CYGPKG_NET_MEM_USAGE. I suggest you try different > sizes and see what works. > > You can also try to use the lwip stack instead of the freebsd > stack. lwip is much smaller. > > Andrew > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] i386 problem 2005-04-30 9:57 ` Gonçalo Antunes [not found] ` <20050430171810.GA6601@lunn.ch> @ 2005-05-03 10:14 ` Nick Garnett 2005-05-03 10:37 ` Gonçalo Antunes 2005-05-03 20:30 ` Bart Veer 1 sibling, 2 replies; 16+ messages in thread From: Nick Garnett @ 2005-05-03 10:14 UTC (permalink / raw) To: Gonçalo Antunes; +Cc: ecos-discuss Gonçalo Antunes <gmma@gmma.net> writes: > Hello again! > > I tried to start with a plain net template, changed the HAL_STARTUP to > FLOPPY and the error on the "make tests" is the same: > > >> /home/gmma/config_install/lib/vectors.o:/tmp/ccfRQjJM.s: undefined > >> reference > >> to 'hal_saved_interrupt_state' > >> make: leaving directory '/home/gmma/config_build' > >> collect2: ld returned 1 exit status > > > If I put it to RAM, it works fine... > > When I first installed ecos (without any CVS update), the FLOPPY > startup worked fine... > > What can I do? The main problem seems to be with the profiling support that Bart added in March. I'll leave him to decide what to do about it in the repository, but in the interim you could try moving the #endif // CYGPKG_PROFILE_GPROF in hal_misc.c to just after the #endif // SMP I've not tried this, so I have no idea whether it will work. However, FLOPPY startup only allows for applications that occupy the lower 640k of RAM. Given all the packages you want to load, you may find this a bit of a squeeze. You would be better off using the GRUB startup type for large stand-alone programs, since these get loaded into RAM above the 1Mb boundary. During development, you should be using RedBoot and load RAM applications. You should only switch to FLOPPY or GRUB startup when you are ready to turn in to a product, not before. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] i386 problem 2005-05-03 10:14 ` Nick Garnett @ 2005-05-03 10:37 ` Gonçalo Antunes 2005-05-03 20:30 ` Bart Veer 1 sibling, 0 replies; 16+ messages in thread From: Gonçalo Antunes @ 2005-05-03 10:37 UTC (permalink / raw) To: Nick Garnett; +Cc: ecos-discuss Thank you, Mr. Nick Garnett. I will try to do what you said. I will now try to start using Redboot during the development. Thank you again. Gonçalo Antunes. ----- Original Message ----- From: "Nick Garnett" <nickg@ecoscentric.com> To: "Gonçalo Antunes" <gmma@gmma.net> Cc: <ecos-discuss@sources.redhat.com> Sent: Tuesday, May 03, 2005 11:14 AM Subject: Re: [ECOS] i386 problem Gonçalo Antunes <gmma@gmma.net> writes: > Hello again! > > I tried to start with a plain net template, changed the HAL_STARTUP to > FLOPPY and the error on the "make tests" is the same: > > >> /home/gmma/config_install/lib/vectors.o:/tmp/ccfRQjJM.s: undefined > >> reference > >> to 'hal_saved_interrupt_state' > >> make: leaving directory '/home/gmma/config_build' > >> collect2: ld returned 1 exit status > > > If I put it to RAM, it works fine... > > When I first installed ecos (without any CVS update), the FLOPPY > startup worked fine... > > What can I do? The main problem seems to be with the profiling support that Bart added in March. I'll leave him to decide what to do about it in the repository, but in the interim you could try moving the #endif // CYGPKG_PROFILE_GPROF in hal_misc.c to just after the #endif // SMP I've not tried this, so I have no idea whether it will work. However, FLOPPY startup only allows for applications that occupy the lower 640k of RAM. Given all the packages you want to load, you may find this a bit of a squeeze. You would be better off using the GRUB startup type for large stand-alone programs, since these get loaded into RAM above the 1Mb boundary. During development, you should be using RedBoot and load RAM applications. You should only switch to FLOPPY or GRUB startup when you are ready to turn in to a product, not before. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] i386 problem 2005-05-03 10:14 ` Nick Garnett 2005-05-03 10:37 ` Gonçalo Antunes @ 2005-05-03 20:30 ` Bart Veer 1 sibling, 0 replies; 16+ messages in thread From: Bart Veer @ 2005-05-03 20:30 UTC (permalink / raw) To: nickg; +Cc: ecos-discuss >>>>> "Nick" == Nick Garnett <nickg@ecoscentric.com> writes: >> I tried to start with a plain net template, changed the HAL_STARTUP to >> FLOPPY and the error on the "make tests" is the same: >> >> >> /home/gmma/config_install/lib/vectors.o:/tmp/ccfRQjJM.s: undefined >> >> reference to 'hal_saved_interrupt_state' Nick> The main problem seems to be with the profiling support that Nick> Bart added in March. I'll leave him to decide what to do Nick> about it in the repository, but in the interim you could try Nick> moving the Nick> #endif // CYGPKG_PROFILE_GPROF Nick> in hal_misc.c to just after the Nick> #endif // SMP Nick> I've not tried this, so I have no idea whether it will work. I don't think that is the problem. The #ifdef GPROF conditional definition of hal_saved_interrupt_state is completely new, previously the i386 arch hal never provided that variable. Instead it will usually come from the common HAL's hal_if.c I just tried a clean build from anoncvs for pc with the net template and startup changed to floppy. Many of the tests build fine, there is no problem with hal_saved_interrupt_state. As expected there are some build failures relating to overflowing the ram region. I suspect the original poster tried his experiment in an existing build tree and things got very confused. Bart -- Bart Veer eCos Configuration Architect http://www.ecoscentric.com/ The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] RE: eCos Loader 2005-04-27 0:21 ` [ECOS] RE: eCos Loader David Bonfrer 2005-04-27 0:33 ` [ECOS] i386 problem Gonçalo Antunes @ 2005-04-27 8:25 ` Andrew Lunn 2005-04-27 10:28 ` Nick Garnett 2 siblings, 0 replies; 16+ messages in thread From: Andrew Lunn @ 2005-04-27 8:25 UTC (permalink / raw) To: David Bonfrer; +Cc: 'Anthony Tonizzo', ecos-discuss On Tue, Apr 26, 2005 at 11:01:07PM +0200, David Bonfrer wrote: > Hi, > > I'm using ELF executable and shared libs. > > I know that *diag_printf points to the function diag_printf. > > The question is: How do I get this in general? > > I don't want to fill my own tables with: > > If ("printf"){location = *printf} > If ("scanf") {location = *scanf} How about arm-elf-nm libtarget.ld | some_script.tcl > linker_table.c gcc linker_table.c Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] RE: eCos Loader 2005-04-27 0:21 ` [ECOS] RE: eCos Loader David Bonfrer 2005-04-27 0:33 ` [ECOS] i386 problem Gonçalo Antunes 2005-04-27 8:25 ` [ECOS] RE: eCos Loader Andrew Lunn @ 2005-04-27 10:28 ` Nick Garnett 2005-04-27 18:06 ` Paul D. DeRocco 2 siblings, 1 reply; 16+ messages in thread From: Nick Garnett @ 2005-04-27 10:28 UTC (permalink / raw) To: David Bonfrer; +Cc: 'Anthony Tonizzo', ecos-discuss "David Bonfrer" <ecos@bonfrer.com> writes: > Hi, > > I'm using ELF executable and shared libs. If you mean proper shared libraries, like on Linux, then I don't think this is a good idea. The support/loader package is the wreckage from my attempts to get this working. The basic problem was that the xxx-elf- toolchains we use for eCos do not all contain the dynamic library support. If we try to use the linux toolchains, which do have this support, we run into problems with calling conventions and code generation issues. We would also have to introduce full support for the GOT and PLT. Essentially, large chunks of all the HALs would have to be rewritten -- something we really don't want to do. Instead, as Tony indicates, I believe the best approach is to implement a .o file loader, similar to the mechanism used in the Linux kernel to load kernel modules. > > I know that *diag_printf points to the function diag_printf. > > The question is: How do I get this in general? > > I don't want to fill my own tables with: > > If ("printf"){location = *printf} > If ("scanf") {location = *scanf} > Etc. Can I get a symbol table from eCos for these functionsymbols? Andrew has indicated a simple mechanism for this. However, doing that would force the whole of the eCos library to be linked into the main application. This would include hundreds of routines that you may not need which would bloat the executable considerably. Instead the approach described by Tony would be more appropriate: the application developer generates a table of just the symbols that he expects his loaded modules to access. This way the main application will be kept small. Also, there will have to be an asymmetry between how functions in the loaded code are accessed from the main application and how main application functions are accessed from the loaded code. When the object file is loaded, it is relocated into its current memory location and its symbol table scanned for external references. These are looked up in the table and the code fixed up appropriately. We cannot do this the other way round, however, since we cannot build the main application with dangling references. So any references from the main application to the loaded code must be done dynamically. Each symbol must be looked up and assigned to a pointer variable. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [ECOS] RE: eCos Loader 2005-04-27 10:28 ` Nick Garnett @ 2005-04-27 18:06 ` Paul D. DeRocco 2005-04-28 10:06 ` Nick Garnett 0 siblings, 1 reply; 16+ messages in thread From: Paul D. DeRocco @ 2005-04-27 18:06 UTC (permalink / raw) To: eCos Discuss > From: Nick Garnett > > Andrew has indicated a simple mechanism for this. However, doing that > would force the whole of the eCos library to be linked into the main > application. This would include hundreds of routines that you may not > need which would bloat the executable considerably. > > Instead the approach described by Tony would be more appropriate: the > application developer generates a table of just the symbols that he > expects his loaded modules to access. This way the main application > will be kept small. This is an intrinsic problem with a loader: you have to create an OS that has an API suitable for loaded applications that haven't yet been written. In general, the most useful OS image would include symbol table entries for all documented functions in the included eCos subsystems. Otherwise you have to arbitrarily constrain the writers of loaded applications, and document those constraints. Yes, this means that the linked portion of the system may be larger than necessary for a particular app, but that's the only way to decouple the design of the OS from the design of the app. > Also, there will have to be an asymmetry between how functions in the > loaded code are accessed from the main application and how main > application functions are accessed from the loaded code. > > When the object file is loaded, it is relocated into its current > memory location and its symbol table scanned for external > references. These are looked up in the table and the code fixed up > appropriately. > > We cannot do this the other way round, however, since we cannot build > the main application with dangling references. So any references from > the main application to the loaded code must be done dynamically. Each > symbol must be looked up and assigned to a pointer variable. Typically, the only reference _into_ a loaded module is the start address. That is, the code is loaded, and a thread is started (or a function is called) at the module's start address. -- Ciao, Paul D. DeRocco Paul mailto:pderocco@ix.netcom.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] RE: eCos Loader 2005-04-27 18:06 ` Paul D. DeRocco @ 2005-04-28 10:06 ` Nick Garnett 0 siblings, 0 replies; 16+ messages in thread From: Nick Garnett @ 2005-04-28 10:06 UTC (permalink / raw) To: Paul D. DeRocco; +Cc: eCos Discuss "Paul D. DeRocco" <pderocco@ix.netcom.com> writes: > > > > Instead the approach described by Tony would be more appropriate: the > > application developer generates a table of just the symbols that he > > expects his loaded modules to access. This way the main application > > will be kept small. > > This is an intrinsic problem with a loader: you have to create an OS that > has an API suitable for loaded applications that haven't yet been written. > In general, the most useful OS image would include symbol table entries for > all documented functions in the included eCos subsystems. Otherwise you have > to arbitrarily constrain the writers of loaded applications, and document > those constraints. Yes, this means that the linked portion of the system may > be larger than necessary for a particular app, but that's the only way to > decouple the design of the OS from the design of the app. The things being loaded will be application specific: device drivers, video/audio codecs, protocol handlers, libraries etc. You just need to define the API that they will use and build a symbol table to match. There's no need to add stuff that they won't be calling. > Typically, the only reference _into_ a loaded module is the start address. > That is, the code is loaded, and a thread is started (or a function is > called) at the module's start address. That may be true in Linux, where the init routine then registers the module into the OS data structures with function tables and the like. This will also be the way that things like device drivers and codec will work too. However, a more general library may have a variety of interface calls. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] i386 problem @ 2002-05-02 9:04 Roland Caßebohm 2002-05-14 14:22 ` Jonathan Larmour 0 siblings, 1 reply; 16+ messages in thread From: Roland Caßebohm @ 2002-05-02 9:04 UTC (permalink / raw) To: ecos-discuss Hi, I tried till long ago running an eCos application on the PC target again. Everything was working fine, but the application won't run :-(. - Redboot is starting from floppy. - gdb connects via net and via serial line. - The application is builded for startup type RAM $ ecosconfig new pc $ ecosconfig tree $ make $ cd ex $ i386-elf-gcc -c -o hello.o -g -Wall -I../install/include -ffunction-sections -fdata-sections hello.c $ i386-elf-gcc -nostartfiles -L../install/lib -Wl,--gc-sections -o hello hello.o -Ttarget.ld -nostdlib - loading the application works target remote 192.168.1.155:9000 load b main c --> nothing is happen! I have set a breakpoint at "hal_platform_init". I can step till: // ISR table setup: plant the default ISR in all interrupt handlers // and the default interrupt VSR in the equivalent VSR table slots. for (vector = CYGNUM_HAL_ISR_MIN; vector <= CYGNUM_HAL_ISR_MAX; vector++) { cyg_uint32 index; HAL_TRANSLATE_VECTOR( vector, index ); here >> hal_interrupt_handlers[index] = (CYG_ADDRESS) HAL_DEFAULT_ISR; HAL_VSR_SET( vector, &__default_interrupt_vsr, NULL ); } but after vector is 70, the application stops at this line. (the same over serial line) Does anybody know what's going wrong? Roland -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] i386 problem 2002-05-02 9:04 [ECOS] i386 problem Roland Caßebohm @ 2002-05-14 14:22 ` Jonathan Larmour 0 siblings, 0 replies; 16+ messages in thread From: Jonathan Larmour @ 2002-05-14 14:22 UTC (permalink / raw) To: Roland Caßebohm; +Cc: ecos-discuss Roland CaÃebohm wrote: > > Hi, > > I tried till long ago running an eCos application on the PC target again. > Everything was working fine, but the application won't run :-(. > > - Redboot is starting from floppy. > - gdb connects via net and via serial line. > - The application is builded for startup type RAM > > $ ecosconfig new pc > $ ecosconfig tree > $ make > $ cd ex > $ i386-elf-gcc -c -o hello.o -g -Wall -I../install/include > -ffunction-sections -fdata-sections hello.c > $ i386-elf-gcc -nostartfiles -L../install/lib -Wl,--gc-sections -o hello > hello.o -Ttarget.ld -nostdlib > > - loading the application works > target remote 192.168.1.155:9000 > load > b main > c > > --> > > nothing is happen! > > I have set a breakpoint at "hal_platform_init". > I can step till: > > // ISR table setup: plant the default ISR in all interrupt handlers > // and the default interrupt VSR in the equivalent VSR table slots. > for (vector = CYGNUM_HAL_ISR_MIN; vector <= CYGNUM_HAL_ISR_MAX; vector++) > { > cyg_uint32 index; > HAL_TRANSLATE_VECTOR( vector, index ); > here >> hal_interrupt_handlers[index] = (CYG_ADDRESS) HAL_DEFAULT_ISR; > HAL_VSR_SET( vector, &__default_interrupt_vsr, NULL ); > } > > but after vector is 70, the application stops at this line. > > (the same over serial line) > > Does anybody know what's going wrong? Afraid not off-hand, but since interrupts should be disabled at this stage of initialization, these lines shouldn't be problematic. But just supposing interrupts are enabled, then it should be the HAL_VSR_SET that would make it go wrong. Vector 70 should be unused, but perhaps there's something else using it. Perhaps see where it is pointing at before it crashes. And make sure you're using an up-to-date redboot image (e.g. from http://sources.redhat.com/ecos/boards/redbootbins/ ) Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 --[ "You can complain because roses have thorns, or you ]-- --[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2005-05-03 20:30 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20050426204513.30E1BE5BC7@ws7-2.us4.outblaze.com> 2005-04-27 0:21 ` [ECOS] RE: eCos Loader David Bonfrer 2005-04-27 0:33 ` [ECOS] i386 problem Gonçalo Antunes 2005-04-27 6:05 ` Andrew Lunn 2005-04-30 9:57 ` Gonçalo Antunes [not found] ` <20050430171810.GA6601@lunn.ch> 2005-05-02 16:12 ` Gonçalo Antunes 2005-05-02 16:30 ` Andrew Lunn 2005-05-02 16:35 ` Gonçalo Antunes 2005-05-03 10:14 ` Nick Garnett 2005-05-03 10:37 ` Gonçalo Antunes 2005-05-03 20:30 ` Bart Veer 2005-04-27 8:25 ` [ECOS] RE: eCos Loader Andrew Lunn 2005-04-27 10:28 ` Nick Garnett 2005-04-27 18:06 ` Paul D. DeRocco 2005-04-28 10:06 ` Nick Garnett 2002-05-02 9:04 [ECOS] i386 problem Roland Caßebohm 2002-05-14 14:22 ` Jonathan Larmour
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).