miguel@imag.UUCP (Miguel Santana) (03/03/86)
Beeing writing a compiler for PCs (and compatible), we need a description
of the object code format used as input by the MS-DOS (PC-DOS) linker. I
should appreciate your mailing me a copy of this description.
Thank you.
----------------------------------------------------------------------------
uucp address : ...!seismo!mcvax!vmucnam!imag!miguel
Postal address : Miguel SANTANA
LGI/IMAG
BP 68
38402 St Martin d'Heres Cedex
Francerde@ukc.ac.uk (R.D.Eager) (03/04/86)
In article <549@imag.UUCP> miguel@imag.UUCP (Miguel Santana) writes: > >Beeing writing a compiler for PCs (and compatible), we need a description >of the object code format used as input by the MS-DOS (PC-DOS) linker. I >should appreciate your mailing me a copy of this description. > >Thank you. > I got a copy of this from the local Microsoft office; they were quite helpful. Also, it is based on an Intel spec you can get from the local Intel office. I don't know if they would like me photocopying it; anyway it is well over 100 pages...... -- Bob Eager rde@ukc.UUCP rde@ukc ...!mcvax!ukc!rde Phone: +44 227 66822 ext 7589
ericf@uwvax.UUCP (Eric Feigenson) (03/04/86)
While someone is looking for a reference to MS-DOS object file formats...
I recently was trying to analyze the .OBJ files under MS-DOS. I got
the "8086 Relocatable Object Module Formats" document from Intel
(Order number 121748-001) to aid me in my quest. However, there
seems to be a critical difference in the .OBJ format described in the
document, and the .OBJ files I found generated by the Microsoft C Compiler.
It's been a while (I got frustrated, and gave up for a while), but the
gist of the difference is the following: There are two record types in
an object module that describe global data, EXTDEF (for globals referenced
in the module, but not allocated space there) and PUBDEF (for globals
defined in the module). What I found was that there were symbols that
were defined in the module (i.e., space was allocated for them there)
that appeared in EXTDEF records (which implies that they were *not*
allocated in the module, and the linker would need to find the module
where the symbols *are* defined). Since I am mainly trying to find
out what symbols are external vs. public in a module, this is a very
annoying situation.
Can anyone shed any light on this? Have I overlooked something? Is
the Intel document describing something different than is dealt with
with the Microsoft C Compiler and Linker? Could a global symbol appear
in an EXTDEF *and* PUBDEF record? If necessary, I can produce a .OBJ
that exhibits this problem (no really, it does happen... I'm *not* crazy...)
Thanks!
--
-Eric Feigenson
Usenet: {seismo, allegra, ihnp4}!uwvax!ericf
Arpanet: ericf@wisc-rsch.arpalotto@talcott.UUCP (Jerry Lotto) (03/05/86)
In article <678@uwvax.UUCP>, ericf@uwvax.UUCP (Eric Feigenson) writes: > While someone is looking for a reference to MS-DOS object file formats... > > I recently was trying to analyze the .OBJ files under MS-DOS. I got > the "8086 Relocatable Object Module Formats" document from Intel > (Order number 121748-001) to aid me in my quest. However, there > seems to be a critical difference in the .OBJ format described in the > document, and the .OBJ files I found generated by the Microsoft C Compiler. The MS-DOS programmers ref. 8411-310-02 or later, Chapter 6 has the information you are looking for. In a nutshell: Segment, group and type definition records, all symbol definition records and the module end record differ from the Intel specification. Specifically - the Microsoft linker uses TYPDEF records for communal variable allocation only (contrary to Intels specs). If the TYPDEF referenced by some EXTDEF does not qualify a variable as communal, a matching PUBDEF is expected. Alternatively, if a PUBDEF matches a communal variable definition, it overrides the original assignment. -- Gerald Lotto - Harvard Chemistry Dept. UUCP: {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lhasa!lotto ARPA: lotto@harvard.EDU CSNET: lotto%harvard@csnet-relay