RTEMS tool-chain | nm | strange behavior
Joel Sherrill
joel.sherrill at OARcorp.com
Thu Feb 16 20:07:29 UTC 2012
If you can produce a small test case, then I can pass it along to the
binutils group to track .
Does this happen on GNU/Linux? That would help get attention :)
--joel
On 02/16/2012 01:09 PM, Wendell Silva wrote:
> On more thing: sparc-rtems4.10-nm does not exhibit incorrect behavior.
> So, chances are that the bug is limited to i386-rtems tool-chain.
>
> --
> Wendell.
>
> 2012/2/16 Wendell Silva <silvawp at gmail.com <mailto:silvawp at gmail.com>>
>
> 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
>
>
>
>
> --
> Att.
> Wendell P. Silva
> +55 12 8114-8018
>
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20120216/0346680c/attachment-0001.html>
More information about the users
mailing list