RE: extracting relocation info from COFF from"section contents" base d on partial_inplace

["Liang, James" <jliang at sandia dot gov>]

Oops.. looks like a timing issue.

At the time I sent that email saying, "output of objdump -s and
bfd_get_section_contents is just a array of bytes.", I was replying to
someone else's email reply to me and hadn't seen your post because I only
get a digest of the mailing list a certain timed intervals.  Consequently, I
posted and replied to a single person and I didn't see your email until the
digest arrived a few moments ago.  

Your first post was very clear and I understand enough to fix the problem.
Thank you again for your help.

James

> -----Original Message-----
> From: Dave Korn [mailto:dk@artimi.com]
> Sent: Thursday, April 08, 2004 12:10 PM
> To: binutils@sources.redhat.com
> Subject: RE: extracting relocation info from COFF from "section
> contents" base d on partial_inplace
> 
> 
> > -----Original Message-----
> > From: binutils-owner On Behalf Of Liang, James
> > Sent: 08 April 2004 19:05
> 
> > The output of objdump -s and bfd_get_section_contents is just 
> > a array of
> > bytes.  What I'd like to know is where the Addend and other 
> > offset related
> > info is stored.
> 
>   The addends are *in* that array of bytes, at the offset 
> indicated by the
> arelent->address field (what I referred to as 'destination' in my last
> post).
> 
> 
> > For example, if my code says:
> > 	extern struct someStruct externData;
> > 
> > 	void function() {
> > 	  printf("%d\n",externData.accessCounter);
> > 	}
> > 
> > 
> > There should normally be some info stored in the object, I 
> > think the Addend
> > field, that tells the offset to accessCounter.
> 
> Yep.  The symbol will point to externData and the 
> offset/addend will be the
> distance to the accessCounter member.
> 
> However, the whole point (about REL vs RELA) is that in this case, the
> addend is not in a field in the arelent reloc struct, but is 
> in the bytes of
> the input section indicated by the address.
> 
> 
>     cheers, 
>       DaveK
> -- 
> Can't think of a witty .sigline today....
> 
>