STM32 weak exception handler override in ASM not working (ARM-EABI-GCC)

I'd decompose this further, but don't have the patience, suspect it is the .global and .type that are most critical

	.section	.text.SVC_Handler,"ax",%progbits
	.align	1
	.global	SVC_Handler
	.thumb
	.thumb_func
	.type	SVC_Handler, %function
SVC_Handler:
	.cfi_startproc
 
	bx	lr /* your code here */
 
	.cfi_endproc
	.size	SVC_Handler, .-SVC_Handler

Not working :(

Default SVC_Handler is being called.

Can it be because startup_stm32l496xx.s file and my ASM file are in different libraries (.a)?

Oh. Maybe order of libraries matter.

I can call function declared in ASM from C no problem so linker sees them fine. Just some bug with weak. Maybe it's a linker issue in ARM-EABI-GCC.

GCC v7.2

LD 2.29

> Can it be because startup_stm32l496xx.s file and my ASM file are in different libraries (.a)?

Linkers (including the GNU linker) treat libraries in a different way than they treat objects, even if the libraries appear to be only a collection of objects. This has both rational and historical reasons and I am yet to see a concise document outlining all the linker idiosyncrasies in historical context. One of the underlying (unwritten) idea is, that users are not supposed to create libraries, they are supposed to stick with objects, libraries are to be a domain of system creators. Nevertheless, users are often caught with unpleasant surprise when they move their objects into libraries to find that the result is quite different from what it used to be with standalone objects.

Here, in particular, the fact, that linkers don't search for symbols in libraries if they were already fulfilled, weak or not, is probably the surprising factor. The probable reason for this is the (unwritten, again, and with historic roots too) rule that you should be always able to override library functions with your own version (because of the potentially buggy library one); and the weak/strong mechanism is supposed to help resolving a similar problem entirely in the user (objects) domain.

Other such factor is that linkers don't iterate when searching for a symbol in libraries (unless forced to do so by some set of command-line switches), ie. if there's a new symbol found in the library (or, in a more rare case in an object linked *after* having linking libraries) it can't be fulfilled by a definition from a library linked earlier (but it can be fulfilled by a user definition, even if objects were liked earlier). The visible effect is, that library ordering in command line (and/or specs) does matter, and sometimes manual reordering or overriding specs-given ordering results in surprising faults.

So, the short answer is, don't make libraries from your objects, whatever good reason you think you might have for this.

JW