Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 May 1996 16:07:01 -0500
From:      "Brent J. Nordquist" <nordquist@platinum.com>
To:        jkh@time.cdrom.com (Jordan K. Hubbard)
Cc:        freebsd-ports@freebsd.org
Subject:   Re: Object files/formats
Message-ID:  <199605302107.QAA26785@doh.vt.platinum.com>
In-Reply-To: <14584.831814161@time.cdrom.com> from "Jordan K. Hubbard" at May 11, 96 06:29:21 am

next in thread | previous in thread | raw e-mail | index | archive | help
[Jordan:  I know you're pretty busy today!  I'm not sure if you're the
right person to deliver this to; if it's someone else, I'd appreciate
it if you would pass this on.  The patch enclosed is to fix the magic
problem for objects and executables.  Comments?]

THE TASK

There are at least two problems with file's identification of
FreeBSD objects and executables.  The first one was reported in
freebsd-ports:

Chuck Robey <chuckr@Glue.umd.edu> said:
| I am working on trying to get tcl to load an object file, and I just 
| noticed that the file command is returning:
|
| tclIO.o: NetBSD/i386 position independent object file not stripped

"Jordan K. Hubbard" <jkh@time.cdrom.com> replied:
| They all say that.  File's magic information has misidentified our
| object files for as long as I can remember now - I noted this quite
| a few months back myself, but so far nobody has done the hacking on
| /etc/magic necessary to fix it. :)

The second one is that some object files report "PDP-11 executable".
I wanted to fix the portions of the magic file relevant to FreeBSD
so objects and executables would be correctly identified.

CONTEXT

I have a 2.1-stable sup'ed on May 5.  The freebsd magic subfile I
started with is version 1.1.6.2.  (NOTE that according to the
check-in comments, the -current version is different, because of
the core file format.)

WHAT I DID

(1)  I tried to carefully follow the structure of the a.out format,
as laid out in <sys/imgact_aout.h>.  In particular, the freebsd
magic subfile now uses the proper masks to get the magic, middle,
and flag components.

(2)  It seems that the 134 value for the middle component (platform)
is used for all the BSD/i386 platforms, including at least FreeBSD
and NetBSD.  As a result, the freebsd magic subfile now prints
"BSD/i386", not "FreeBSD/i386", because it looks to me like you
can't tell.  (If someone who knows more about this knows how to
tell them apart, by all means let's put in some more sub-rules.)

(3)  Some of the object files produced by the compiler have the
right magic number, but oddly enough, in big-endian order.  The
netbsd magic subfile is smart enough to handle this, by repeating
all the sections, changing lelong to belong, etc..  That's why some
of our object files were being labeled as "NetBSD/i386 object
file", the original issue that got me interested in this.  I adopted
this technique in the freebsd file.

(4)  I removed the lines commented with:

  # This covers object files, and is better than "PDP-11 executable"

because they were never triggered, and were thus superfluous.
(This was because the whole long was being checked, rather than
just the magic part:  the low 16 bits.)  This is why our object
files with the 0407 magic were still being labeled as "PDP-11
executable".

TESTING

I rebuilt the full magic file and tested it on all the object files
(.o, .so, and .po) under /usr/obj, plus all the files in /usr/bin
and /usr/lib.  I assembled representative sample files, and compared
file's output to that of the hexdump command.  It looks to me like
file is now producing the correct output.

OBSERVATIONS

(1)  The old freebsd magic subfile used the entry point (long #6
at offset 20) to decide object file (less than 4k) vs. executable
(4k and greater).  I don't understand enough about the a.out format
to know if this is rock-solid, or just a best-guess.  I incorporated
that logic into the new change.

(2)  The -current subfile is apparently different because of the
core file format.  The equivalent change will have to be made to
the -current version.

(3)  At some point, someone should probably coordinate with the
keepers of the magic subfiles (as documented in the README) to
incorporate these changes.  They will have to deal with the fact
that the freebsd, netbsd, and linux magic subfiles all seem to lay
claim to the same object format.  My feeling is that common BSD/i386
formats that you can't tell apart should be merged together into
one file, and be reported generically as "BSD/i386".

