<div dir="ltr"><div>I created a patch for review to allow wildcard patterns in `-u`.</div><div><br></div><a href="https://reviews.llvm.org/D63244">https://reviews.llvm.org/D63244</a><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 12, 2019 at 5:35 PM Peter Smith <<a href="mailto:peter.smith@linaro.org">peter.smith@linaro.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 12 Jun 2019 at 04:48, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br>
><br>
> On Tue, Jun 11, 2019 at 10:54 PM Peter Smith <<a href="mailto:peter.smith@linaro.org" target="_blank">peter.smith@linaro.org</a>> wrote:<br>
>><br>
>> On Tue, 11 Jun 2019 at 14:31, Rui Ueyama via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> ><br>
>> > Hi,<br>
>> ><br>
>> > I got a feature request from an internal customer of lld, but I don't know whether we should implement it or not, so I'd like to get opinions from people on this mailing list.<br>
>> ><br>
>> > The feature request is to allow wildcard patterns in the `--undefined` option. `--undefined foo` (or `-u foo` for short) makes the linker to pull out an object file from a static library if the file defines symbol foo. So, by allowing wildcard patterns, you can pull out all object files defining some JNI symbols (which start with "Java_") from static archives by specifying `-u "Java_*"`, for example.<br>
>> ><br>
>> > This seems mildly useful to me, but it comes with a cost. Currently, `-u` is literally as fast as a single hash lookup. If you allow wildcard patterns in `-u`, you have to attempt a wildcard pattern match against all symbols in the symbol table, which can be expensive.<br>
>> ><br>
>> > I'm also not sure how useful it will actually be. The above JNI case is somewhat convincing, but that's just one use case, and if there's only one use case, adding a new feature for that particular case is probably not a very good idea.<br>
>> ><br>
>> > Does anyone have any opinion on whether we should support this or not?<br>
>> ><br>
>><br>
>> Arm's proprietary linker supported a similar wildcard feature for the<br>
>> various section and symbol commands. My opinion was that it was very<br>
>> useful for a small number of cases. Usually where a customer's set of<br>
>> symbols to operate on was changing frequently during development and<br>
>> with a simple naming convention and a wildcard they could save quite a<br>
>> bit of effort. Their alternative was to either manually maintain the<br>
>> list of symbols or write a tool to generate it.<br>
><br>
><br>
> Thank you for the info. Does the ARM proprietary linker support `*`? Is there any way to escape `*`? I think `*` is not usually used in a symbol name, so treating `*` as a metacharacter should be fine, but I'm wondering how the ARM linker works.<br>
><br>
<br>
No it didn't have an escape character. The way the '*' was defined<br>
(match 0 or more characters) would have matched a symbol name with a *<br>
in it, but would also have matched more than it should have if the<br>
intention was to just match the symbol with the '*' character. There<br>
was an another wildcard '?' that matched any one character which could<br>
have been used to try and match the '*' character a bit more<br>
precisely. As you say '*' and '?' are not common in symbol names, I<br>
don't think I've ever seen it happen in practice so the lack of<br>
escaping didn't turn out to be a problem.<br>
<br>
>> We went down the approach of a fast path when there where no wildcards<br>
>> and a slow path when there was. Aside from the check that there was a<br>
>> wildcard it wasn't too much extra overhead for the fast path.<br>
><br>
><br>
> That's true. The usual use case won't be penalized by adding a wildcard support.<br>
><br>
>><br>
>> Peter<br>
>><br>
>> > Thanks,<br>
>> > Rui<br>
>> > _______________________________________________<br>
>> > LLVM Developers mailing list<br>
>> > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> > <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>