objcopy --extract-symbol option keeping bogus sections/segments : wrong?

objcopy --extract-symbol option keeping bogus sections/segments : wrong?

[Vincent Rubiolo]

[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]

Hi gentle binutils maintainers,

I am writing to you about the newly added --extract-symbol of objcopy 
(cf [1]) which, as Richard explained, we use to extract symbol files 
from VxWorks kernels.

My concern is about the fact that the option zeroes out the 
addresses/sizes, etc of the sections and segments in the file _instead_ 
of only keeping the relevant bits in. In some circumstances, this 
confuses our kernel loader (which is used to load that stripped file) 
since the segments within the file are marked as loadable but are of 
empty size/address.

I have looked at the ELF spec [2] and while the standard says the image 
can have supplementary segments/sections, it does not specify whether 
they can be empty/marked PT_LOAD.

To me, there is no reason to have these bogus sections/segments in the 
image and they should be removed. I think we should fix the file and not 
the loader itself.

Is this a correct reasoning?

Thanks for your insight.

Vincent

PS: attaching readelf output on VxWorks symbol files

[1] http://sourceware.org/ml/binutils/2007-03/msg00004.html
[2] http://www.sco.com/developers/gabi/latest/contents.html



[-- Attachment #2: readelf_output --]
[-- Type: text/plain, Size: 2239 bytes --]

There are 18 section headers, starting at offset 0x20b0:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 000080 000000 00 WAX  0   0 16
  [ 2] .sdata2           PROGBITS        00000000 000080 000000 00  AX  0   0  1
  [ 3] .data             PROGBITS        00000000 002000 000000 00  WA  0   0 8192
  [ 4] .tls_data         PROGBITS        00000000 002000 000000 00  WA  0   0  1
  [ 5] .tls_vars         PROGBITS        00000000 002000 000000 00  WA  0   0  1
  [ 6] .sdata            PROGBITS        00000000 002000 000000 00  WA  0   0  1
  [ 7] .sbss             NOBITS          00000000 002000 000000 00  WA  0   0  1
  [ 8] .bss              NOBITS          00000000 002000 000000 00  WA  0   0  8
  [ 9] .debug_global_abb PROGBITS        00000000 002000 000000 00      0   0  1
  [10] .debug_global_inf PROGBITS        00000000 002000 000000 00      0   0  1
  [11] .debug_frame      PROGBITS        00000000 002000 000000 00      0   0  1
  [12] .debug_line       PROGBITS        00000000 002000 000000 00      0   0  1
  [13] .debug_abbrev     PROGBITS        00000000 002000 000000 00      0   0  1
  [14] .debug_info       PROGBITS        00000000 002000 000000 00      0   0  1
  [15] .shstrtab         STRTAB          00000000 002000 0000b0 00      0   0  1
  [16] .symtab           SYMTAB          00000000 002380 022ea0 10     17 3702  4
  [17] .strtab           STRTAB          00000000 025220 02386e 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Elf file type is EXEC (Executable file)
Entry point 0x0
There are 2 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000080 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10
  LOAD           0x002000 0x00000000 0x00000000 0x00000 0x00000 RW  0x2000

 Section to Segment mapping:
  Segment Sections...
   00     
   01     

objcopy --extract-symbol option keeping bogus sections/segments : wrong?

[Vincent Rubiolo]

Hello again,

I am pinging again since my message might have been overlooked.

Thanks for your suggestions,

Vincent

Vincent Rubiolo wrote:
> Hi gentle binutils maintainers,
> 
> I am writing to you about the newly added --extract-symbol of objcopy 
> (cf [1]) which, as Richard explained, we use to extract symbol files 
> from VxWorks kernels.
> 
> My concern is about the fact that the option zeroes out the 
> addresses/sizes, etc of the sections and segments in the file _instead_ 
> of only keeping the relevant bits in. In some circumstances, this 
> confuses our kernel loader (which is used to load that stripped file) 
> since the segments within the file are marked as loadable but are of 
> empty size/address.
> 
> I have looked at the ELF spec [2] and while the standard says the image 
> can have supplementary segments/sections, it does not specify whether 
> they can be empty/marked PT_LOAD.
> 
> To me, there is no reason to have these bogus sections/segments in the 
> image and they should be removed. I think we should fix the file and not 
> the loader itself.
> 
> Is this a correct reasoning?
> 
> Thanks for your insight.
> 
> Vincent
> 
> PS: attaching readelf output on VxWorks symbol files
> 
> [1] http://sourceware.org/ml/binutils/2007-03/msg00004.html
> [2] http://www.sco.com/developers/gabi/latest/contents.html

-- 
http://twiki.wrs.com/do/view/APPdb/DefectTrackerFAQ
http://twiki.wrs.com/do/view/ENGtools/MozillaAtWindriver