Jump to content

ggn

Members
  • Content Count

    1,604
  • Joined

  • Last visited

Community Reputation

2,172 Excellent

About ggn

  • Rank
    Stargunner

Profile Information

  • Gender
    Male
  • Location
    Greece

Recent Profile Visitors

21,873 profile views
  1. Hmm, that's odd The differences start yet again on the name of the segments - old has ".text", new has "TEXT" etc. Did you apply that fix? [EDIT] On second thoughts, could you attach brownboot.s? I'll take a look at it here and not have to bother you.
  2. Oh, I see. Well, v2.0.20 doesn't have the proposed fixes of this thread yet (because we're still investigating). So what you could do is to grab the latest snapshot of the source code (currently http://shamusworld.gotdns.org/cgi-bin/gitweb.cgi?p=rmac;a=tree;h=234f42879ceda29cd6a37a50ff287730f4ac632e;hb=HEAD - just click "snapshot") and then apply the things on this thread. This means posts #102 and #108. Then recompile and generate brownboot.o. I expect that with this you'll get equal sized files but with a few diffs. I hope we're getting to the bottom of this soon!
  3. Oh hi, I lost track of this thread because I missed the edit in the last post. So, my guess that now you should be able to make equal sized brownboot.o files but with some slight differences. Could you try that?
  4. Sorry, but the invocation is wrong, it should be: swapd0$ rmac-old -fe -o brownboot-old.o brownboot.s swapd0$ rmac-new -fe -o brownboot-new.o brownboot.s (yes, it's a remnant from the old MadMac times, the idea behind this is that you can assemble multiple files from the command line that have different options you can switch on and off. So whenever rmac encounters an input file, it goes and assembles without parsing the rest of the arguments) (I still believe there's an issue since the register clashing is real fwiw)
  5. Without going any further I noticed some weird things. For starters, brownboot.o: That's 68000 code in there, and it seems that after that 4E75 (RTS) where everything starts mismatching very badly there is a "10a8 60c1 4e75" (which is move.b $6061(a0),a0) / rts) snippet inserted in the "old" version instead of just a "4ef9" which appears on the "new" version. Similarly, in gpu.o: A "0000 0000" is inserted at offset $78 which seems to derail the whole binary afterwards. The other two sets of .o files seem to be an identical match, but I'm puzzled about these two. It seems like they're assembled from a different version of the source codes. Is it possible that this is the case?
  6. Are you able to diff a few object files now?
  7. I just realised that I actually have some of these files since they're from dml's tiny startup code - d'oh! So I tried assembling brownboot.s using a pre-2.0.0 version of rmac, as well as the latest with all the the above proposed fixed applied. Then I binary diffed them and something stood out: Seems like the name of the section names was turned to lower case at some point and nobody complained until now. So, current theory: the linker is anal about case sensitivity in section names, sees the label names, loads them into a different section, then sees that the sections aren't used, and then zaps them from orbit. So let's try something. Around line 561 of object.c there should be a line like shstSize += DepositELFSHSTEntry(&shstPtr, ".text"); and a similar line below for ".data" and ".bss". Change those to "TEXT', "DATA", and "BSS" (note: no leading dot "."). Recompile rmac and test things out. I have a good feeling about this
  8. Hi there, Thanks a lot for the files. From the little I can gather it seems like the linker is rejecting the data from the symbols. So my guess is that while it's importing the symbols correctly, it thinks that the data associated with the symbols is 0 in length, maybe that's the reason you see symbol addresses clashing. Also, since we get such a large difference in the final binaries, it makes little sense to binary compare them. Instead, it'd be really useful if you could binary diff the object files generated by the two rmacs. For example brownboot.o. At least there I more or less expect to see the same file sizes but some bytes will be different, most likely in the symbol table. So it'd be great if I could have such a diff. Also, as for a visual hex diff client you can try https://winmerge.org - just go to edit->options under "binary" and append the file extension you'll diff (most likely ".o"). Then drag the two object files and it'll do its job. Thanks for going through with this so far!
  9. If it's only rmac that's different between the 2 builds you could even binary compare the two different output files. Also, producing a map file ("-Xlinker -Map=output.map" for gcc) when linking might also shed some clues. Or, even better, binary diffing the object files produced by the 2 rmacs would help tremendously.
  10. Hi, There are a lot of things that could have gone wrong there. Also many questions like: 1) Do you still have your own install? Is <installdir>\bin\m68k-atari-mint-gcc.exe present? 2) Do you compile your programs from the command line or from an editor (like notepad++, check out tutorial #1 for more info) 3) When you say "re-installed" do you grab a zip from github and unpack it, or do you use the installer (bad idea, it's outdated)? 4) If you compile from console did you execute any other commands other than build.bat? 5) What do you get if you execute "echo %RBTOOLS%" on a new console and after you build something? 6) Did you get any other build errors? If yes, what were they? ... I could go on with this list but I guess there's little point since you're back in operation now. Unless you want to help troubleshoot this, in which case we'll need to narrow it down. But you'll have to help me by answering a lot of bizarre questions :).
  11. Ok, so what probably happens now is that rmac optimistically exports all global symbols as Absolute. Reading your post (thanks for bearing with this btw) I think the problem isn't in skunk.s but brownboot.s, or rather the way symbols are exported in brownboot.s. Last time I asked you to remove these two lines in object.c: else if (globflag) st_shndx = 0; // Global, not absolute This time I ask of you to replace them with else if (globflag && !(w1 & DEFINED) && (w1 & REFERENCED)) { st_shndx = SHN_UNDEF; } This will hopefully fix all your "multiple definition" issues (unless there's some other case I'm not considering right now, which is possible!). So give it a go and let us know what happens. Thanks
  12. Also while I was at it, I submitted a patch for one of @dilinger's bug reports in post #75
  13. Right, I might have fixed it. If you can compile your own rmac (I assume you can judging from the fact that you have patched it in the past), open object.c and go to lines 243 and 244 and comment them out. To be 100% clear, these should read: else if (globflag) st_shndx = 0; // Global, not absolute Then recompile and test. I checked and this code hasn't been touched since it was initially committed so when we added a fix for another issue (see above), the rmac listing reported your global/absolute symbol as: gpu_foo 0000000000F0300C ag (a=absolute, g=global) However the exported symbol needed the magic value fff1 (at least according to https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-94076.html#chapter6-tbl-16). Anyway, do try this out and tell us if it works so we can apply it to the main tree :).
  14. Are we talking about @Zerosquare's DSP routines as used, for example, here? If yes, after a bit of fiddling I found that the tool sox can create adpcm μlaw samples just fine: sox <input> --channels 1 --bits 8 --encoding mu-law <output.ul> --show-progress rate -v <rate> From what I recall, it's very important for the output file extension to be "ul". Other than that it should be fine. Hope this helps!
  15. Okay, interesting. I'll definitely take a look at it soon (perhaps tomorrow).
×
×
  • Create New...