John Reagan via llvm-dev
2020-May-08 01:47 UTC
[llvm-dev] How to force unused external routine declaration into object
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. On 5/7/2020 4:16 PM, Robinson, Paul wrote:> > >> -----Original Message----- >> From: llvm-dev <llvm-dev-bounces at 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 at 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 > >> >> John (safely at home with sufficient food & wine) >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
David Blaikie via llvm-dev
2020-May-08 01:58 UTC
[llvm-dev] How to force unused external routine declaration into object
On Thu, May 7, 2020 at 6:47 PM John Reagan via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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?> > 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. > > On 5/7/2020 4:16 PM, Robinson, Paul wrote: > > > > > >> -----Original Message----- > >> From: llvm-dev <llvm-dev-bounces at 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 at 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 > > > >> > >> John (safely at home with sufficient food & wine) > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200507/3c4c6a42/attachment.html>
John Reagan via llvm-dev
2020-May-08 14:37 UTC
[llvm-dev] How to force unused external routine declaration into object
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 On 5/7/2020 9:58 PM, David Blaikie wrote:> > > On Thu, May 7, 2020 at 6:47 PM John Reagan via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > 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? > > > > 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. > > On 5/7/2020 4:16 PM, Robinson, Paul wrote: > > > > > >> -----Original Message----- > >> From: llvm-dev <llvm-dev-bounces at lists.llvm.org > <mailto:llvm-dev-bounces at 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 at lists.llvm.org > <mailto:llvm-dev at 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 > > > >> > >> John (safely at home with sufficient food & wine) > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >