* [ECOS] waitpid and alarm? @ 2001-01-16 5:51 Colin Ford 2001-01-16 6:36 ` Bart Veer 0 siblings, 1 reply; 7+ messages in thread From: Colin Ford @ 2001-01-16 5:51 UTC (permalink / raw) To: ecos-discuss Hello, I've seen this really strange problem. I'm compiling on Linux using a gcc mips cross compiler for my R3000 target. I've got the latest cvs version of eCos and the network and snmp modules. In the module net/snmp/agent/current/src/mibgroup/util_funcs.c the functions 'waitpid' and 'alarm' are used within the functions wait_on_exec and restart_hook. Now these two functions are not used but are defined at global scope. This means that they end up in the libtarget.a with the functions 'waitpid' and 'alarm' undefined. Thats all well and good and everything compiled. I then noticed that in my compile line I had -ffunction-sections and -fdata-sections so I took thoes out as they interfered with gdb and tried then to re-compile. Could I get it to compiler after that? not a chance! It seemed to think in the link that waitpid and alarm where undefined. Only putting -ffunction-section back in aliviated the problem? To get around the problem I #if them out and took out the -ffunction-section. That then allowed me to compile again. I think that maybe these functions need to be hashed out in the cvs code until waitpid and alarm can be supported. Many thanks for allowing me to rant, Col. -- =========================================== Colin Ford PipingHot Networks Software Engineer +44 (0)1364 655510 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] waitpid and alarm? 2001-01-16 5:51 [ECOS] waitpid and alarm? Colin Ford @ 2001-01-16 6:36 ` Bart Veer 2001-01-16 7:38 ` Colin Ford 0 siblings, 1 reply; 7+ messages in thread From: Bart Veer @ 2001-01-16 6:36 UTC (permalink / raw) To: colin.ford; +Cc: ecos-discuss >>>>> "Colin" == Colin Ford <colin.ford@pipinghotnetworks.com> writes: Colin> Hello, Colin> I've seen this really strange problem. I'm compiling on Colin> Linux using a gcc mips cross compiler for my R3000 target. Colin> I've got the latest cvs version of eCos and the network and Colin> snmp modules. Colin> In the module Colin> net/snmp/agent/current/src/mibgroup/util_funcs.c the Colin> functions 'waitpid' and 'alarm' are used within the Colin> functions wait_on_exec and restart_hook. Now these two Colin> functions are not used but are defined at global scope. Colin> This means that they end up in the libtarget.a with the Colin> functions 'waitpid' and 'alarm' undefined. Colin> Thats all well and good and everything compiled. I then Colin> noticed that in my compile line I had -ffunction-sections Colin> and -fdata-sections so I took thoes out as they interfered Colin> with gdb and tried then to re-compile. Colin> Could I get it to compiler after that? not a chance! It Colin> seemed to think in the link that waitpid and alarm where Colin> undefined. Only putting -ffunction-section back in Colin> aliviated the problem? Colin> To get around the problem I #if them out and took out the Colin> -ffunction-section. That then allowed me to compile again. Colin> I think that maybe these functions need to be hashed out in Colin> the cvs code until waitpid and alarm can be supported. Colin> Many thanks for allowing me to rant, The tools are behaving as expected. Without -ffunction-sections and -fdata-sections, linking operates on a per-module basis. If any functions in util_funcs.c are used then all functions in util_funcs.c will end up in the final image, and hence all references must be resolved. With -ffunction-sections linking operates at a finer grain so e.g. wait_on_exec will only end up in the final image if there is an explicit reference to it. The main goal is to keep down the size of the final executable. In general we do assume that people will make use of -ffunction-sections and similar functionality. This allows us to import external code like SNMP with minimal source changes, and when a new version is released it can be imported more easily. I do not know enough about the SNMP code to understand under what circumstances if any wait_on_exec or restart_hook might be useful, but just #ifdef'ing them out may have undesirable side effects and will complicate future maintenance. Obviously waitpid() is not relevant to eCos systems, but I believe that alarm() is already implemented in the EL/IX compatability layer. The real issue here is not the SNMP code but why you are unable to debug reliably when using -ffunction-sections. In theory, as far as debugging is concerned, there should be no real differences between linking on a per-function or a per-module basis. In practice there may well still be bugs in this area that need to be tracked down - although that discussion might be more appropriate for the gdb mailing list. Bart ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] waitpid and alarm? 2001-01-16 6:36 ` Bart Veer @ 2001-01-16 7:38 ` Colin Ford 2001-01-16 7:46 ` Gary Thomas 2001-01-16 8:19 ` Bart Veer 0 siblings, 2 replies; 7+ messages in thread From: Colin Ford @ 2001-01-16 7:38 UTC (permalink / raw) To: bartv; +Cc: ecos-discuss Thanks for the info Bart. The only thing is that I was put off somewhat by the gcc info on the two option -ffunction-sections and -fdata-sections, see the last paragraph below: @item -ffunction-sections @itemx -fdata-sections Place each function or data item into its own section in the output file if the target supports arbitrary sections. The name of the function or the name of the data item determines the section's name in the output file. Use these options on systems where the linker can perform optimizations to improve locality of reference in the instruction space. HPPA processors running HP-UX and Sparc processors running Solaris 2 have linkers with such optimizations. Other systems using the ELF object format as well as AIX may have these optimizations in the future. Only use these options when there are significant benefits from doing so. When you specify these options, the assembler and linker will create larger object and executable files and will also be slower. You will not be able to use @code{gprof} on all systems if you specify this option and you may have problems with debugging if you specify both this option and @samp{-g}. Nice to know what you think of this? Cheers, Col On 16 Jan 2001 14:36:08 +0000, Bart Veer wrote: > >>>>> "Colin" == Colin Ford <colin.ford@pipinghotnetworks.com> writes: > > Colin> Hello, > Colin> I've seen this really strange problem. I'm compiling on > Colin> Linux using a gcc mips cross compiler for my R3000 target. > Colin> I've got the latest cvs version of eCos and the network and > Colin> snmp modules. > > Colin> In the module > Colin> net/snmp/agent/current/src/mibgroup/util_funcs.c the > Colin> functions 'waitpid' and 'alarm' are used within the > Colin> functions wait_on_exec and restart_hook. Now these two > Colin> functions are not used but are defined at global scope. > Colin> This means that they end up in the libtarget.a with the > Colin> functions 'waitpid' and 'alarm' undefined. > > Colin> Thats all well and good and everything compiled. I then > Colin> noticed that in my compile line I had -ffunction-sections > Colin> and -fdata-sections so I took thoes out as they interfered > Colin> with gdb and tried then to re-compile. > > Colin> Could I get it to compiler after that? not a chance! It > Colin> seemed to think in the link that waitpid and alarm where > Colin> undefined. Only putting -ffunction-section back in > Colin> aliviated the problem? > > Colin> To get around the problem I #if them out and took out the > Colin> -ffunction-section. That then allowed me to compile again. > Colin> I think that maybe these functions need to be hashed out in > Colin> the cvs code until waitpid and alarm can be supported. > > Colin> Many thanks for allowing me to rant, > > The tools are behaving as expected. Without -ffunction-sections and > -fdata-sections, linking operates on a per-module basis. If any > functions in util_funcs.c are used then all functions in util_funcs.c > will end up in the final image, and hence all references must be > resolved. With -ffunction-sections linking operates at a finer grain > so e.g. wait_on_exec will only end up in the final image if there is > an explicit reference to it. The main goal is to keep down the size of > the final executable. > > In general we do assume that people will make use of > -ffunction-sections and similar functionality. This allows us to > import external code like SNMP with minimal source changes, and when a > new version is released it can be imported more easily. I do not know > enough about the SNMP code to understand under what circumstances > if any wait_on_exec or restart_hook might be useful, but just > #ifdef'ing them out may have undesirable side effects and will > complicate future maintenance. Obviously waitpid() is not relevant to > eCos systems, but I believe that alarm() is already implemented in the > EL/IX compatability layer. > > The real issue here is not the SNMP code but why you are unable to > debug reliably when using -ffunction-sections. In theory, as far as > debugging is concerned, there should be no real differences between > linking on a per-function or a per-module basis. In practice there may > well still be bugs in this area that need to be tracked down - > although that discussion might be more appropriate for the gdb mailing > list. > > Bart -- =========================================== Colin Ford PipingHot Networks Software Engineer +44 (0)1364 655510 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] waitpid and alarm? 2001-01-16 7:38 ` Colin Ford @ 2001-01-16 7:46 ` Gary Thomas 2001-01-16 9:52 ` Jonathan Larmour 2001-01-16 8:19 ` Bart Veer 1 sibling, 1 reply; 7+ messages in thread From: Gary Thomas @ 2001-01-16 7:46 UTC (permalink / raw) To: Colin Ford; +Cc: ecos-discuss, bartv On 16-Jan-2001 Colin Ford wrote: > Thanks for the info Bart. The only thing is that I was put off somewhat > by the gcc info on the two option -ffunction-sections and > -fdata-sections, > see the last paragraph below: > > @item -ffunction-sections > @itemx -fdata-sections > Place each function or data item into its own section in the output > file if the target supports arbitrary sections. The name of the > function or the name of the data item determines the section's name > in the output file. > > Use these options on systems where the linker can perform optimizations > to improve locality of reference in the instruction space. HPPA > processors running HP-UX and Sparc processors running Solaris 2 have > linkers with such optimizations. Other systems using the ELF object format > as well as AIX may have these optimizations in the future. > > Only use these options when there are significant benefits from doing > so. When you specify these options, the assembler and linker will > create larger object and executable files and will also be slower. > You will not be able to use @code{gprof} on all systems if you > specify this option and you may have problems with debugging if > you specify both this option and @samp{-g}. > > > Nice to know what you think of this? > Hogwash? Honestly, the text is probably quite old and certainly does not reflect our experience in using these options with eCos. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] waitpid and alarm? 2001-01-16 7:46 ` Gary Thomas @ 2001-01-16 9:52 ` Jonathan Larmour 2001-01-17 5:33 ` Colin Spier 0 siblings, 1 reply; 7+ messages in thread From: Jonathan Larmour @ 2001-01-16 9:52 UTC (permalink / raw) To: Gary Thomas; +Cc: Colin Ford, ecos-discuss, bartv Gary Thomas wrote: > > On 16-Jan-2001 Colin Ford wrote: > > Thanks for the info Bart. The only thing is that I was put off somewhat > > by the gcc info on the two option -ffunction-sections and > > -fdata-sections, > > see the last paragraph below: > > > > @item -ffunction-sections > > @itemx -fdata-sections > > Place each function or data item into its own section in the output > > file if the target supports arbitrary sections. The name of the > > function or the name of the data item determines the section's name > > in the output file. > > > > Use these options on systems where the linker can perform optimizations > > to improve locality of reference in the instruction space. HPPA > > processors running HP-UX and Sparc processors running Solaris 2 have > > linkers with such optimizations. Other systems using the ELF object format > > as well as AIX may have these optimizations in the future. > > > > Only use these options when there are significant benefits from doing > > so. When you specify these options, the assembler and linker will > > create larger object and executable files and will also be slower. > > You will not be able to use @code{gprof} on all systems if you > > specify this option and you may have problems with debugging if > > you specify both this option and @samp{-g}. > > > > > > Nice to know what you think of this? > > > > Hogwash? > > Honestly, the text is probably quite old and certainly does not reflect > our experience in using these options with eCos. Actually it is correct that the assembler/linker will create larger object files, but this is purely the files themselves, not the size of your program as loaded onto the target. To be honest, the size increase is minimal anyway - I'm surprised it's worth mentioning. We don't support gprof anyway, and we have had very very occasional problems with debugging, when using stabs debugging formats. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [ECOS] waitpid and alarm? 2001-01-16 9:52 ` Jonathan Larmour @ 2001-01-17 5:33 ` Colin Spier 0 siblings, 0 replies; 7+ messages in thread From: Colin Spier @ 2001-01-17 5:33 UTC (permalink / raw) To: Jonathan Larmour; +Cc: Colin Ford, Gary Thomas, ecos-discuss, bartv Well, we definitely have _significant_ problems debugging if we compile with -ffunction-sections -fdata-sections and link with -Wl,--gc-sections. If I build with the above directives, run the system and force a <CTRLC> breakpoint, when I connect gdb it suggests that the code has stopped at "0x80034d98 <_breakinst+4>: move $sp,$s8" and only displays assembly code, no source. Also, 'info address main' says that 'Symbol "main" is a function at address 0x0'. I can set breakpoints in code, but they do not cause the system to break... However, if I build without the above directives, run the system and force a <CTRLC> breakpoint, when I connect gdb it correctly shows the source code for breakpoint() (i.e. the correct source code for where the system was stopped), and 'info address main' says that the address is 0x80089274. I can set breakpoints in my code and they work! Our tool chain is gcc 2.95.2, binutils 2.10.1, insight 5.0 (I've also tried insight+dejagnu-weekly-20001124 and insight+dejagnu-weekly-20010116). My conclusion, therefore, is that although the gcc info file may indeed be hogwash, I'm inclined to believe the bit about having problems debugging ;) -- Colin Spier PipingHot Networks Ltd. Office: +44 (0)1364 655500 DDI: +44 (0)1364 655521 Fax: +44 (0)1364 654625 mailto:colin.spier@pipinghotnetworks.com http://www.pipinghotnetworks.com > -----Original Message----- > From: Jonathan Larmour [ mailto:jlarmour@redhat.com ] > Sent: 16 January 2001 17:52 > To: Gary Thomas > Cc: Colin Ford; ecos-discuss@sources.redhat.com; bartv@redhat.com > Subject: Re: [ECOS] waitpid and alarm? > > > Gary Thomas wrote: > > > > On 16-Jan-2001 Colin Ford wrote: > > > Thanks for the info Bart. The only thing is that I was put > off somewhat > > > by the gcc info on the two option -ffunction-sections and > > > -fdata-sections, > > > see the last paragraph below: > > > > > > @item -ffunction-sections > > > @itemx -fdata-sections > > > Place each function or data item into its own section in the output > > > file if the target supports arbitrary sections. The name of the > > > function or the name of the data item determines the section's name > > > in the output file. > > > > > > Use these options on systems where the linker can perform > optimizations > > > to improve locality of reference in the instruction space. HPPA > > > processors running HP-UX and Sparc processors running Solaris 2 have > > > linkers with such optimizations. Other systems using the ELF > object format > > > as well as AIX may have these optimizations in the future. > > > > > > Only use these options when there are significant benefits from doing > > > so. When you specify these options, the assembler and linker will > > > create larger object and executable files and will also be slower. > > > You will not be able to use @code{gprof} on all systems if you > > > specify this option and you may have problems with debugging if > > > you specify both this option and @samp{-g}. > > > > > > > > > Nice to know what you think of this? > > > > > > > Hogwash? > > > > Honestly, the text is probably quite old and certainly does not reflect > > our experience in using these options with eCos. > > Actually it is correct that the assembler/linker will create larger object > files, but this is purely the files themselves, not the size of your > program as loaded onto the target. To be honest, the size increase is > minimal anyway - I'm surprised it's worth mentioning. > > We don't support gprof anyway, and we have had very very occasional > problems with debugging, when using stabs debugging formats. > > Jifl > -- > Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 > Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] waitpid and alarm? 2001-01-16 7:38 ` Colin Ford 2001-01-16 7:46 ` Gary Thomas @ 2001-01-16 8:19 ` Bart Veer 1 sibling, 0 replies; 7+ messages in thread From: Bart Veer @ 2001-01-16 8:19 UTC (permalink / raw) To: colin.ford; +Cc: ecos-discuss >>>>> "Colin" == Colin Ford <colin.ford@pipinghotnetworks.com> writes: Colin> Thanks for the info Bart. The only thing is that I was put off somewhat Colin> by the gcc info on the two option -ffunction-sections and Colin> -fdata-sections, Colin> see the last paragraph below: Colin> @item -ffunction-sections Colin> @itemx -fdata-sections Colin> Place each function or data item into its own section in Colin> the output file if the target supports arbitrary sections. Colin> The name of the function or the name of the data item Colin> determines the section's name in the output file. This paragraph is correct - bearing in mind that eCos depends on toolchains which support arbitrary sections. Colin> Use these options on systems where the linker can perform Colin> optimizations to improve locality of reference in the Colin> instruction space. HPPA processors running HP-UX and Sparc Colin> processors running Solaris 2 have linkers with such Colin> optimizations. Other systems using the ELF object format as Colin> well as AIX may have these optimizations in the future. Correct to some extent: -ffunction-sections does allow linkers to group related functions together. However as far as we are concerned the main use is with the linker's --gc-sections option. This paragraph really refers to native development rather than embedded systems. Colin> Only use these options when there are significant benefits Colin> from doing so. In the eCos context and when linking with --gc-sections, there are significant benefits. Colin> When you specify these options, the assembler and linker Colin> will create larger object and executable files and will Colin> also be slower. Only if the linker does not support --gc-sections. Colin> You will not be able to use @code{gprof} on all systems if Colin> you specify this option This may be true, but currently we have no profiling support in eCos so the issue has not been addressed. Colin> and you may have problems with debugging if you specify Colin> both this option and @samp{-g}. This is software. There will be bugs. There may be bugs in the compiler, linker, or gdb which only show up when using -ffunction-sections. If there are such bugs then you may have problems. So strictly speaking the statement is correct, but you can say the same thing about all software. There may well be problems when using debuggers other than gdb, for example those debuggers might get confused by the large number of sections. eCos users should not be affected. Bart ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2001-01-17 5:33 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-01-16 5:51 [ECOS] waitpid and alarm? Colin Ford 2001-01-16 6:36 ` Bart Veer 2001-01-16 7:38 ` Colin Ford 2001-01-16 7:46 ` Gary Thomas 2001-01-16 9:52 ` Jonathan Larmour 2001-01-17 5:33 ` Colin Spier 2001-01-16 8:19 ` Bart Veer
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).