RTEMS tool-chain | nm | strange behavior
Wendell Silva
silvawp at gmail.com
Thu Feb 16 18:33:46 UTC 2012
Hello everybody,
When calling:
i386-rtems-4.10-nm --print-size --numeric-sort --line-numbers
rtems-img.exe > rtems-img.num
the list of symbols in the file rtems-img.num produces valid line numbers
(location of the symbol in the source code) only for those at .text section.
When the symbol is in .data (or .bss) it seems to be printed as it was in
the location of the last symbol in the .text section, instead of the
correct file/line number.
Example of listing:
(... suppressed lines ...)
001283f4 00000109 T lseek
/home/developer/rtems-testing/rtems/build-i386-pc386-rtems/i386-rtems4.10/c/pc386/cpukit/libcsupport/../../../../../../rtems/c/src/../../cpukit/libcsupport/src/lseek.c:28
00128500 00000027 T _lseek_r
/home/developer/rtems-testing/rtems/build-i386-pc386-rtems/i386-rtems4.10/c/pc386/cpukit/libcsupport/../../../../../../rtems/c/src/../../cpukit/libcsupport/src/lseek.c:98
00128528 00000012 T _malloc_r
/home/developer/rtems-testing/rtems/build-i386-pc386-rtems/i386-rtems4.10/c/pc386/cpukit/libcsupport/../../../../../../rtems/c/src/../../cpukit/libcsupport/src/_malloc_r.c:26
0012853c 00000018 T _realloc_r
/home/developer/rtems-testing/rtems/build-i386-pc386-rtems/i386-rtems4.10/c/pc386/cpukit/libcsupport/../../../../../../rtems/c/src/../../cpukit/libcsupport/src/_realloc_r.c:27
00128554 0000001e T _write_r
/home/developer/rtems-testing/rtems/build-i386-pc386-rtems/i386-rtems4.10/c/pc386/cpukit/libcsupport/../../../../../../rtems/c/src/../../cpukit/libcsupport/src/write_r.c:37
00128574 0000000c T isatty
/builddir/build/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.5/build/i386-rtems4.10/newlib/libc/posix/../../../../../gcc-4.4.5/newlib/libc/posix/isatty.c:8
00128580 0000004f T _isatty
/builddir/build/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.5/build/i386-rtems4.10/newlib/libc/posix/../../../../../gcc-4.4.5/newlib/libc/posix/_isatty.c:10
001285d0 t __do_global_ctors_aux
/builddir/build/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.5/build/i386-rtems4.10/newlib/libc/posix/../../../../../gcc-4.4.5/newlib/libc/posix/_isatty.c:21
00128600 T __start_set_sysctl_set
/builddir/build/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.5/build/i386-rtems4.10/newlib/libc/posix/../../../../../gcc-4.4.5/newlib/libc/posix/_isatty.c:21
00128600 A __stop_set_sysctl_set
00128600 T _init
/builddir/build/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.5/build/i386-rtems4.10/newlib/libc/posix/../../../../../gcc-4.4.5/newlib/libc/posix/_isatty.c:21
0012860d T _fini
/builddir/build/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.5/build/i386-rtems4.10/newlib/libc/posix/../../../../../gcc-4.4.5/newlib/libc/posix/_isatty.c:21
(... suppressed lines ...)
00128a04 00000018 R rtems_filesystem_table
/builddir/build/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.5/build/i386-rtems4.10/newlib/libc/posix/../../../../../gcc-4.4.5/newlib/libc/posix/_isatty.c:21
00128a1c 00000010 R configuration_mount_table
/builddir/build/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.5/build/i386-rtems4.10/newlib/libc/posix/../../../../../gcc-4.4.5/newlib/libc/posix/_isatty.c:21
00128a2c 00000004 R rtems_filesystem_mount_table_size
/builddir/build/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.5/build/i386-rtems4.10/newlib/libc/posix/../../../../../gcc-4.4.5/newlib/libc/posix/_isatty.c:21
The last three lines are incorrect.
Look at "rtems_filesystem_table", for instance. It is expected to be
allocated in the source that defines CONFIGURE_INIT, since it is in
confdefs.h, however 'nm' thinks it is in _isatty.c, line 21 (!!!!).
Can anyone confirm this strange behavior?
Versions of nm and gcc I'm using:
i386-rtems4.10-nm --version
GNU nm (GNU Binutils) 2.20.1
Copyright 2009 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later
version.
This program has absolutely no warranty.
i386-rtems4.10-gcc --version
i386-rtems4.10-gcc (GCC) 4.4.5 20101001 (RTEMS
gcc-4.4.5-4.fc14/newlib-1.18.0-19.fc14)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thanks in advance,
--
Att.
Wendell Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20120216/062516f7/attachment.html>
More information about the users
mailing list