Create stub library/object from application code (ROM) using binutils for bare-metal ARM

I have some C code that is implemented in a ROM. I'd like to link an application against that code, so I can save some space (as my application won't have to include the ROM code as it's already in the ROM). My question is about how to do this in an efficient way. I'm using the GCC toolchain for ARM (arm-none-eabi-*)

The long explanation:

I'll quote Oracle's definition of a stub object:

A stub object is a shared object, built entirely from mapfiles, that supplies the same linking interface as the real object, while containing no code or data.

As a normal part of the linking process, we can link against libraries, either static or dynamic. As I'm using an embedded target with no MMU, I'm using static libraries. When linking against static libraries, the library code is copied to my final application image. In my problem here, I have code that is implemented in a ROM. I have the final binary and the map file of this ROM. What I want is to call this ROM code from my application, so I don't have to include it again.

So, let's say that I have the following code in ROM

int some_rom_function(void)
{
    // do something here, doesn't really matter what
}

I go to the map file and see that some_rom_function lives at 0x1234:

 .text.some_rom_function
                0x00001234       0x94 ./source/mysource.o
                0x00001234                some_rom_function

My current solution is to use a header with inline functions, like so:

#define SOME_ROM_FUNCTION_ADDR    0x00001234

static inline int some_rom_function(void)
{
    return (*((int (**)())SOME_ROM_FUNCTION_ADDR))();
}

So that in my application code I can just do

int main( void )
{
    some_rom_function();
}

My question is: is there a better way to do this, especially for a large application? Do I really have to manually go through every single function?

Can the binutils applications (ld, objcopy, etc, etc) be used to achieve the same result, assuming that I have the final binary (non-relocatable code)?

Caveats: 1. I do own the original ROM code. So I have access to the source, the final binary, and the map file.

2. The ROM has already been implemented. This means that it literally is written in stone (silicon in my case), so I can't change anything about the ROM itself.

Thanks!