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]

Re: objcopy --strip-debug breaks GROUP sections


"H.J. Lu" <hjl.tools@gmail.com> writes:

> On Tue, Feb 16, 2010 at 9:25 AM, Eirik Byrkjeflot Anonsen
> <eirik@opera.com> wrote:
>> Eirik Byrkjeflot Anonsen <eirik@opera.com> writes:
>>
>>> 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.
>> [...]
>>> 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
>>
>> Changing bfd_elf_set_group_contents() to shrink sh_size and skip the
>> sections that will not be output seems to solve the problem. ©˘Does
>> anyone think that this is something I should try to clean up and submit
>> a patch for? ©˘Or am I doing something completely wrong?
>>
>> (I haven't been able to fully test this yet, as I now have problems with
>> the .arm_vfe_vcallinfoi.* sections, I believe. ©˘Probably objcopy doesn't
>> renumber the section references in those sections.)
>>
>
> Please open a bug report with a self-contained testcase, which can
> be reproduced with a cross binutils.

Am I to interpret that as you think that leaving null references in
SHT_GROUP sections is probably a bug?

I'll see if I can find the time to construct such a beast.

eirik


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