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.html>


More information about the users mailing list