delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/04/17/22:49:06

From: "Christopher Nelson" <paradox AT gye DOT satnet DOT net>
To: <djgpp AT delorie DOT com>
Subject: RELOC_XXXXX
Date: Sat, 17 Apr 1999 21:44:15 -0600
Message-ID: <01be894d$bb12a140$LocalHost@thendren>
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Reply-To: djgpp AT delorie DOT com

This is a multi-part message in MIME format.

------=_NextPart_000_0026_01BE891B.70783140
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Thanks for all the help you've given me up to now, but I have discovered =
another problem that I can't find the solution too, and is related to =
the same area.
=20
The DOCS say:
RELOC_ADDR32

To do this relocation, you must perform the following steps:=20

a.. Get the address of the symbol referred to.=20
    b.. Add the value currently stored in the location being adjusted.=20
    c.. Store the value back into the location being adjusted.=20
   =20
This is fine if the object contains only one section, but when it =
contains multiple sections, it leaves a little bit of specification.

According to the paragraph above in the instructions, "If the symbol is =
in the same object, the symbol table will have entries that refer to the =
sections themselves (always there and always private) that will be =
referred to. When you relocate the section itself, these symbols will =
reflect its new location."

The symbol I'm trying to adjust in this instance is a global integer =
located in a section called .xptdata.
This is the code I use to readjust a RELOC_ADDR32:

(the 'a' below is a loop variable that goes from 0 to =
file_header.f_nscns-1)

unsigned long *sc;
unsigned long offset, new_base;
unsigned long orig;

sc        =3D (unsigned long *)sections[a].data;
offset    =3D r->r_vaddr; // - sections[a].header.s_paddr;
new_base  =3D (unsigned =
long)sections[sym_table[r->r_symndx].e_scnum-1].data;=20

*(sc+offset) +=3D (unsigned long)new_base;

The description above doesn't say whether I should use the base address =
of the section that the variable is contained in (which sounds =
reasonable) or whether it needs to be in the section that contains the =
reloc entry.  (or, in other words, if the value i add in is the base of =
the section where the variable is found, or the base of the section that =
the relocation entry is part of.)

The problem is, this doesn't seem to work.  The relocated code executes =
fine, but the address for the variable is 0x40, which is definitely not =
right.  This is the offset that I get in the r->r_vaddr member too.

What am I overlooking?

    -=3D{C}=3D-

------=_NextPart_000_0026_01BE891B.70783140
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Thanks for all the help you've given =
me up to=20
now, but I have discovered another problem that I can't find the =
solution too,=20
and is related to the same area.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The DOCS say:</FONT></DIV>
<DIV><FONT size=3D2>
<P><TT><B>RELOC_ADDR32</B></TT></P>
<P>To do this relocation, you must perform the following steps:=20
<UL>
    <LI>Get the address of the symbol referred to.=20
    <LI>Add the value currently stored in the location being adjusted.=20
    <LI>Store the value back into the location being adjusted. =
</LI></UL></DIV>
<DIV>&nbsp;</DIV>
<DIV>This is fine if the object contains only one section, but when it =
contains=20
multiple sections, it leaves a little bit of specification.</DIV>
<DIV>&nbsp;</DIV>
<DIV>According to the paragraph above in the instructions, &quot;If the =
symbol=20
is in the same object, the symbol table will have entries that refer to =
the=20
sections themselves (always there and always private) that will be =
referred to.=20
When you relocate the section itself, these symbols will reflect its new =

location.&quot;</DIV>
<DIV>&nbsp;</DIV>
<DIV>The symbol I'm trying to adjust in this instance is a global =
integer=20
located in a section called .xptdata.</DIV>
<DIV>This is the code I use to readjust a RELOC_ADDR32:</DIV>
<DIV>&nbsp;</DIV>
<DIV>(the 'a' below is a loop variable that goes from 0 to=20
file_header.f_nscns-1)</DIV>
<DIV>&nbsp;</DIV>
<DIV>unsigned long *sc;<BR>unsigned long offset, new_base;<BR>unsigned =
long=20
orig;<BR></DIV>
<DIV>sc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D (unsigned long=20
*)sections[a].data;<BR>offset&nbsp;&nbsp;&nbsp; =3D r-&gt;r_vaddr; // -=20
sections[a].header.s_paddr;<BR>new_base&nbsp; =3D (unsigned=20
long)sections[sym_table[r-&gt;r_symndx].e_scnum-1].data;&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>*(sc+offset) +=3D (unsigned long)new_base;</DIV>
<DIV>&nbsp;</DIV>
<DIV>The description above doesn't say whether I should use the base =
address of=20
the section that the variable is contained in (which sounds reasonable) =
or=20
whether it needs to be in the section that contains the reloc =
entry.&nbsp; (or,=20
in other words, if the value i add in is the base of the section where =
the=20
variable is found, or the base of the section that the relocation entry =
is part=20
of.)</DIV>
<DIV>&nbsp;</DIV>
<DIV>The problem is, this doesn't seem to work.&nbsp; The relocated code =

executes fine, but the address for the variable is 0x40, which is =
definitely not=20
right.&nbsp; This is the offset that I get in the r-&gt;r_vaddr member=20
too.</DIV>
<DIV>&nbsp;</DIV>
<DIV>What am I overlooking?</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000>&nbsp;&nbsp;&nbsp;=20
-=3D{C}=3D-</FONT></DIV></FONT></BODY></HTML>

------=_NextPart_000_0026_01BE891B.70783140--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019