This is the mail archive of the binutils@sources.redhat.com 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]

Finding BFD bug





I apologize for the length of this post, or even the apparent irrelevance.
We are not using the standard binutils distribution, but we are looking for
some help with debugging the BFD.  Initially I start off the post with the
problem description, what we've done to narrow it down (to what we think is
the BFD), and how we are trying resolve it.  Finally I ask for any tips or
advice.

We are using the Xilinx Microblaze development kit, and we have run into
what appears to be a bug in their version of the BFD.  Initially we found
the bug when doing something of the sort:

file1.h:

struct test_t
{
  int x;
  char c;
};

extern struct test_t test[];

file1.c:

struct test_t test[] =
{
  {1, 'a'},
  {2, 'b'},
  {3, 'c'},
  {4, 'd'}
};

main.c:

#include "file1.h"

struct test_t *ptr1 = &test[0];
struct test_t *ptr2 = &test[1];
struct test_t *ptr3 = &test[2];

int main(void)
{
}

Given these three files, it produces bad addresses in ptr2 and ptr3.  If
test is located at address 0, then:

  &test[0] = 0
  &test[1] = 0 + sizeof(test_t) = 0 + 8 = 8
  &test[2] = 0 + 2*sizeof(test_t) = 0 + 2*8 = 16
  ...
  &test[n] = n*sizeof(test_t) = n*8

The sizeof(test_t) in our case is 8.  However, what we get instead is:

  &test[0] = 0
  &test[1] = 16
  &test[2] = 32

In general we find:

  &test[n] = 2*n*sizeof(test_t)

We've created several test cases, all with different sizes of struct test_t
and we consistently get the above addresses.  We did find one thing that
does generate the correct address:  merge all the files into one C file.
Then all the code works correctly.  We initially thought this might be a
gcc problem, so we dumped the assembly output.  For file1.c, we get:

        .file   1 "file1.c"
gcc2_compiled.:
__gnu_compiled_c:
        .globl  test
        .data
        .align  2
        .type    test,@object
test:
        .data32 1
        .data8  97
        .space  3
        .data32 2
        .data8  98
        .space  3
        .data32 3
        .data8  99
        .space  3
        .data32 4
        .data8  100
        .space  3
        .size    test,32

And for main.c (just the data section shown):

        .file   1 "main.c"
gcc2_compiled.:
__gnu_compiled_c:
        .globl  ptr1
        .data
        .align  2
        .type    ptr1,@object
        .size    ptr1,4
ptr1:
        .data32 test
        .globl  ptr2
        .align  2
        .type    ptr2,@object
        .size    ptr2,4
ptr2:
        .data32 test+8
        .globl  ptr3
        .align  2
        .type    ptr3,@object
        .size    ptr3,4
ptr3:
        .data32 test+16

The assembly looks fine (test, test+8, test+16).  So it didn't seem like an
compiler problem.  We extended our tests by doing something like:

file1.s:

.global test

.data

/* This is an array of 6 32-bit words */
test:
  .data32 0
  .data32 1
  .data32 2
  .data32 3
  .data32 4
  .data32 5

main.s (again, only the data section shown):

.global test2

.data
test2:
  .data32 test
  .data32 test+4
  .data32 test+8

After using gas and linking, we get the same problem:  test2 contains
{test, test+8, test+16}.  If we merge the two assembly files, the problem
goes away.  This screams at us as a linker problem.  To eliminate a general
linker error, we took the same code to a Linux box running the same version
of binutils.  In fact, we took the Xilinx modified source and configured
for i686-linux-gnu.  The problem does not appear when using the x86
version.  Seems to us when linking external symbols, the offsets get
broken.

So, since the error didn't appear in the x86 configuration, and only in the
Microblaze configuration, we are fairly certain the bug is in the
Microblaze portion of the code.  Most of the code is in the BFD library,
and surfing around in ld and reading docs it appears that the BFD does the
bulk of the linking anyhow.

We reported this to Xilinx, but right now our design is halted waiting for
a resolution.  We are happy generating our own version of the tools if we
knew how to fix it.  We are even willing to try and locate the bug ourself,
but we need a good starting point.

I'm asking anyone that may have seen this problem before, or one similar,
could point us in the right direction.  In fact, even if an knowledgeable
BFD person could point us to where in the BFD this type of linking occurs,
we would at least know where to look.

Thanks,
Pete LaDow
Peter_LaDow@selgs.com


------------------------------------------------
This e-mail may contain SEL confidential information.  The opinions
expressed are not necessarily those of SEL.  Any unauthorized disclosure,
distribution or other use is prohibited.  If you received this e-mail in
error, please notify the sender, permanently delete it, and destroy any
printout.  Thank you.


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