[Bug ld/5652] genscripts.sh fails with BASH_LINENO
--- Additional Comments From vincent dot riviere at freesbee dot fr 2008-01-25 22:55 --- Furthermore: - SVR2 (1984): - shell functions (sh) http://www.faqs.org/faqs/unix-faq/faq/part6/ I didn't find any documentation about POSIX. But bash --posix knows about functions. And dash (ash) knows it, too (without the function keyword). I really think this patch is good and harmless. I put the test in a function because the BASH_LINENO (a bash builtin) exists only in functions ! And as the original code uses functions, it doesn't matter to add one more. The original code uses the BASH_LINENO trick in order to produce #line statements about the original em file into the generated C file. If BASH_LINENO is available, the script use it. If not, it does not produce #line. The BASH_LINENO trick is absolutely not mandatory. It just helps to get better error report when there is a compilation problem in the em file. Regards, Vincent -- What|Removed |Added Status|WAITING |NEW http://sourceware.org/bugzilla/show_bug.cgi?id=5652 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5652] genscripts.sh fails with BASH_LINENO
--- Additional Comments From schwab at suse dot de 2008-01-25 20:04 --- http://www.faqs.org/faqs/unix-faq/shell/shell-differences/ sh csh ksh bash tcsh zsh rc es Shell functions Y(1) NYYNYYY 1. This feature was not in the orginal version, but has since become almost standard. -- http://sourceware.org/bugzilla/show_bug.cgi?id=5652 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gprof reporting zero times for one program
Nick Clifton wrote: > > Whereas for the development nettee: > > > Each sample counts as 0.01 seconds. > > no time accumulated > > Hmm, well it appears that there is no profiling information in the gmon.out > file. Have you checked that a gmon.out file is actually being produced ? And > that it is not empty ? gmon.out is created and is not empty. It contains some information as the "called" columns have reasonable values, it is just times that are all zero. > > My first guess as to the cause would be that you are now linking with startup > files which do not enable profiling. I did that for an old version (which will profile) and the new one (which will not) and could not see anything obviously different in the two. Try adding "-v" to the gcc command line > of the old and new nettee builds and see if different startup files are being used. The -v output looks the same, except for the lines in the new one which result from the compile of the two new nio.c and rb.c files, that is, the build for the previous one was: gcc -Wall -DNOUSLEEP -D_LARGEFILE64_SOURCE -D_POSIX_SOURCE -v -pg -g -O0 -v -o nettee nettee.c>previous_v.txt 2>&1 and for the current one: gcc -Wall -DNOUSLEEP -D_LARGEFILE64_SOURCE -D_POSIX_SOURCE -v -pg -g -O0 -o nettee nettee.c rb.c nio.c >current_v.txt 2>&1 ldd shows the same entries for both binaries. I wonder if maybe this isn't some issue related to secondary files rb.c and nio.c? I tried export GPROF_PATH=/(the path) gprof -l nettee and while the times were all zero it did have line numbers in rb.c and nio.c. So it found the source files and could read them ok. Here are the first two useful lines of gprof -l which show that it could resolve line numbers in both nettee.c and rb.c, sorry about the wrap: 0.000.007339/7339transmit (nettee.c:1576 @ 804c5c8) [2241] [2] 0.00.000.007339 rb_shadow_set_reconcile (rb.c:427 @ 8052518) [2] The time, self, and children fields are all zero, but the called graph seems about right. > > You might also try using the gcov program as an alternative to gprof (and > --coverage instead of -pg). That ran and provided exactly the same coverage information which was already in gprof, but no times. Maybe I'm missing something but I do not see how to induce gcov to emit execution times per line. gcc -Wall -DNOUSLEEP -D_LARGEFILE64_SOURCE -D_POSIX_SOURCE -coverage -g -O0 -o nettee nettee.c rb.c nio.c (run nettee on a transfer that took 38 seconds) gcov nettee The only change other than the use of multiple files, instead of just one, that I can think of which might be causing this is that the new version of nettee calls alarm(0) and alarm(time) more frequently than did the previous version. If gprof embeds code which uses the same mechanism it might never be seeing its timers going off. Other than that, the rest of the code changes are just that - code changes, there shouldn't be anything in normal logic to confuse gprof. Valgrind runs cleanly so it isn't stomping on memory. Thanks, David Mathog [EMAIL PROTECTED] Manager, Sequence Analysis Facility, Biology Division, Caltech ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5670] linker is broken
--- Additional Comments From hjl dot tools at gmail dot com 2008-01-25 17:35 --- Fixed by http://sourceware.org/ml/binutils/2008-01/msg00278.html -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=5670 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5670] New: linker is broken
This patch: http://sourceware.org/ml/binutils/2008-01/msg00272.html breaks linker. On Linux/Intel64 with gcc 4.1, I got cc1: warnings being treated as errors /export/gnu/src/binutils/binutils/ld/ldlang.c: In function ‘process_insert_statements’: /export/gnu/src/binutils/binutils/ld/ldlang.c:3398: warning: dereferencing type-punned pointer will break strict-aliasing rules /export/gnu/src/binutils/binutils/ld/ldlang.c:3405: warning: dereferencing type-punned pointer will break strict-aliasing rules make[4]: *** [ldlang.o] Error 1 -- Summary: linker is broken Product: binutils Version: 2.19 (HEAD) Status: NEW Severity: critical Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: hjl dot tools at gmail dot com CC: amodra at bigpond dot net dot au,bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=5670 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5652] genscripts.sh fails with BASH_LINENO
--- Additional Comments From nickc at redhat dot com 2008-01-25 16:56 --- Hi Vincent, Thanks for reporting this problem. I am not sure if your proposed patch will work for all versions of /bin/sh however. Correct me if I am wrong, but aren't shell functions a feature of bash rather than all shells ? So wouldn't it be better to just test BASH_LINENO directly ? eg: if test $BASH_LINENO" != "x"; then source_em() Cheers Nick -- What|Removed |Added Status|NEW |WAITING http://sourceware.org/bugzilla/show_bug.cgi?id=5652 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gprof reporting zero times for one program
Hi David, I'm having issues with gprof reporting empty times on the development version of my network program nettee. binutils-2.17.50.0.9-1mdv2007.1 For the record there is a 2.18 release out now, although I doubt if this will have any effect on the problem you are seeing. Whereas for the development nettee: Each sample counts as 0.01 seconds. no time accumulated Hmm, well it appears that there is no profiling information in the gmon.out file. Have you checked that a gmon.out file is actually being produced ? And that it is not empty ? My first guess as to the cause would be that you are now linking with startup files which do not enable profiling. Try adding "-v" to the gcc command line of the old and new nettee builds and see if different startup files are being used. You might also try using the gcov program as an alternative to gprof (and --coverage instead of -pg). Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
