[Bug binutils/10199] 'nm' compiled for Linux -> Windows cross compilation silently ignores -S switch

[sergstesh at yahoo dot com]

------- Additional Comments From sergstesh at yahoo dot com  2009-05-29 05:54 
-------
I think you are missing a number of points - look, for example, at the 
following:

"
address@hidden:~/try_ltdl> cat f.c
unsigned lib_function1(double input)
  {
  return (unsigned)input;
  }

inline void end1()
  {
  }
unsigned lib_function2(double input)
  {
  return (unsigned)input;
  }

inline void end2()
  {
  }
address@hidden:~/try_ltdl> ~/mingwi686/bin/i686-mingw32msvc-gcc -c f.c
address@hidden:~/try_ltdl> ~/mingwi686/bin/i686-mingw32msvc-nm f.o
00000000 b .bss
00000000 d .data
00000000 t .text
00000033 T _end1
0000006b T _end2
00000000 T _lib_function1
00000038 T _lib_function2
address@hidden:~/try_ltdl> ~/mingwi686/bin/i686-mingw32msvc-objdump -S f.o

f.o:     file format pe-i386


Disassembly of section .text:

00000000 <_lib_function1>:
   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   83 ec 18                sub    $0x18,%esp
   6:   8b 45 08                mov    0x8(%ebp),%eax
   9:   89 45 f8                mov    %eax,-0x8(%ebp)
   c:   8b 45 0c                mov    0xc(%ebp),%eax
   f:   89 45 fc                mov    %eax,-0x4(%ebp)
  12:   dd 45 f8                fldl   -0x8(%ebp)
  15:   d9 7d f6                fnstcw -0xa(%ebp)
  18:   0f b7 45 f6             movzwl -0xa(%ebp),%eax
  1c:   b4 0c                   mov    $0xc,%ah
  1e:   66 89 45 f4             mov    %ax,-0xc(%ebp)
  22:   d9 6d f4                fldcw  -0xc(%ebp)
  25:   df 7d e8                fistpll -0x18(%ebp)
  28:   d9 6d f6                fldcw  -0xa(%ebp)
  2b:   8b 45 e8                mov    -0x18(%ebp),%eax
  2e:   8b 55 ec                mov    -0x14(%ebp),%edx
  31:   c9                      leave
  32:   c3                      ret

00000033 <_end1>:
  33:   55                      push   %ebp
  34:   89 e5                   mov    %esp,%ebp
  36:   5d                      pop    %ebp
  37:   c3                      ret

00000038 <_lib_function2>:
  38:   55                      push   %ebp
  39:   89 e5                   mov    %esp,%ebp
  3b:   83 ec 18                sub    $0x18,%esp
  3e:   8b 45 08                mov    0x8(%ebp),%eax
  41:   89 45 f8                mov    %eax,-0x8(%ebp)
  44:   8b 45 0c                mov    0xc(%ebp),%eax
  47:   89 45 fc                mov    %eax,-0x4(%ebp)
  4a:   dd 45 f8                fldl   -0x8(%ebp)
  4d:   d9 7d f6                fnstcw -0xa(%ebp)
  50:   0f b7 45 f6             movzwl -0xa(%ebp),%eax
  54:   b4 0c                   mov    $0xc,%ah
  56:   66 89 45 f4             mov    %ax,-0xc(%ebp)
  5a:   d9 6d f4                fldcw  -0xc(%ebp)
  5d:   df 7d e8                fistpll -0x18(%ebp)
  60:   d9 6d f6                fldcw  -0xa(%ebp)
  63:   8b 45 e8                mov    -0x18(%ebp),%eax
  66:   8b 55 ec                mov    -0x14(%ebp),%edx
  69:   c9                      leave
  6a:   c3                      ret

0000006b <_end2>:
  6b:   55                      push   %ebp
  6c:   89 e5                   mov    %esp,%ebp
  6e:   5d                      pop    %ebp
  6f:   c3                      ret
address@hidden:~/try_ltdl>    
"

- both 'nm' and 'objdump' show (relative) addresses of

_lib_function1
_end1
_lib_function2
_end2
.

Each of the above symbols lengths is

next_symbol_address - this_symbol_address

, where next_symbol_address is either true next_symbol_address or the last seen
in disassembly address plus one - the latter is for the last symbol in any 
section.

So, using the above definition I wrote for myself a Perl script (can publish it
here  if you are interested) which calculates symbol lengths according to the
above definition.

I' trying to say that symbol length information is there by definition -
otherwise linker wouldn't be able to correctly work, it will make mistakes and
overlap symbol areas, and the issue is properly extracting it.

I.e. even if certain object file format does not present symbol length info
readily available, it can easily be calculated.

And even if you are not going to implement the functionality, you couldn't have
closed the bug as WHATEVER INVALID - the bug _is_ _valid_ because I as end user
requested an action, and the request has been _silently_ ignored, and the word
"silently" is part of the summary.

I.e. if -S switch exists, and the manual says symbol lengths should be
displayed, then the lengths should either be displayed, or at least a warning
saying something like "symbol lengths for this input format are not supported"
should be issued.

Let me make it even more clear: this is a classical case of advertised behavior
(the manual promising symbol sizes in case of -S) is different from actual
behavior (symbol lengths are _not_ displayed), and thus is a _valid_ bug.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


http://sourceware.org/bugzilla/show_bug.cgi?id=10199

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.