Anyone know what this means and how it can be fixed?
ppc-amigaos-gcc -Wall -g -O2 -use-dynld -o mpeg2desc mpeg2desc.o compat.o
mpeg2desc.o: In function `process_packets':
/home/salass00/Development/Projects/Shell/dvdauthor/src/mpeg2desc.c:340: undefined reference to `__trampoline_setup'
collect2: ld returned 1 exit status
Never meet it, but via google found that link. Maybe can help (at least code have some comment at top, which sounds understanable):
Maybe just reusing that small ppc code from will be fine ?
I got rid of the undefined reference by compiling and linking mpeg2desc with the following modified trampoline_setup.c file:
I don't know if this works as a replacement though.
I must say this looks pretty bad. Why is mpeg2desc using self modified code on PPC of all things? Does it do the same for x86?
That's very nice when speeding things up but I don't see any core optimisations here, just an ASM hack to call a function. Why can't mpeg2desc do it in normal C functions calls? :-?
I'm resurrecting this thread because I've ran into this same problem again while updating the dvdauthor port to version 0.7.2.
Doing some googling I found mention of an ld option "--no-trampoline" so I tried adding "-Wl,--no-trampoline" to LDFLAGS. It didn't work, ld says the --no-trampoline option is unrecognised.
The mpeg2desc code is normal C code. The __trampoline_setup call is generated by the gcc compiler.
Also it's not self modifying code since the code is not modifying itself.
No mention of how to disable this feature though, or why it might not be working correctly with our gcc port.
Finally got mpeg2desc to compile by undefining HAVE_NESTED_ROUTINES in "config.h".
Apparently gcc has a non-standard extension called nested functions which means that you can have a function defined inside a function that will also have full access to all the local variables in the parent/surrounding function (useful for callback functions) and mpeg2desc was making use of this functionality.
Nested Procedures (functions) are common in Modula-2 and probably Oberon. However, it looks to me like setting up trampolines wouldn't be very effecient when in C you could just declare all the parent variables in a structure and pass the structure pointer to the sub-function. Maybe I'm just misunderstanding what trampolines are doing.
X1000 - OS 4.1FE
No doubt caused by those nested functions. Which I like the idea of since you can freely do it in ASM. But I still wonder why our GCC lacks the trampoline.
Okay technically not. But it still builds up a cache of instructions by hand so still a hack! :-D
Like on 68K the instruction cache would need flushing out. As part of ASM generated code in the assembler that would be fine. But it still looks dirty without using actual portable C code to do the operation.