greg@mobius.Viewlogic.COM (Gregory Larkin) (01/10/91)
Well, the fight continues to get a SPARC executable to read a Minix
.a file.
Thanks to all Minixers who replied to my original post! I now get the
little-endian vs. big-endian concept.
So, once I got that down, I thought "all I have to do is swap bytes
when I read from the .a file". Well, yes and no.
I am able to swap the bytes containing the magic number, so the file
will be recognized correctly.
However, when the first header structure is read out of the .a file,
most everything in it does not come in correctly.
Here's the struct for .a header:
struct ar_hdr {
char ar_name[14];
long ar_date;
char ar_uid;
char ar_gid;
int ar_mode;
long ar_size;
};
ar_name seems to be Ok. In this case, I am trying to unarchive h.a
in the src/h directory. The first file is "callnr.h". This comes
out fine. The problem is, ar_size is set to some huge number (much
more than the 1683 bytes it should be). So, when ar(1) tries to
seek to the next header, it runs off the end of the file.
The other structure elements seem to be corrupted, as well. Is there
some sort of special swapping of bytes I should do within the structure
or should I swap the bytes of the structure as a whole??
This is close enough to working (I think) that I really don't want to
go back to Minix and unarchive all of the .a files and then tar the
contents. It would work, but hey, it's more fun trying to get this
to work.
If anyone has any more hints for me, I would love to hear them!
--
Greg Larkin (ASIC Engineer)
Viewlogic Systems, Inc. (The CAE Company)
293 Boston Post Road West ____________________________________________
Marlboro, MA 01752 |"This is a fragile ball we are living on; |
508 480 0881 x321 |it's a miracle and we are destroying it.."|
Email: greg@Viewlogic.COM |Peter Garrett, Midnight Oil |
--------------------------------------------des@frogland.inmos.co.uk (David Shepherd) (01/10/91)
In article <1991Jan9.151828@mobius.Viewlogic.COM>, greg@mobius.Viewlogic.COM (Gregory Larkin) writes: |> Well, the fight continues to get a SPARC executable to read a Minix |> .a file. |> |> However, when the first header structure is read out of the .a file, |> most everything in it does not come in correctly. |> Here's the struct for .a header: .... let me guess .... the header gets read in by a command like fread(f, &hdr, sizeof (struct ar_hdr), 1); if so this is your problem. This is *NON-PORTABLE*. The Sparc C compiler does (clever?) things with the positioning of elements inside a struct .... in particular it will align entries to word boundaries if there are word lengthed items in it. So in |> struct ar_hdr { |> char ar_name[14]; |> long ar_date; |> char ar_uid; |> char ar_gid; |> int ar_mode; |> long ar_size; |> }; The Sparc C compiler sees the struct as being 14 bytes of ar_name 2 bytes padding 4 bytes of ar_date 1 byte of ar_uid 1 byte of ar_gid 2 bytes padding 4 bytes of ar_mode <- ints are 32 bits here 4 bytes of ar_size Hence reading in a struct which probably doesn't align components (and probably has 16 bit ints) causes rubbish to be seen in the struct components. The fix is probably to read in the struct as an array of bytes and assign the components by hand :-( -- -------------------------------------------------------------------------- david shepherd: des@inmos.co.uk or des@inmos.com tel: 0454-616616 x 529 inmos ltd, 1000 aztec west, almondsbury, bristol, bs12 4sq phevbfvgl xvyyrq gur png
cechew@bruce.cs.monash.OZ.AU (Earl Chew) (01/11/91)
In <12887@wraxall.inmos.co.uk> des@frogland.inmos.co.uk (David Shepherd) writes: >In article <1991Jan9.151828@mobius.Viewlogic.COM>, greg@mobius.Viewlogic.COM (Gregory Larkin) writes: >|> Well, the fight continues to get a SPARC executable to read a Minix >|> .a file. >|> >|> However, when the first header structure is read out of the .a file, >|> most everything in it does not come in correctly. >|> Here's the struct for .a header: >.... let me guess .... the header gets read in by a command like > fread(f, &hdr, sizeof (struct ar_hdr), 1); >if so this is your problem. This is *NON-PORTABLE*. The Sparc I forget about the 1.3 compiler, but the 1.5.10 ar.c packs and unpacks properly (I think --- well at least the intent is there --- I haven't verified that it works ok). Perhaps you can upload the 1.5.10 ar.c first and try that one. Earl -- Earl Chew, Dept of Computer Science, Monash University, Australia 3168 EMAIL: cechew@bruce.cs.monash.edu.au PHONE: 03 5655447 FAX: 03 5655146 ----------------------------------------------------------------------