This is the mail archive of the
mailing list for the binutils project.
Re: [objcopy]: zero to three bytes of padding in .gnu_debuglink section
The binutils package that I used is binutils-126.96.36.199.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
Best regards, Majcher.
2011/4/7 Alan Modra <email@example.com>:
> On Wed, Apr 06, 2011 at 05:54:59PM +0200, T Majchrowski wrote:
>> 2011/4/6 Alan Modra <firstname.lastname@example.org>
>> > 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