How to force unused external routine declaration into object

I'm defining an external function in the IR that has no uses at all. No
calls, no address taken, nada.

Such an unused declaration seems to be just dropped on the floor as not
needed. Seems reasonable in most cases.

However, one of my OpenVMS compilers (BLISS) has a language rule that
expects such definitions to get into the ELF symbol table as a way to
compel the linker to include certain object modules.

With our backend for our older targets, we had a "required_om_entry"
function attribute that told our backend to put it out regardless.

I was looking at the list of function attributes and don't see anything
that would accomplish this.

I could just create a bogus variable and initialize it with the
function's value, but that seems unsavory.

I'm still using a way old version but I'll adapt as needed.

Any suggestions? Did I miss something?

John (safely at home with sufficient food & wine)

From: llvm-dev <llvm-dev-bounces@lists.llvm.org> On Behalf Of John Reagan
via llvm-dev
Sent: Wednesday, May 6, 2020 9:29 PM
To: via llvm-dev <llvm-dev@lists.llvm.org>
Subject: [llvm-dev] How to force unused external routine declaration into
object

I'm defining an external function in the IR that has no uses at all. No
calls, no address taken, nada.

Such an unused declaration seems to be just dropped on the floor as not
needed. Seems reasonable in most cases.

However, one of my OpenVMS compilers (BLISS) has a language rule that
expects such definitions to get into the ELF symbol table as a way to
compel the linker to include certain object modules.

With our backend for our older targets, we had a "required_om_entry"
function attribute that told our backend to put it out regardless.

I was looking at the list of function attributes and don't see anything
that would accomplish this.

I could just create a bogus variable and initialize it with the
function's value, but that seems unsavory.

I'm still using a way old version but I'll adapt as needed.

Any suggestions? Did I miss something?

Hi John,

This sounds like __attribute__((used)) which Clang turns into
entries in the @llvm.used list. There's also @llvm.compiler.used
and I'm not clear what the difference is, but hopefully that's
enough of a pointer that you can get it to work for Bliss.

--paulr

I had thought about "used", but not aware of the @llvm.used, et al.

I wrote some test programs with __attribute__((used)) but that felt like
something you'd put on function definitions to force code to be
generated regardless.

In the worst case, I'll do some metadata hack (I've ready had to do that
for BLISS' GLOBAL BIND feature).

Thanks for the response. I'll let folks know what I find out.

P.S. we're about to enter field test for OpenVMS after 2+ years of work
on the system and compilers. I can now boot it under VBox on my W10
system here at home.

I had thought about “used”, but not aware of the @llvm.used, et al.

I wrote some test programs with attribute((used)) but that felt like
something you’d put on function definitions to force code to be
generated regardless.

Isn’t that what you’re asking for?

Though I’m slightly confused by your original statement - /LLVM/ (the middle/backend, compiler - generating object files) wouldn’t discard an external-linkage function with no calls, because the call might be in another module. Oh, a declaration?

You have a declaration (without a definition) of a function in an llvm::Module and you want some remnant of that to appear in the object file? Yeah, I don’t think that’s supported - how’s that done on other compilers/what’s the prior art you’re trying to emulate here?

Yes, a external declaration with no uses. No calls to it. No address
taken. Just the external declaration and I want it to say around and
make it into the ELF symbol table as an undefined external reference.

Our BLISS language behaves that way and we have code that relies on that
behavior as a way to get the linker to include a particular routine into
the final image. On our other platforms, our old backend had to invent
a special attribute to indicate "you must put this in the ELF symbol
table regardless".

I can easily create a compiler-generated static and initialize it with
the address. That will do what I want at the slight expense of a static
location (memory is cheap) and a relocation for the linker to process
(it is already doing a ton anyway, what's one more). It isn't that
common so I'm not too worried. I was just wondering if I was missing it.

Thanks

yeah, don’t think there’s anything builtin to handle that - likely you’ll have to roll your own