[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Gcl-devel] bfd coff back-end

From: Mike Thomas
Subject: RE: [Gcl-devel] bfd coff back-end
Date: Mon, 12 Jan 2004 16:00:51 +1000

Hi Aurelian.

| Sorry for the delay getting back to you, I'm fairly busy at the moment.

Thanks for taking the time - delay is no problem as I a totally bewildered
with this code!

| I thought I would be more helpful in looking at the matter myself, so I
| installed mingw, compiled binutils 2.14 and ran a sample program to
| test dynamic loading. While there is probably more to it than what I
| relate below, here is a first issue :

I have both the GCL CVS version and the MinGW 2.14.90-20030807-1 source
download from Sourceforge.  Below I am talking about the 2.14.90-20030807-1

| Basically, there are two files of interest. The first one is coffcode.h
| and the second one is coff-i386.c. BFD relocation entries (of type
| arelent) have an address field, which is not an absolute address, but a
| section relative offset. As can be seen, this convention is enforced at
| coff-i386.c:144.

This is where "reloc_entry->address" is added to "data" in the DOIT macro.

| However, this convention is violated at
| coffcode.h:5037.

| Running objdump -r on a sample object file reveals
| that COFF relocation entries have an r_vaddr field which looks like a
| section relative offset.

Here is what I get on a small GCL object module.  Are you saying that the
OFFSET column below is the value held in the r_vaddr field:

$ objdump -r ./gazonk0.o

./gazonk0.o:     file format pe-i386

OFFSET   TYPE              VALUE
00000004 dir32             .data
00000009 DISP32            _do_init
00000018 dir32             _vs_limit
0000001e dir32             _vs_base
00000024 dir32             _vs_top
00000039 dir32             _vs_top
0000003e DISP32            _number_plus
0000004a dir32             _vs_top
0000004f dir32             _vs_base
0000005d DISP32            _vs_overflow

OFFSET   TYPE              VALUE
00000000 dir32             .text

OFFSET   TYPE              VALUE
00000014 dir32             .text
00000020 dir32             .text
000007dc dir32             .text
00000800 dir32             .text
00000920 dir32             .data
0000092c dir32             .text

The following stuff is happening in the "coff_slurp_reloc_table()" function.

| Apparently, this section relative offset is
| being considered as an absolute address in coffcode.h, which is why we
| later get a segmentation violation. In coffcode.h, cache_ptr->address
| is set at line 5002,

At my line 5053 ?:

      cache_ptr->address = dst.r_vaddr;

| and then incorrectly adjusted at line 5037.

At my line 5088 ?:
      cache_ptr->address -= asect->vma;

| The
| fix might be to zero out the section's vma (asect->vma) prior to
| calling bfd_get_relocated_section_contents in bfdtest.c, but I'm not
| 100% sure of that.

Putting s->vma = 0 just before that call gives a crash in the C runtime
writing to a file, so I suppose there is a file index gone wrong somewhere

For me this gives an error at line 714 of libbfd.c during:

  bfd_seek (abfd, section->filepos + offset, SEEK_SET)

the offset seems to be bad.

| I'll continue investigating this when I have time.

Likewise - thanks

Mike Thomas.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]