CONTEXT DIFF FROM OLD SUBFILE (81 lines)

begin 644 freebsd.diff
M*BHJ(&9R965B<V0N;W)I9PE3870@36%Y("`T(#$U.C,P.C`U(#$Y.38*+2TM
M(&9R965B<V0)5&AU($UA>2`S,"`Q,#HU-3HU,B`Q.3DV"BHJ*BHJ*BHJ*BHJ
M*BHJ*@HJ*BH@,2PQ."`J*BHJ"B$@(R!T:&4@9F]L;&]W:6YG(&%R92!F;W(@
M,S@V0E-$+T9R965"4T0*("`*(2`P"6QE;&]N9PD)"3`T,3`)"7!U<F4@97AE
M8W5T86)L90HA(#`);&5L;VYG"0D),#0Q,PD)9&5M86YD('!A9V5D(&5X96-U
M=&%B;&4*(2`P"6QE;&]N9R8P-S<W-S<W-S<),#0Q-#`P,S$T"49R965"4T0O
M:3,X-B!D96UA;F0@<&%G960*(2`^,PEB>71E"0D))C!X.#`*(2`^/C(P"6QE
M;&]N9PD)"3PT,#DV"0ES:&%R960@;&EB<F%R>0HA(#X^,C`);&5L;VYG"0D)
M/30P.38)"61Y;F%M:6-A;&QY(&QI;FME9"!E>&5C=71A8FQE"B$@/CXR,`EL
M96QO;F<)"0D^-#`Y-@D)9'EN86UI8V%L;'D@;&EN:V5D(&5X96-U=&%B;&4*
M(2`^,PEB>71E"0D)7C!X.#`)"65X96-U=&%B;&4*("`^,38);&5L;VYG"0D)
M/C`)"6YO="!S=')I<'!E9`H@(`HA(",@5&AI<R!C;W9E<G,@;V)J96-T(&9I
M;&5S+"!A;F0@:7,@8F5T=&5R('1H86X@(E!$4"TQ,2!E>&5C=71A8FQE(@HA
M(#`);&5L;VYG"0D),#`P,#`P-#`W"6EM<'5R92!F;W)M870*("`^,38);&5L
M;VYG"0D)/C`)"6YO="!S=')I<'!E9`H@(`H@(",@6%A8(&=R;W-S(&AA8VL@
M=&\@:61E;G1I9GD@8V]R92!F:6QE<PH@(",@8V]R97,@<W1A<G0@=VET:"!A
M('-T<G5C="!T<W,[('=E('1A:V4@861V86YT86=E(&]F('1H92!F;VQL;W=I
M;F<Z"BTM+2`Q+#@T("TM+2T*(2`C('1H92!F;VQL;W=I;F<@87)E(&9O<B!"
M4T0O:3,X-B`H1G)E94)31"P@3F5T0E-$+"!E=&,N*0H@(`HA(#`);&5L;VYG
M)C`S-S<W-S<W-S<),#0Q-#`P-#`W"4)31"]I,S@V"B$@/C(P"6QE;&]N9PD)
M"3PT,#DV"B$@/CXS"6)Y=&4F,'A#,`D))C!X.#`)"7-H87)E9"!L:6)R87)Y
M"B$@/CXS"6)Y=&4F,'A#,`D),'@T,`D)4$E#(&]B:F5C=`HA(#X^,PEB>71E
M)C!X0S`)"3!X,#`)"6]B:F5C=`HA(#XR,`EL96QO;F<)"0D^-#`Y-0HA(#X^
M,PEB>71E)C!X.#`)"3!X.#`)"61Y;F%M:6-A;&QY(&QI;FME9"!E>&5C=71A
M8FQE"B$@/CXS"6)Y=&4F,'@X,`D),'@P,`D)97AE8W5T86)L90H@(#XQ-@EL
M96QO;F<)"0D^,`D);F]T('-T<FEP<&5D"B`@"B$@,`EL96QO;F<F,#,W-S<W
M-S<W-PDP-#$T,#`T,3`)0E-$+VDS.#8@<'5R90HA(#XR,`EL96QO;F<)"0D\
M-#`Y-@HA(#X^,PEB>71E)C!X0S`)"28P>#@P"0ES:&%R960@;&EB<F%R>0HA
M(#X^,PEB>71E)C!X0S`)"3!X-#`)"5!)0R!O8FIE8W0*(2`^/C,)8GET928P
M>$,P"0DP>#`P"0EO8FIE8W0*(2`^,C`);&5L;VYG"0D)/C0P.34*(2`^/C,)
M8GET928P>#@P"0DP>#@P"0ED>6YA;6EC86QL>2!L:6YK960@97AE8W5T86)L
M90HA(#X^,PEB>71E)C!X.#`)"3!X,#`)"65X96-U=&%B;&4*("`^,38);&5L
M;VYG"0D)/C`)"6YO="!S=')I<'!E9`HK(`HK(#`);&5L;VYG)C`S-S<W-S<W
M-S<),#0Q-#`P-#$S"4)31"]I,S@V(&1E;6%N9"!P86=E9`HK(#XR,`EL96QO
M;F<)"0D\-#`Y-@HK(#X^,PEB>71E)C!X0S`)"28P>#@P"0ES:&%R960@;&EB
M<F%R>0HK(#X^,PEB>71E)C!X0S`)"3!X-#`)"5!)0R!O8FIE8W0**R`^/C,)
M8GET928P>$,P"0DP>#`P"0EO8FIE8W0**R`^,C`);&5L;VYG"0D)/C0P.34*
M*R`^/C,)8GET928P>#@P"0DP>#@P"0ED>6YA;6EC86QL>2!L:6YK960@97AE
M8W5T86)L90HK(#X^,PEB>71E)C!X.#`)"3!X,#`)"65X96-U=&%B;&4**R`^
M,38);&5L;VYG"0D)/C`)"6YO="!S=')I<'!E9`HK(`HK(#`);&5L;VYG)C`S
M-S<W-S<W-S<),#0Q-#`P,S$T"4)31"]I,S@V(&-O;7!A8W0@9&5M86YD('!A
M9V5D"BL@/C(P"6QE;&]N9PD)"3PT,#DV"BL@/CXS"6)Y=&4F,'A#,`D))C!X
M.#`)"7-H87)E9"!L:6)R87)Y"BL@/CXS"6)Y=&4F,'A#,`D),'@T,`D)4$E#
M(&]B:F5C=`HK(#X^,PEB>71E)C!X0S`)"3!X,#`)"6]B:F5C=`HK(#XR,`EL
M96QO;F<)"0D^-#`Y-0HK(#X^,PEB>71E)C!X.#`)"3!X.#`)"61Y;F%M:6-A
M;&QY(&QI;FME9"!E>&5C=71A8FQE"BL@/CXS"6)Y=&4F,'@X,`D),'@P,`D)
M97AE8W5T86)L90HK(#XQ-@EL96QO;F<)"0D^,`D);F]T('-T<FEP<&5D"BL@
M"BL@,`EB96QO;F<F,#,W-S<W-S<W-PDP-#$T,#`T,#<)0E-$+VDS.#8**R`^
M,C`)8F5L;VYG"0D)/#0P.38**R`^/C`)8GET928P>$,P"0DF,'@X,`D)<VAA
M<F5D(&QI8G)A<GD**R`^/C`)8GET928P>$,P"0DP>#0P"0E024,@;V)J96-T
M"BL@/CXP"6)Y=&4F,'A#,`D),'@P,`D);V)J96-T"BL@/C(P"6)E;&]N9PD)
M"3XT,#DU"BL@/CXP"6)Y=&4F,'@X,`D),'@X,`D)9'EN86UI8V%L;'D@;&EN
M:V5D(&5X96-U=&%B;&4**R`^/C`)8GET928P>#@P"0DP>#`P"0EE>&5C=71A
M8FQE"BL@/C$V"6)E;&]N9PD)"3XP"0EN;W0@<W1R:7!P960**R`**R`P"6)E
M;&]N9R8P,S<W-S<W-S<W"3`T,30P,#0Q,`E"4T0O:3,X-B!P=7)E"BL@/C(P
M"6)E;&]N9PD)"3PT,#DV"BL@/CXP"6)Y=&4F,'A#,`D))C!X.#`)"7-H87)E
M9"!L:6)R87)Y"BL@/CXP"6)Y=&4F,'A#,`D),'@T,`D)4$E#(&]B:F5C=`HK
M(#X^,`EB>71E)C!X0S`)"3!X,#`)"6]B:F5C=`HK(#XR,`EB96QO;F<)"0D^
M-#`Y-0HK(#X^,`EB>71E)C!X.#`)"3!X.#`)"61Y;F%M:6-A;&QY(&QI;FME
M9"!E>&5C=71A8FQE"BL@/CXP"6)Y=&4F,'@X,`D),'@P,`D)97AE8W5T86)L
M90HK(#XQ-@EB96QO;F<)"0D^,`D);F]T('-T<FEP<&5D"BL@"BL@,`EB96QO
M;F<F,#,W-S<W-S<W-PDP-#$T,#`T,3,)0E-$+VDS.#8@9&5M86YD('!A9V5D
M"BL@/C(P"6)E;&]N9PD)"3PT,#DV"BL@/CXP"6)Y=&4F,'A#,`D))C!X.#`)
M"7-H87)E9"!L:6)R87)Y"BL@/CXP"6)Y=&4F,'A#,`D),'@T,`D)4$E#(&]B
M:F5C=`HK(#X^,`EB>71E)C!X0S`)"3!X,#`)"6]B:F5C=`HK(#XR,`EB96QO
M;F<)"0D^-#`Y-0HK(#X^,`EB>71E)C!X.#`)"3!X.#`)"61Y;F%M:6-A;&QY
M(&QI;FME9"!E>&5C=71A8FQE"BL@/CXP"6)Y=&4F,'@X,`D),'@P,`D)97AE
M8W5T86)L90HK(#XQ-@EB96QO;F<)"0D^,`D);F]T('-T<FEP<&5D"BL@"BL@
M,`EB96QO;F<F,#,W-S<W-S<W-PDP-#$T,#`S,30)0E-$+VDS.#8@8V]M<&%C
M="!D96UA;F0@<&%G960**R`^,C`)8F5L;VYG"0D)/#0P.38**R`^/C`)8GET
M928P>$,P"0DF,'@X,`D)<VAA<F5D(&QI8G)A<GD**R`^/C`)8GET928P>$,P
M"0DP>#0P"0E024,@;V)J96-T"BL@/CXP"6)Y=&4F,'A#,`D),'@P,`D);V)J
M96-T"BL@/C(P"6)E;&]N9PD)"3XT,#DU"BL@/CXP"6)Y=&4F,'@X,`D),'@X
M,`D)9'EN86UI8V%L;'D@;&EN:V5D(&5X96-U=&%B;&4**R`^/C`)8GET928P
M>#@P"0DP>#`P"0EE>&5C=71A8FQE"BL@/C$V"6)E;&]N9PD)"3XP"0EN;W0@
M<W1R:7!P960*("`*("`C(%A86"!G<F]S<R!H86-K('1O(&ED96YT:69Y(&-O
M<F4@9FEL97,*("`C(&-O<F5S('-T87)T('=I=&@@82!S=')U8W0@='-S.R!W
C92!T86ME(&%D=F%N=&%G92!O9B!T:&4@9F]L;&]W:6YG.@IU
`
end

-- 
Brent J. Nordquist      PLATINUM technology, inc. (ViaTech Development Lab)
nordquist@platinum.com  2600 Eagan Woods Dr., Suite 410, Eagan, MN  55121-1152

Voice +1 612 688-3033   Which is worse:  ignorance or apathy?
Vmail +1 708 620-5116               ...Who knows?
      (ext. 7806)                                  ...Who cares?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605302107.QAA26785>