#2331 ISR table not set up when compiling and linking manually

[Maarten]

If I define an ISR in a separate source file (other than the main file),
SDCC will not add it to the interrupt jump table.
SDCC should put at code address 0x23 a jump to uartISR.

main.c:

void main()
{
  while (1)
  {}
}

int.c:

void uartISR(void) __interrupt 4 __using 1
{
  return;
}

The following sequence of sdcc invocations fails to put a jump to the ISR:

sdcc -c main.c
sdcc -c int.c
sdld -n -mwux -i fail.ihx -Y -b HOME=0x0000 -b ISEG=0x0000 -M -b BSEG=0x0000 -k /usr/share/sdcc/lib/small -l mcs51 -l libsdcc -l libint -l liblong -l libfloat main.rel int.rel

The emitted code around the code address 0x23 is (no jump visible):

   0x001f 78 00    MOV   R0,#00
   0x0021 75 a0 00 MOV   P2,#00
   0x0024 e4       CLR   A
   0x0025 93       MOVC  A,@A+DPTR

The following sdcc invocation succeeds. Compile everything as one monolithic source.

cat main.c int.c > all.c
sdcc all.c -o all.ihx

The emitted code has a (correct) jump at code address 0x23:

   0x0020 66       XRL   A,@R0
   0x0021 32       RETI
 ? 0x0022 0d       INC   R5
 ? 0x0023 02 00 87 LJMP  0087
   0x0026 02 00 85 LJMP  0085
   0x0029 75 81 0f MOV   SP,#0f

One minor thing. The following segfaults.
(Caught signal 11: SIGSEGV)

cat main.c int.c > all.c
sdcc --c1mode -o segv.ihx < all.c

What are your suggestions?

Contact: anonymous.maarten at mailservice of google...

[Maarten Brock]

This is documented behavior. You need to provide at least the prototype when compiling the file containing main().

void uartISR(void) __interrupt (4);
void main()
{
  while (1)
  {}
}

[Maarten]

My apologies. The bug was in my code :).

[Anonymous]

Sorry, but even when this is documented behavior it's at least not what one would expect. If it's too hard to be fixed in the linker, is there any chance that a warning or error could be generated?

[Maarten Brock]

Who should warn?
The compiler when compiling main.c when it finds no interrupt 4?
The compiler when compiling int.c that you should not forget to put the prototype in main.c even if it is already there?
The linker when it finds no code for address 0x23?
What is the upper limit? Many derivatives have more than 20 interrupts.
What if there are no interrupts used at all in the application?
What if the application coexists with a bootloader so the interrupt table must be moved from 0x0000 to e.g. 0x1000? AFAIK the linker currently does not support relative offsets from the start of a segment area.

When it comes to interrupts and C there is little to expect. They are not described in the C specification. So the user should read the manual of the chosen tool, I guess.

[Anonymous]

Hi Maarten,
thank you for your reply. Ok, I see it's not solvable by the compiler.

Could the linker just place every function, that is declared to be an interrupt handler at the place it belongs according to the declaration?

cheers,
Torsten

[Maarten Brock]

The interrupt handlers cannot be placed in the vector table. There are only 8 bytes per handler available. That's why we use jumps in the table instead.

Now if the compiler were to generate this jump it would have to use .org to fix the jump to the right place. The downside of this is that an org statement is absolute and does not shift to a different address when requested by --code-loc. A solution could be a new "relative org" or "offset" directive.

The linker OTOH does not know which label belongs to an interrupt, let alone which. Further it is not the task of the linker to insert code.