Re: [objcopy]: zero to three bytes of padding in .gnu_debuglink section

[T Majchrowski <bugtracker at majchrowski dot co dot uk>]

Thanks Alan.

The binutils package that I used is binutils-2.17.50.0.6-14.el5 as
this one is coming with OS (RH 5.5)
As a workarround I'm genereting debuginfo filenames strings which are
always multiplicity of 4.

Anyway I just checked latest sources and it's very nice that this has
been solved.

Best regards, Majcher.

2011/4/7 Alan Modra <amodra@gmail.com>:
> On Wed, Apr 06, 2011 at 05:54:59PM +0200, T Majchrowski wrote:
>> 2011/4/6 Alan Modra <amodra@gmail.com>
>> >
>> > On Mon, Apr 04, 2011 at 10:31:41AM -0700, Majcher wrote:
>> > > I found that .gnu_debuglink. section contains zero to three bytes of padding
>> > > just after filename. I recognized that this padding may be different
>> > > depending on which host is used to add gnu_debuglink via objcopy
>> > > --add-gnu-debuglink. Is there any way to provide always a fixed value of
>> > > that padding?
>> >
>> > No.
>> >
>> I checked sources, it seems so that it would quite easy to achieve
>> just by changing
>>
>> FROM: contents = malloc (debuglink_size );
>> TO: ? ? ?contents = calloc (debuglink_size,sizeof(char) );
>>
>> in bfd/opncls.c
>
> I misunderstood your question, thinking you were asking for a fixed
> length of padding. ?We already zero the padding.
>
> ?crc_offset = debuglink_size - 4;
> ?memcpy (contents, filename, filelen);
> ?memset (contents + filelen, 0, crc_offset - filelen);
>
> ?bfd_put_32 (abfd, crc32, contents + crc_offset);
>
>
> --
> Alan Modra
> Australia Development Lab, IBM
>