Closed mheyer32 closed 1 year ago
Something odd:
static __inline APTR __GetBssStart(void)
{ APTR res;
__asm("lea __edata,%0" : "=a" (res)); return res;
}
edata is supposed to be placed at the start of the BSS, while the symbol seem to be in the data segmat:
00000038 g .data 0000 00 __edata
..thats not the issue, though. I disabled the code to clear the bss segment and it didn't change the crash.
This may be related to #58
ADoom builds a library named doomsound_midi.library which implements the same interface as doomsound.library, but is re-routing the music playback to MIDI (while forwarding the SFX to the original doomsound.library).
This library had been working for years now, but it now seems to be broken. When loading the library, ADoom will consistently crash with various Gurus.. From looking at SnoopDos I can infer that it at least makes it through __UserLibInit https://github.com/mheyer32/ADoom/blob/master/adoom_src/doomsound_midi.c#L78
I don't see anything sticking out in the disassembly and bgdbserver won't help me either as it can't debug across library calls.
I'm open to the idea that I'm doing something wrong that now got tickled, but my hunch is that somehow the magic fairy dust in the linker/libnix that glues together a library into the right structure got broken.
how do I load that library? I copied all files and it works with sound... /shrug
Make sure, camd.library is installed on your testsystem. Otherwise ADoom will fall back to loading the original doomsound.library. You should be able to use SnoopDos to see the loading of all involved libraries.
the lib gets loaded now, but there is still no music:
I shuffled around and at least got rid of the end file. The midi library will compile again and does not need any source change.
... needs some more checking, since there are more complaints... but at least libnix will work without using the CONTRUCTOR directive, which is e.g. not supported in elf.
The Music will come out of the serial port as MIDI stream. In WinUAE you can redirect the Amiga's serial port to a Midi synth like MUNT. But since its not crashing for you, that's already a good sign.
The changes are live.
ping
There's still something off... need to traige more. So far it had helped to use the unstripped library binary... I guess something is writing where it shouldn't...
Ohhh, while investigating the linking failures, I introduced a bug myself... closing now.
There's still something borked - and I just can't figure out what. If I build doomsound_midi.library in debug mode, it works, in release mode it doesn't.
Interestingly, comparing FuncTable between a debug build and a release build, they seem to have different sizes:
Release:
00000f8c 00000f8c <__FuncTable__>:
f8c: 0000 0001 ori.b #1,d0
f90: ffff .short 0xffff
f92: ffff .short 0xffff
f94: 0000 0000 ori.b #0,d0
f98: 0000 0000 ori.b #0,d0
f9c: 0000 0070 ori.b #112,d0
fa0: 0000 0052 ori.b #82,d0
fa4: 0000 0008 ori.b #8,d0
fa8: 0000 0004 ori.b #4,d0
fac: 0000 0266 ori.b #102,d0
fb0: 0000 0278 ori.b #120,d0
fb4: 0000 0296 ori.b #-106,d0
fb8: 0000 02b0 ori.b #-80,d0
fbc: 0000 02c2 ori.b #-62,d0
fc0: 0000 02d4 ori.b #-44,d0
fc4: 0000 02e6 ori.b #-26,d0
fc8: 0000 02f8 ori.b #-8,d0
fcc: 0000 030a ori.b #10,d0
fd0: 0000 031e ori.b #30,d0
fd4: 0000 0330 ori.b #48,d0
fd8: 0000 0342 ori.b #66,d0
fdc: 0000 0354 ori.b #84,d0
Debug:
00001c48 00001c48 <__FuncTable__>:
1c48: 0000 0001 ori.b #1,d0
1c4c: ffff .short 0xffff
1c4e: ffff .short 0xffff
1c50: 0000 0000 ori.b #0,d0
1c54: 0000 1a26 ori.b #38,d0
1c58: 0000 0062 ori.b #98,d0
1c5c: 0000 1c0e ori.b #14,d0
1c60: 0000 004e ori.b #78,d0
1c64: 0000 0000 ori.b #0,d0
1c68: 0000 0070 ori.b #112,d0
1c6c: 0000 0052 ori.b #82,d0
1c70: 0000 0008 ori.b #8,d0
1c74: 0000 0004 ori.b #4,d0
1c78: 0000 0276 ori.b #118,d0
1c7c: 0000 0288 ori.b #-120,d0
1c80: 0000 02a6 ori.b #-90,d0
1c84: 0000 02c0 ori.b #-64,d0
1c88: 0000 02d2 ori.b #-46,d0
1c8c: 0000 02e4 ori.b #-28,d0
1c90: 0000 02f6 ori.b #-10,d0
1c94: 0000 0308 ori.b #8,d0
1c98: 0000 031a ori.b #26,d0
1c9c: 0000 032e ori.b #46,d0
1ca0: 0000 0340 ori.b #64,d0
1ca4: 0000 0352 ori.b #82,d0
1ca8: 0000 0364 ori.b #100,d0
1cac: 0000 184a ori.b #74,d0
1cb0: 0000 0062 ori.b #98,d0
1cb4: 0000 1bd8 ori.b #-40,d0
1cb8: 0000 004e ori.b #78,d0
How can this be explained? Also, shouldn't the list be -1 terminated?
doomsound_midi.library builds the function table this way:
ADDTABL_1(Forward_Sfx_SetVol, d0); /* One Argument in d0 */
ADDTABL_6(Forward_Sfx_Start, a0, d0, d1, d2, d3, d4);
ADDTABL_4(Forward_Sfx_Update, d0, d1, d2, d3);
ADDTABL_1(Forward_Sfx_Stop, d0);
ADDTABL_1(Forward_Sfx_Done, d0);
ADDTABL_1(CAMD_Mus_SetVol, d0);
ADDTABL_1(CAMD_Mus_Register, a0);
ADDTABL_1(CAMD_Mus_Unregister, d0);
ADDTABL_2(CAMD_Mus_Play, d0, d1);
ADDTABL_1(CAMD_Mus_Stop, d0);
ADDTABL_1(CAMD_Mus_Pause, d0);
ADDTABL_1(CAMD_Mus_Resume, d0);
ADDTABL_1(CAMD_Mus_Done, d0);
ADDTABL_END();
Oh, and I moved the midi stuff into its own repo now: https://github.com/mheyer32/camd_tools
Actually, I need clarification: is libnix code allowed inside a library? How do INIT_LIST and EXIT_LIST interact with libraries?
The reason why debug and release FuncTable look different, is because it looks like what was supposed to go into EXITLIST and INIT_LIST got stuffed into FuncTable__ (or maybe objdump is screwed up?):
1c48: 0000 0001 ori.b #1,d0
1c4c: ffff .short 0xffff
1c4e: ffff .short 0xffff I believe this is the library vector start as -1 , marking the entries as "relative ", but then the offsets down below would need to be different... OR it is a misplaced end marker for the library offset table?
1c50: 0000 0000 ori.b #0,d0 start of __EXIT_LIST__
1c54: 0000 1a26 ori.b #38,d0 __exitstdio
1c58: 0000 0062 ori.b #98,d0 prio
1c5c: 0000 1c0e ori.b #14,d0 __exitmalloc
1c60: 0000 004e ori.b #78,d0 prio
1c64: 0000 0000 ori.b #0,d0 end of list
1c68: 0000 0070 ori.b #112,d0 LibOpen
1c6c: 0000 0052 ori.b #82,d0 LibClose
1c70: 0000 0008 ori.b #8,d0 LibExpunge
1c74: 0000 0004 ori.b #4,d0 LibExtFunc
1c78: 0000 0276 ori.b #118,d0 Actual library functions
1c7c: 0000 0288 ori.b #-120,d0
1c80: 0000 02a6 ori.b #-90,d0
1c84: 0000 02c0 ori.b #-64,d0
1c88: 0000 02d2 ori.b #-46,d0
1c8c: 0000 02e4 ori.b #-28,d0
1c90: 0000 02f6 ori.b #-10,d0
1c94: 0000 0308 ori.b #8,d0
1c98: 0000 031a ori.b #26,d0
1c9c: 0000 032e ori.b #46,d0
1ca0: 0000 0340 ori.b #64,d0
1ca4: 0000 0352 ori.b #82,d0
1ca8: 0000 0364 ori.b #100,d0
(observe no -1 end marker)
1cac: 0000 184a ori.b #74,d0 __initstdio
1cb0: 0000 0062 ori.b #98,d0 prio
1cb4: 0000 1bd8 ori.b #-40,d0 __initmalloc
1cb8: 0000 004e ori.b #78,d0 prio
(no terminator)
The release functable doesn't look much better, though:
00000f8c 00000f8c <__FuncTable__>:
f8c: 0000 0001 ori.b #1,d0 idk...
f90: ffff .short 0xffff
f92: ffff .short 0xffff start of vectors? or misplaced end of vectors?
f94: 0000 0000 ori.b #0,d0 Are these empty __INIT_LISTS and __EXIT_LIST__?
f98: 0000 0000 ori.b #0,d0
f9c: 0000 0070 ori.b #112,d0 LibOpen
fa0: 0000 0052 ori.b #82,d0 LibClose etc
fa4: 0000 0008 ori.b #8,d0
fa8: 0000 0004 ori.b #4,d0
fac: 0000 0266 ori.b #102,d0
fb0: 0000 0278 ori.b #120,d0
fb4: 0000 0296 ori.b #-106,d0
fb8: 0000 02b0 ori.b #-80,d0
fbc: 0000 02c2 ori.b #-62,d0
fc0: 0000 02d4 ori.b #-44,d0
fc4: 0000 02e6 ori.b #-26,d0
fc8: 0000 02f8 ori.b #-8,d0
fcc: 0000 030a ori.b #10,d0
fd0: 0000 031e ori.b #30,d0
fd4: 0000 0330 ori.b #48,d0
fd8: 0000 0342 ori.b #66,d0
fdc: 0000 0354 ori.b #84,d0
Is it possible the ADDTABL_END() macro in stabs.h is hosed?
#define ADDTABL_END() asm(".stabs \"___FuncTable__\",20,0,0,-1")
Isn't this supposed to use sections, too?
In fact, replacing it with
#define ADDTABL_END() asm(".section\t.list_" "__FuncTable__" ",\"aw\""); \
asm("\t.long -1"); \
asm(".text")
produces a"sane" FuncTable:
release (no stdlib used):
00000f8c 00000f8c <__FuncTable__>:
f8c: 0000 0000 ori.b #0,d0
f90: 0000 0070 ori.b #112,d0
f94: 0000 0052 ori.b #82,d0
f98: 0000 0008 ori.b #8,d0
f9c: 0000 0004 ori.b #4,d0
fa0: 0000 0266 ori.b #102,d0
fa4: 0000 0278 ori.b #120,d0
fa8: 0000 0296 ori.b #-106,d0
fac: 0000 02b0 ori.b #-80,d0
fb0: 0000 02c2 ori.b #-62,d0
fb4: 0000 02d4 ori.b #-44,d0
fb8: 0000 02e6 ori.b #-26,d0
fbc: 0000 02f8 ori.b #-8,d0
fc0: 0000 030a ori.b #10,d0
fc4: 0000 031e ori.b #30,d0
fc8: 0000 0330 ori.b #48,d0
fcc: 0000 0342 ori.b #66,d0
fd0: 0000 0354 ori.b #84,d0
fd4: ffff .short 0xffff
fd6: ffff .short 0xffff // yay!
debug (uses some printf stuff and maybe assert())
00001c58 00001c58 <__FuncTable__>:
1c58: 0000 0000 ori.b #0,d0
1c5c: 0000 0070 ori.b #112,d0
1c60: 0000 0052 ori.b #82,d0
1c64: 0000 0008 ori.b #8,d0
1c68: 0000 0004 ori.b #4,d0
1c6c: 0000 0276 ori.b #118,d0
1c70: 0000 0288 ori.b #-120,d0
1c74: 0000 02a6 ori.b #-90,d0
1c78: 0000 02c0 ori.b #-64,d0
1c7c: 0000 02d2 ori.b #-46,d0
1c80: 0000 02e4 ori.b #-28,d0
1c84: 0000 02f6 ori.b #-10,d0
1c88: 0000 0308 ori.b #8,d0
1c8c: 0000 031a ori.b #26,d0
1c90: 0000 032e ori.b #46,d0
1c94: 0000 0340 ori.b #64,d0
1c98: 0000 0352 ori.b #82,d0
1c9c: 0000 0364 ori.b #100,d0
1ca0: 0000 184a ori.b #74,d0 __initstdio Ugghh! how come __FuncTable_ and __INIT_LIST get mushed together??
1ca4: 0000 0062 ori.b #98,d0 prio
1ca8: 0000 1bd8 ori.b #-40,d0 __initmalloc
1cac: 0000 004e ori.b #78,d0 prio
1cb0: ffff .short 0xffff
1cb2: ffff .short 0xffff vector table endmarker
Placing
__attribute__((section(".list___INIT_LIST__")))
long __INIT_LIST__[] = {0};
__attribute__((section(".list___EXIT_LIST__")))
long __EXIT_LIST__[] = {0};
__attribute__((section(".list___ZZZZ__")))
long __ZZZZ__[] = {0};
At the end of libinit.c results again in a broken vector table. The luck is here that the endmarker is in reasonable reach of the end of the table and as long as nobody attempts to call the "extranoues" library offsets, noone will notice that the table contains these extra, but broken function pointers.
00001c48 00001c48 <__EXIT_LIST__>:
1c48: 0000 0000 ori.b #0,d0
1c4c: 0000 1a26 ori.b #38,d0
1c50: 0000 0062 ori.b #98,d0
1c54: 0000 1c0e ori.b #14,d0
1c58: 0000 004e ori.b #78,d0
00001c5c 00001c5c <__FuncTable__>:
1c5c: 0000 0000 ori.b #0,d0
1c60: 0000 0070 ori.b #112,d0
1c64: 0000 0052 ori.b #82,d0
1c68: 0000 0008 ori.b #8,d0
1c6c: 0000 0004 ori.b #4,d0
1c70: 0000 0276 ori.b #118,d0
1c74: 0000 0288 ori.b #-120,d0
1c78: 0000 02a6 ori.b #-90,d0
1c7c: 0000 02c0 ori.b #-64,d0
1c80: 0000 02d2 ori.b #-46,d0
1c84: 0000 02e4 ori.b #-28,d0
1c88: 0000 02f6 ori.b #-10,d0
1c8c: 0000 0308 ori.b #8,d0
1c90: 0000 031a ori.b #26,d0
1c94: 0000 032e ori.b #46,d0
1c98: 0000 0340 ori.b #64,d0
1c9c: 0000 0352 ori.b #82,d0
1ca0: 0000 0364 ori.b #100,d0
00001ca4 00001ca4 <__INIT_LIST__>:
1ca4: 0000 0000 ori.b #0,d0
1ca8: 0000 184a ori.b #74,d0
1cac: 0000 0062 ori.b #98,d0
1cb0: 0000 1bd8 ori.b #-40,d0
1cb4: 0000 004e ori.b #78,d0
00001cb8 00001cb8 <__ZZZZ__>:
1cb8: 0000 0000 ori.b #0,d0
1cbc: ffff .short 0xffff <<<<<<<< misplaced vector table endmarker
1cbe: ffff .short 0xffff
By fixing ADDTABL_END, ADD2LIST macros in stabs.h and changing the FuncTable to be placed into section .dlist___FuncTable I was able to separate out FuncTable and the init/exit lists. But TBH, I don't know what I'm doing here and if that is a preferable solution. One thing that is for sure is that this forces libraries to always have a data section even if they don't need it.
Hm, I don't have any of your local changes and do get
00000fdc 00000fdc ___FuncTable__:
fdc: 0000 0000 ori.b #0,d0
fe0: 0000 004e ori.b #78,d0
fe4: 0000 001e ori.b #30,d0
fe8: 0000 0008 ori.b #8,d0
fec: 0000 0004 ori.b #4,d0
ff0: 0000 0286 ori.b #-122,d0
ff4: 0000 0298 ori.b #-104,d0
ff8: 0000 02b6 ori.b #-74,d0
ffc: 0000 02d0 ori.b #-48,d0
1000: 0000 02e2 ori.b #-30,d0
1004: 0000 02f4 ori.b #-12,d0
1008: 0000 0306 ori.b #6,d0
100c: 0000 0318 ori.b #24,d0
1010: 0000 032a ori.b #42,d0
1014: 0000 033e ori.b #62,d0
1018: 0000 0350 ori.b #80,d0
101c: 0000 0362 ori.b #98,d0
1020: 0000 0374 ori.b #116,d0
1024: ffff .short 0xffff
1026: ffff .short 0xffff
By fixing ADDTABL_END, ADD2LIST macros in stabs.h and changing the FuncTable to be placed into section .dlist___FuncTable I was able to separate out FuncTable and the init/exit lists. But TBH, I don't know what I'm doing here and if that is a preferable solution. One thing that is for sure is that this forces libraries to always have a data section even if they don't need it.
and ___Functable__
is in .text
libinit.c
__attribute__((section(".list___FuncTable__")))
APTR __FuncTable__[] = {0};
stabs.h:
#define ADDTABL_END() asm(".stabs \"___FuncTable__\",20,0,0,-1") <<< broken
/* add symbol a to list b (c unused) */
#define ADD2LIST(a,b,c) \
asm(".section\t.list_" #b ",\"aw\""); \
asm("\t.long _" #a); \
asm(".text");
#define ADD2LIST2(a,b,c) \
asm(".section\t.list_" #b ",\"aw\""); \
asm("\t.long " #a); \
asm(".text");
try building doomsound_midi.library in debug mode:
make -j8 -B DEBUG=1 doomsound_midi.library
Btw, how does stabs.h get generated? Where does it come from?
stabs.h is a general header and thus is provided by newlib.
m68k-amigaos-gcc -noixemul -DUSENOIXEMUL -fbaserel -m68020-60 -mtune=68030 -msmall-code -mregparm=4 -msoft-float -Werror -Wimplicit -Wstrict-prototypes -Wdouble-promotion -fstrict-aliasing -g -ggdb -DDEBUG -Og -ffast-math -fno-omit-frame-pointer -D__BIG_ENDIAN__ -DNORMALUNIX -DAMIGA -Diabs=abs -D__NO_NET_API -DINDIVISION -include "amiga_macros.h" -I./ -ramiga-lib -fbaserel -o doomsound_midi.library doomsound_midi.c musplay.c exit.s
yields:
00001494 00001494 ___FuncTable__:
1494: 0000 0000 ori.b #0,d0
1498: 0000 004e ori.b #78,d0
1498: RELOC32 _LibOpen
149c: 0000 001e ori.b #30,d0
149c: RELOC32 _LibClose
14a0: 0000 0008 ori.b #8,d0
14a0: RELOC32 _LibExpunge
14a4: 0000 0004 ori.b #4,d0
14a4: RELOC32 _LibExtFunc
14a8: 0000 0296 ori.b #-106,d0
14a8: RELOC32 _____Sfx_SetVol
14ac: 0000 02a8 ori.b #-88,d0
14ac: RELOC32 _____Sfx_Start
14b0: 0000 02c6 ori.b #-58,d0
14b0: RELOC32 _____Sfx_Update
14b4: 0000 02e0 ori.b #-32,d0
14b4: RELOC32 _____Sfx_Stop
14b8: 0000 02f2 ori.b #-14,d0
14b8: RELOC32 _____Sfx_Done
14bc: 0000 0304 ori.b #4,d0
14bc: RELOC32 _____Mus_SetVol
14c0: 0000 0316 ori.b #22,d0
14c0: RELOC32 _____Mus_Register
14c4: 0000 0328 ori.b #40,d0
14c4: RELOC32 _____Mus_Unregister
14c8: 0000 033a ori.b #58,d0
14c8: RELOC32 _____Mus_Play
14cc: 0000 034e ori.b #78,d0
14cc: RELOC32 _____Mus_Stop
14d0: 0000 0360 ori.b #96,d0
14d0: RELOC32 _____Mus_Pause
14d4: 0000 0372 ori.b #114,d0
14d4: RELOC32 _____Mus_Resume
14d8: 0000 0384 ori.b #-124,d0
14d8: RELOC32 _____Mus_Done
14dc: ffff .short 0xffff
14de: ffff .short 0xffff
exit.s:
_exit: .globl _exit
rts
and I removed stdio usage from raise/abort in libnix.
Somewhere there's a disconnect between us. I can't reproduce the vector table as you're showing up there. I just rebuilt the whole toolchain, nuking the source directory and the output directory.
Check out https://github.com/mheyer32/camd_tools
build it via
make -j8 -B doomsound_midi.library
or make -j8 -B doomsound_midi.library DEBUG=1
then check the output of
m68k-amigaos-objdump -m68020-60 -d -C -S doomsound_midi.library
Right now this yields:
00000fa4 00000fa4 <__FuncTable__>:
fa4: 0000 0001 ori.b #1,d0
fa8: ffff .short 0xffff ??
faa: ffff .short 0xffff ??
fac: 0000 0000 ori.b #0,d0 ??
fb0: 0000 0000 ori.b #0,d0 ??
fb4: 0000 0070 ori.b #112,d0
fe0: 0000 02f8 ori.b #-8,d0
fe4: 0000 030a ori.b #10,d0
fe8: 0000 031e ori.b #30,d0
fec: 0000 0330 ori.b #48,d0
ff0: 0000 0342 ori.b #66,d0
ff4: 0000 0354 ori.b #84,d0
(Also, in the DEBUG build, its still asking for a missing symbol)
m68k-amigaos-gcc -noixemul -DUSENOIXEMUL -fbaserel -m68020-60 -mtune=68030 -msmall-code -mregparm=4 -msoft-float -Werror -Wimplicit -Wstrict-prototypes -Wdouble-promotion -fstrict-aliasing -g -ggdb -DDEBUG -Og -ffast-math -fno-omit-frame-pointer -D__BIG_ENDIAN__ -I./ -flto -ramiga-lib -fbaserel -o doomsound_midi.library doomsound_midi.c musplay.c exit.s
/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld: /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/libb/libm020/libnix20.a(__initstdio.o): in function `__initstdio':
__initstdio.o:(.text+0x284): undefined reference to `_WBenchMsg'
collect2: fatal error: ld returned 1 exit status
I can probably define that myself.
I see, made a new VM:
CONSTRUCTORS
0x0000000000000f90 . = ALIGN (0x4)
0x0000000000000f90 ___FuncTable__ = .
0x0000000000000f90 0x4 LONG 0x1
0x0000000000000f94 0x4 LONG 0xffffffff *ABS*+0xffffffff
0x0000000000000f98 0x4 LONG 0x0
it seems that fautomat
did not update newlib
... grrr
please run make update
and sorry for the buzz... have to fix the publish script (again^^)
Yes, that did the trick! I'm getting a clean FuncTable now. I think, prior the ADDTABL_END() had just not been updated and thus all my problems...
Which brings me to the next question: libinit.c doesn't handle INIT_LIST/EXIT_LIST on its own. Yes, I know, in this particular case of doomsound_midi.library there's no need for a clib environment. But supposed I do want to use libnix functionality like malloc and file I/O from a library, what is the proper way to do it? I think there might be some hurdles, like stdout having nowhere to go... can libnix deal with that?
the disasm looks nicer soon;
00001494 00001494 ___FuncTable__:
1494: 0000 0000 .long 0x00000000
1498: 0000 004e .long _LibOpen
1498: RELOC32 .text
149c: 0000 001e .long _LibClose
149c: RELOC32 .text
14a0: 0000 0008 .long _LibExpunge
14a0: RELOC32 .text
14a4: 0000 0004 .long _LibExtFunc
14a4: RELOC32 .text
14a8: 0000 0296 .long _____Sfx_SetVol
14a8: RELOC32 .text
14ac: 0000 02a8 .long _____Sfx_Start
14ac: RELOC32 .text
14b0: 0000 02c6 .long _____Sfx_Update
14b0: RELOC32 .text
14b4: 0000 02e0 .long _____Sfx_Stop
14b4: RELOC32 .text
14b8: 0000 02f2 .long _____Sfx_Done
14b8: RELOC32 .text
14bc: 0000 0304 .long _____Mus_SetVol
14bc: RELOC32 .text
14c0: 0000 0316 .long _____Mus_Register
14c0: RELOC32 .text
14c4: 0000 0328 .long _____Mus_Unregister
14c4: RELOC32 .text
14c8: 0000 033a .long _____Mus_Play
14c8: RELOC32 .text
14cc: 0000 034e .long _____Mus_Stop
14cc: RELOC32 .text
14d0: 0000 0360 .long _____Mus_Pause
14d0: RELOC32 .text
14d4: 0000 0372 .long _____Mus_Resume
14d4: RELOC32 .text
14d8: 0000 0384 .long _____Mus_Done
14d8: RELOC32 .text
14dc: ffff .short 0xffff
14de: ffff .short 0xffff
Which brings me to the next question: libinit.c doesn't handle INIT_LIST/EXIT_LIST on its own. Yes, I know, in this particular case of doomsound_midi.library there's no need for a clib environment. But supposed I do want to use libnix functionality like malloc and file I/O from a library, what is the proper way to do it? I think there might be some hurdles, like stdout having nowhere to go... can libnix deal with that?
I don't think there is a good standard way to call all that init stuff. The I/O will be attached to the (first) task opening the library... To enable a behaviour like this, ixemul was created once, where all libraries do share and reference the ixemul.library... ... maybe it's time to revive that?
Thank you!
Thanks for upping the disassembly once more! Very useful!
Thanks for upping the disassembly once more! Very useful!
have you tried -NL
?
I did try -NL just now, but it crashed:
m68k-amigaos-objdump -m68020-60 -d -C -S -NL ADoom > ADoom.asm
pass 1:pass 2: 4/1530
pass 3: 2/1531
pass 4:pass 5: 1/1531
pass 6:pass 7: 1600/1675 1794/1828 274/1848
pass 8: 1849/1920 139/1921
pass 9: 29/1933
pass 10: 2/1933
pass 11:pass 12: 6/1941
pass 13: 2/1941
pass 14:pass 15: 51/2001
pass 16: 9/2001
pass 17:pass 18: 6/2008
pass 19: 1/2008
pass 20:pass 21: 4/2014
pass 22: 1/2014
pass 23:pass 24: 7/2021
pass 25: 2/2021
pass 26:pass 27: 2/2023
pass 28:pass 29: 2/2025
pass 30:pass 31: 5/2032
pass 32:pass 33: 13/2046
pass 34: 2/2046
pass 35:pass 36: 4/2049
pass 37:pass 38: 4/2052
pass 39:pass 40: 38/2105
pass 41: 88/2208
pass 42: 23/2208
pass 43:pass 44: 1/2208
pass 45:pass 46: 1/2208
pass 47:pass 48: 1/2208
pass 49:pass 50: 1/2208
pass 51:pass 52: 16/2223
pass 53:pass 54: 2/2225
pass 55: 1/2225
pass 56:pass 57: 3/2228
pass 58: 1/2228
pass 59:pass 60: 2/2229
pass 61:pass 62: 2/2230
pass 63:pass 64: 2/2231
pass 65:pass 66: 2/2232
pass 67:pass 68: 2183/2447 151/2471
pass 69: 57/2528
pass 70: 19/2547
pass 71: 6/2547
pass 72:pass 73: 5/2559
pass 74: 3/2559
pass 75:pass 76: 1/2559
pass 77:pass 78: 1/2559
pass 79:pass 80: 1/2559
pass 81:pass 82: 1/2559
pass 83:pass 84: 3/2561
pass 85:pass 86: 5/2573
pass 87: 2/2573
pass 88:pass 89: 4/2577
pass 90: 1/2577
pass 91:pass 92: 8/2588
pass 93: 3/2588
pass 94:pass 95: 21/2625
pass 96: 7/2627
pass 97:pass 98: 3/2631
pass 99: 1/2631
pass 100:pass 101: 8/2640
pass 102: 1/2640
pass 103:pass 104: 16/2655
pass 105:pass 106: 24/2678
pass 107: 1/2678
pass 108:pass 109: 16/2697
pass 110: 11/2703
pass 111: 1/2703
pass 112:pass 113: 4/2706
pass 114:pass 115: 20/2724
pass 116:pass 117: 3/2726
pass 118:pass 119: 49/2774
pass 120: 16/2786
pass 121: 2/2786
pass 122:pass 123: 1838/3053 2879/3201 263/3206
pass 124: 1990/3338 2286/3480 2781/3616 3131/3744 577/3807
pass 125: 1725/3964 2301/4079 2778/4211 3147/4359 3563/4485 3815/4622 4105/4780 986/4887
pass 126: 1871/5007 2962/5097 3439/5194 4193/5284 632/5361
pass 127: 3825/5441 216/5500
pass 128: 97/5581
pass 129: 86/5665
pass 130: 18/5665
pass 131:pass 132: 10/5676
pass 133: 2/5676
pass 134:pass 135: 1/5676
pass 136:pass 137: 1/5676
pass 138:pass 139: 13/5690
pass 140: 1/5690
pass 141:pass 142: 13/5705
pass 143: 4/5705
pass 144:pass 145: 67/5799
pass 146: 33/5803
pass 147: 1/5803
pass 148:pass 149: 2/5805
pass 150:pass 151: 5/5810
pass 152: 1/5810
pass 153:pass 154: 5/5815
pass 155:pass 156: 5/5820
pass 157:pass 158: 3/5822
pass 159:pass 160: 2/5824
pass 161:pass 162: 6/5829
pass 163:pass 164: 6/5835
pass 165: 1/5835
pass 166:pass 167: 3/5837
pass 168:pass 169: 5/5841
pass 170:pass 171: 5/5848
pass 172: 3/5848
pass 173:pass 174: 5/5855
pass 175: 3/5855
pass 176:pass 177: 4/5860
pass 178: 9/5868
pass 179: 1/5868
pass 180:pass 181: 7/5877
pass 182:pass 183: 2/5879
pass 184: 1/5879
pass 185:pass 186: 3/5883
pass 187:pass 188: 2/5884
pass 189:pass 190: 5/5890
pass 191:pass 192: 3/5895
pass 193: 1/5895
pass 194:pass 195: 7/5906
pass 196: 1/5906
pass 197:pass 198: 1/5907
pass 199:pass 200: 1/5909
pass 201:pass 202: 1/5910
pass 203:pass 204: 2/5911
pass 205:pass 206: 2/5914
pass 207: 1/5914
pass 208:pass 209: 4/5919
pass 210:pass 211: 1/5920
pass 212:pass 213: 1/5921
pass 214:pass 215: 1/5922
pass 216:pass 217: 7/5929
pass 218: 1/5929
pass 219:pass 220: 5/5934
pass 221: 1/5934
pass 222:pass 223: 3/5936
pass 224:pass 225: 31/5973
pass 226: 9/5973
pass 227:pass 228: 20/5995
pass 229: 7/5996
pass 230:pass 231: 3/5998
pass 232:pass 233: 13/6014
pass 234: 3/6014
pass 235:pass 236: 20/6038
pass 237: 3/6038
pass 238:pass 239: 18/6059
pass 240: 1/6059
pass 241:pass 242: 1/6059
pass 243:pass 244: 1/6059
pass 245:pass 246: 12/6072
pass 247: 3/6072
pass 248:pass 249: 7/6078
pass 250: 6/6083
pass 251: 12/6095
pass 252: 5/6096
pass 253:pass 254: 8/6106
pass 255: 3/6106
pass 256:pass 257: 31/6142
pass 258: 7/6142
pass 259:pass 260: 2/6143
pass 261:pass 262: 23/6170
pass 263: 4/6170
pass 264:pass 265: 6/6177
pass 266: 2/6177
pass 267:pass 268: 6/6181
pass 269:pass 270: 11/6195
pass 271: 4/6195
pass 272:pass 273: 18/6218
pass 274: 6/6218
pass 275:pass 276: 2/6219
pass 277:pass 278: 5/6221
pass 279:pass 280: 3/6223
pass 281:pass 282: 2/6224
pass 283:pass 284: 3/6227
pass 285: 1/6227
pass 286:pass 287: 3/6230
pass 288: 1/6230
pass 289:pass 290: 6/6234
pass 291: 3/6237
pass 292: 4/6240
pass 293: 1/6240
pass 294:pass 295: 26/6267
pass 296: 18/6285
pass 297: 5/6285
pass 298:pass 299: 2/6286
pass 300:pass 301: 3/6288
pass 302:pass 303: 2/6289
pass 304:pass 305: 4/6292
pass 306:pass 307: 2/6293
pass 308:pass 309: 11/6306
pass 310: 4/6306
pass 311:pass 312: 2/6307
pass 313:pass 314: 2/6308
pass 315:pass 316: 2/6309
pass 317:pass 318: 4/6313
pass 319: 1/6314
pass 320: 2/6315
pass 321:pass 322: 3/6316
pass 323:pass 324: 1/6316
pass 325:pass 326: 2/6317
pass 327:pass 328: 4/6320
pass 329: 2/6322
pass 330: 1/6322
pass 331:pass 332: 1/6322
pass 333:pass 334: 1/6322
pass 335:pass 336: 1/6322
pass 337:pass 338: 1/6322
pass 339:pass 340: 3/6324
pass 341:pass 342: 6/6329
pass 343:pass 344: 2/6330
pass 345:pass 346: 1/6330
pass 347:pass 348: 7/6337
pass 349: 1/6337
pass 350:pass 351: 60/6403
pass 352: 12/6403
pass 353:pass 354: 1/6403
pass 355:pass 356: 1/6403
pass 357:pass 358: 1/6403
pass 359:pass 360: 3/6404
pass 361: 14/6417
pass 362: 1/6417
pass 363:pass 364: 3/6420
pass 365: 1/6420
pass 366:pass 367: 3/6424
pass 368: 2/6424
pass 369:pass 370: 2/6426
pass 371: 1/6426
pass 372:pass 373: 2/6427
pass 374:pass 375: 7/6432
pass 376: 2/6435
pass 377: 2/6435
pass 378:pass 379: 5/6440
pass 380: 1/6440
pass 381:pass 382: 7/6449
pass 383: 3/6449
pass 384:pass 385: 12/6463
pass 386: 2/6463
pass 387:pass 388: 8/6472
pass 389: 2/6472
pass 390:pass 391: 2/6473
pass 392:pass 393: 59/6572
pass 394: 2/6572
pass 395:pass 396: 3/6575
pass 397: 1/6575
pass 398:pass 399: 4/6578
pass 400: 1/6578
pass 401:pass 402: 3/6581
pass 403: 1/6581
pass 404:pass 405: 1/6581
pass 406:pass 407: 3/6583
pass 408:pass 409: 3/6585
pass 410:pass 411: 2/6587
pass 412: 1/6587
pass 413:pass 414: 5/6593
pass 415: 2/6593
pass 416:pass 417: 6/6600
pass 418: 2/6600
pass 419:pass 420: 3/6603
pass 421: 1/6603
pass 422:pass 423: 1/6603
pass 424:pass 425: 3/6605
pass 426:pass 427: 13/6620
pass 428: 4/6620
pass 429:pass 430: 11/6632
pass 431: 2/6632
pass 432:pass 433: 2/6634
pass 434: 1/6634
pass 435:pass 436: 6/6640
pass 437: 1/6640
pass 438:pass 439: 6/6648
pass 440: 2/6648
pass 441:pass 442: 7/6660
pass 443: 6/6660
pass 444:pass 445: 9/6672
pass 446: 4/6672
pass 447:pass 448: 29/6707
pass 449: 30/6731
pass 450: 5/6731
pass 451:pass 452: 3/6734
pass 453: 1/6734
pass 454:pass 455: 3/6736
pass 456:pass 457: 4/6739
pass 458:pass 459: 6/6746
pass 460: 2/6746
pass 461:pass 462: 1/6746
pass 463:pass 464: 2/6747
pass 465:pass 466: 5/6754
pass 467: 3/6754
pass 468:pass 469: 3/6757
pass 470: 1/6757
pass 471:pass 472: 12/6771
pass 473: 3/6771
pass 474:pass 475: 3/6773
pass 476:pass 477: 1/6773
pass 478:pass 479: 8/6781
pass 480: 1/6781
pass 481:pass 482: 1/6781
pass 483:pass 484: 3/6783
pass 485:pass 486: 5/6790
pass 487: 3/6790
pass 488:pass 489: 5/6793
pass 490:pass 491: 2/6794
pass 492:pass 493: 2/6795
pass 494:pass 495: 1/6795
pass 496:pass 497: 2/6796
pass 498:pass 499: 2/6797
pass 500:pass 501: 2/6798
pass 502:pass 503: 4/6801
pass 504:pass 505: 6/6807
pass 506: 1/6807
pass 507:pass 508: 16/6824
pass 509: 2/6824
pass 510:pass 511: 13/6838
pass 512: 2/6838
pass 513:pass 514: 3/6840
pass 515:pass 516: 5/6846
pass 517: 2/6846
pass 518:pass 519: 8/6856
pass 520: 3/6856
pass 521:pass 522: 1/6856
pass 523:pass 524: 3/6858
pass 525:pass 526: 3/6860
pass 527:pass 528: 11/6872
pass 529: 2/6872
pass 530:pass 531: 6/6879
pass 532: 2/6879
pass 533:pass 534: 2/6881
pass 535: 1/6881
pass 536:pass 537: 1/6881
pass 538:pass 539: 2/6883
pass 540: 1/6883
pass 541:pass 542: 2/6885
pass 543: 1/6885
pass 544:pass 545: 7/6897
pass 546:pass 547: 6/6905
pass 548:pass 549: 14/6919
pass 550:pass 551: 6/6925
pass 552: 1/6925
pass 553:pass 554: 4/6933
pass 555: 1/6933
pass 556:pass 557: 2/6934
pass 558:pass 559: 5/6941
pass 560: 3/6941
pass 561:pass 562: 1/6941
pass 563:pass 564: 17/6963
pass 565: 6/6963
pass 566:pass 567: 6/6968
pass 568:pass 569: 4/6971
pass 570:pass 571: 2/6973
pass 572: 1/6973
pass 573:pass 574: 7/6982
pass 575: 2/6983
pass 576:pass 577: 4/6987
pass 578: 1/6987
pass 579:pass 580: 1/6987
pass 581:pass 582: 2/6989
pass 583: 1/6989
pass 584:pass 585: 4/6992
pass 586:pass 587: 1/6992
pass 588:pass 589: 1/6992
pass 590:pass 591: 1/6992
pass 592:pass 593: 1/6992
pass 594:pass 595: 8/7002
pass 596: 3/7002
pass 597:pass 598: 3/7005
pass 599: 1/7005
pass 600:pass 601: 3/7008
pass 602: 1/7008
pass 603:pass 604: 0/7008
*** buffer overflow detected ***: terminated
This may be related to #58
ADoom builds a library named doomsound_midi.library which implements the same interface as doomsound.library, but is re-routing the music playback to MIDI (while forwarding the SFX to the original doomsound.library).
This library had been working for years now, but it now seems to be broken. When loading the library, ADoom will consistently crash with various Gurus.. From looking at SnoopDos I can infer that it at least makes it through __UserLibInit https://github.com/mheyer32/ADoom/blob/master/adoom_src/doomsound_midi.c#L78
I don't see anything sticking out in the disassembly and bgdbserver won't help me either as it can't debug across library calls.
I'm open to the idea that I'm doing something wrong that now got tickled, but my hunch is that somehow the magic fairy dust in the linker/libnix that glues together a library into the right structure got broken.