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 --strip-debug breaks GROUP sections


Using binutils 2.20, I find that running objcopy --strip-debug generates
"invalid" GROUP sections.  ("invalid" in the sense that ar complains and
the linker fails...  I haven't checked any specifications.)


It seems that what happens is that when sections are removed from the
object file, any references to that section within GROUP sections are
set to 0.  Example readelf output (somewhat doctored):


Original file:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] _ZN10GreatClassC1 GROUP           00000000 000034 00001c 04     510 543  4
...
  [498] i._ZN10GreatClass PROGBITS        00000000 00faa0 000018 00 AXG  0   0  4
  [499] .ARM.exidx        ARM_EXIDX       00000000 00fab8 000008 00 ALG 498   0  4
  [500] .rel.ARM.exidx    REL             00000000 01f2c0 000008 08     510 499  4
  [501] .debug_frame$$$i. PROGBITS        00000000 00fac0 00007c 00   G  0   0  1
  [502] .rel.debug_frame$ REL             00000000 01f2c8 000010 08     510 501  4
  [503] .debug_info$$$i._ PROGBITS        00000000 00fb3c 0000b4 00   G  0   0  1
  [504] .rel.debug_info$$ REL             00000000 01f2d8 000068 08     510 503  4
  [505] .debug_line$$$i._ PROGBITS        00000000 00fbf0 000070 00   G  0   0  1
  [506] .rel.debug_line$$ REL             00000000 01f340 000008 08     510 505  4
  [507] .debug_loc$$$i._Z PROGBITS        00000000 00fc60 00003c 00   G  0   0  1
...
COMDAT group section [    1] `_ZN10GreatClassC1E7ArgType' [_ZN10GreatClassC1E7ArgType] contains 6 sections:
   [Index]    Name
   [  498]   i._ZN10GreatClassC1E7ArgType
   [  499]   .ARM.exidx
   [  501]   .debug_frame$$$i._ZN10GreatClassC1E7ArgType
   [  503]   .debug_info$$$i._ZN10GreatClassC1E7ArgType
   [  505]   .debug_line$$$i._ZN10GreatClassC1E7ArgType
   [  507]   .debug_loc$$$i._ZN10GreatClassC1E7ArgType



After --strip-debug:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] _ZN10GreatClassC1 GROUP           00000000 000034 00001c 04     93  82  4
...
  [88] i._ZN10GreatClass PROGBITS        00000000 00118c 000018 00 AXG  0   0  4
  [89] .ARM.exidx        ARM_EXIDX       00000000 0011a4 000008 00 ALG 88   0  4
...
COMDAT group section [    1] `_ZN10GreatClassC1E7ArgType' [_ZN10GreatClassC1E7ArgType] contains 6 se
ctions:
   [Index]    Name
   [   88]   i._ZN10GreatClassC1E7ArgType
   [   89]   .ARM.exidx
   [    0]   
   [    0]   
   [    0]   
   [    0]   



A bit of hexediting proves that both ar and the linker are quite happy
if I just set the size of the GROUP section to 0xc.


So my immediate question is: Where in the code is the output GROUP
section data generated?  Or, in other words, what do I change to make
objcopy not output the null references?

eirik


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