|building xcoff-linker firstname.lastname@example.org (Thomas Vyskocil) (1997-06-10)|
|Re: building xcoff-linker email@example.com (Ian Lance Taylor) (1997-06-13)|
|From:||Ian Lance Taylor <firstname.lastname@example.org>|
|Date:||13 Jun 1997 22:02:45 -0400|
In comp.compilers Thomas Vyskocil <email@example.com> writes:
>My questions are about some values and their interpretation in some
>What is the meaning of the storageclass value 107 in the symbol record
That is C_HIDEXT. It is a symbol which is just like a global symbol,
but is actually local. There is no short way of explaining this
without also explaining the whole csect system used in XCOFF files.
If you don't know what csects are, I'm afraid you have a long hard
road ahead of you.
>and what is the meaning of the relocation type entry 7936 in the
>-26358 means patch with 26 bit format
>-28925 means patch with 16 bit format
> 7936 probably means patch with 32 bit format
Relocation entries in XCOFF files are not simple numeric codes. They
are 16 bit values. The low 8 bits are the type. The next 5 bits are
the size in bits minus 1. The high bit is whether the relocation is
signed. 2 bits are unused.
7926 is 0x1f00. Type 0 is a normal positive relocation. The 0x1f is
the size: 32 bits.
>Is there some free documentation about this topic available on the
>internet? I didn't find anything worthful!
The GNU linker fully supports XCOFF, so in some sense the source code
can serve as documentation for what an XCOFF linker must do. You find
the GNU linker in the binutils distribution on any GNU archive site.
There is also an XCOFF manual available at
which may be of some help. I haven't looked at it recently.
Don't be misled into thinking that an XCOFF linker is simple, or
anything like a COFF linker. XCOFF is a bizarre format, and the
linker is not in the standard Unix tradition.
Return to the
Search the comp.compilers archives again.