This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


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     

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]