[Coco] Fwd: failure notice

Tue May 12 04:26:20 EDT 2015

Gene, ROFs don't have a CRC. It would be useless anyway since they are going to eventually be compiled into a much larger file that will have a CRC. I think the linker adds the CRC in the final stage of an compilation or assembly.
I thought of just zapping the 2 extra bytes, but that won't solve finding out what's causing it. Besides, there's over 120 files in the clib.l alone.

I'm going to try some experiments using the execs from the L1 compiler and do it straight out the box and see what happens.
I tried with c.comp, c.pass 1 & 2, both with rma. I thought I tried with c.asm, but according to my logs, I didn't, so I'm wondering now if it's rma. I'm using rma from the repo, which I've had no problem with my C projects, some with over 150 files. The linker may be ignoring the 2 extra bytes when compiling individual "normal" rofs from sources in a program because it's using the file length and only copying "x" amount of bytes from the rof. But wwhen they're merged as in a library, it's having problems "finding" the next rof due to the two bytes throwing the count off. Instead of seeing 62CD, it's seeing 0000.
I may try the old rma from the dev sys disk and see what happens. Something is creating those two bytes. It can't be the C compilers because it happens on the ".a" sources as well as the ".c" sources. The only thing that touches the final ".a" files is rma which leaves them as ".r" files. 

I'm trying to find a disassembler that handles ROFs, but nothing is set up for it. Most disassembler check for "87CD" and puke if it's not there. I found one that will do raw files, but I have to go step by step through  the header to find the first op-code. Sleuth looks for 87CD so it tells me the file is invalid. It could be setup to read through an ROF header, but it would be tough LOL.

Here's a link to the ROF file format:
https://dl.dropboxusercontent.com/u/23059963/Stuff/Relocatable%20Object%20File%20%28ROF%29%20Format.txt

Bill Pierce
"Today is a good day... I woke up" - Ritchie Havens

My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
E-Mail: ooogalapasooo at aol.com

-----Original Message-----
From: Gene Heskett <gheskett at wdtv.com>
To: coco <coco at maltedmedia.com>
Sent: Tue, May 12, 2015 3:43 am
Subject: Re: [Coco] Fwd: failure notice

On Tuesday 12 May 2015 02:40:36 Bill Pierce via Coco wrote:
> Gene, I haven't a
clue why the email didn't go through, I used the
> same address and method I
always use... probably some "Linus
> thing".... security blanket and all that...
(j/k)but anyway...

Naw, likely aol has gone down the same road yahoo has with a
certificate 
based msg acceptance policy.  That BS has rather effectively broken
the 
internet.  And I find it a bit ironic that yahoo was first with it, when

in fact 20% of my incoming spam has been thru a yahoo server.

> The problem is
that when I assemble (or compile, in the case of C
> sources) the sources to
CK's clib.l, EVERY resulting ROF has 2 extra
> zeros at the end.
>
> Apparently,
when trying to compile a C file using the merged library,
> the linker (and any
other file made to use ROFs), reads the header,
> which is WAAAY different from
a standard OS9 header, and get the ROF's
> size, then uses this size to
calculate where the next header should
> be... So the zeros must not be figured
into the size as the linker and
> CK's "lib" which separates C libraries,
reports that the file is not
> an valid ROF. In fact, CK's "lib" separates the
first file in the
> library then pukes on the second because it can't find the
header, so
> it assumes the library is not an ROF. It will separate CK's
clib.l
> fine. I have checked the assembled files against the library files
>
that I've been using and they are byte-for-byte identical except for
> those two
bytes at the end. Even the headers are the same.
>
> I tried using RMA and
C.Asm, and both produce the same result. The
> resulting rofs, when merged,
should make a valid lib file, but the
> linker says no, and aborts if I use the
lib in a C compile.
>
> And I have CK's notes on the contents of the ROF header.
It's much
> more complex than a standard OS9 modules header. The ROF header
>
contains all the info about the file's global and dp variables as well
> as the
pointers, so that the linker can tie them all together later
> when used in
module. In a C library, these ROFs are left raw and just
> merged so the linker
is not involved until the library is used.
>
> I want to make some "custom"
libraries, but until I solve what's
> adding the "00 00" to the end, it ain't
happenin'

Does the linker use the module length, and is this module length
correct 
such the the extra $0000 int is detectable, and fixable by a quick

assembly program that would copy only the valid bytes, piping that into 
the
merge command that makes the library?

Its a problem I never had a decade and
change ago.  Have you asked 
Willard, who did a more recent c.prep, if he has
encountered this?
If not, get the crc's of what he is using so you can tell when
you've 
found the ones that work.

Worse comes to worse, ded might be able to
fix it by reducing the module 
size by 2 bytes, do this in the raw ROF's FD
sector. How difficult this 
is depends on how many modules there are to fix. 
Keep in mind that 
would probably need a v for verify to fix the files crc for
the new, 
shorter data length too.  I think this would have to be a 2 copies of

ded running project, one to edit the FD.sector, and one to load the file 
to
verify that it has been fixed.

Unless you can ID the compiler module that is
doing the fubar output, 
thats the best idea I can come up with.

> Bill
Pierce
> "Today is a good day... I woke up" - Ritchie Havens
>
>
> My Music from
the Tandy/Radio Shack Color Computer 2 & 3
>
https://sites.google.com/site/dabarnstudio/
> Co-Contributor, Co-Editor for
CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
> E-Mail:
ooogalapasooo at aol.com

Cheers, Gene Heskett
-- 
"There are four boxes to be used
in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that
order."
-Ed Howdershelt (Author)
Genes Web page
<http://geneslinuxbox.net:6309/gene>

-- 
Coco mailing
list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco