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

[Mike Thomas]

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
source

| 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

RELOCATION RECORDS FOR [.text]:
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


RELOCATION RECORDS FOR [.data]:
OFFSET   TYPE              VALUE
00000000 dir32             .text


RELOCATION RECORDS FOR [.stab]:
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.