[llvm-dev] [RFC] [tools] Changing Behavior of LLVM binutils When No File Is Specified

Jordan Rupprecht via llvm-dev llvm-dev at lists.llvm.org
Mon Jul 8 09:42:30 PDT 2019


One topic that came up at the euro llvm round table was configure script
compatibility, e.g. even if no human ever runs "ld foo.o; objdump -d",
there might be a configure script that tests for binutils that way.
However, I don't often use configure scripts, so I can't say how real this
concern is.

On Sat, Jul 6, 2019 at 1:19 PM Alex Brachet-Mialot <
alexbrachetmialot at gmail.com> wrote:

> I created a patch for just llvm-nm for now on D64290.
>
> On Thu, Jul 4, 2019 at 12:16 PM Alex Brachet-Mialot <
> alexbrachetmialot at gmail.com> wrote:
>
>> I have been working towards this on D63859. My current route was to add
>> an optional callback to MemoryBuffer::getFileOrSTDIN which will be executed
>> if stdin has not been redirected. James and I were talking over there and
>> are maybe deciding that this might not be the best solution. The
>> alternative in my mind is that the tools which want this behavior could do
>> so by explicitly testing if Process::StandardInIsUserInput rather than let
>> getFileOrSTDIN do it. This might be the better approach than passing a
>> callback to getFileOrSTDIN which perhaps not all tools will use anyway. I
>> am leaning towards doing it outside of getFileOrSTDIN. Does anyone have
>> a preference either way, or a better solution than the above two?
>>
>> Best,
>> Alex
>>
>> On Wed, Jun 26, 2019 at 3:09 PM Jake Ehrlich <jakehehrlich at google.com>
>> wrote:
>>
>>> I think consistency is key and agree that people are likely not using
>>> this anywhere. It's better to go after the ideal at first but we need to be
>>> willing to offer some path forward on these tools if it turns out large
>>> code bases that can't be easily modified use this trick. So I suppose we
>>> should do it but be willing to switch back.
>>>
>>> On Wed, Jun 26, 2019 at 10:15 AM via llvm-dev <llvm-dev at lists.llvm.org>
>>> wrote:
>>>
>>>> Like James, Michael suggested, I would prefer the default behavior be
>>>> consistent across tools (either always read from stdin or no default at all
>>>> /give error messages)
>>>>
>>>>
>>>>
>>>> *From:* James Henderson <jh7370.2008 at my.bristol.ac.uk>
>>>> *Sent:* Wednesday, June 26, 2019 2:31 AM
>>>> *To:* Alex Brachet-Mialot <alexbrachetmialot at gmail.com>
>>>> *Cc:* Fāng-ruì Sòng <maskray at google.com>; LLVMDev <
>>>> llvm-dev at lists.llvm.org>; Jordan Rupprecht <rupprecht at google.com>;
>>>> Chen, Yuanfang <Yuanfang.Chen at sony.com>
>>>> *Subject:* Re: [llvm-dev] [RFC] [tools] Changing Behavior of LLVM
>>>> binutils When No File Is Specified
>>>>
>>>>
>>>>
>>>> I agree with others that the a.out behaviour is weird (I've even
>>>> thought this about the linker output being called a.out since I started
>>>> programming, but perhaps that's a different story). The use-case I can
>>>> imagine is something like:
>>>>
>>>>
>>>>
>>>> $ ld.lld test.o
>>>>
>>>> $ llvm-objdump -d
>>>>
>>>>
>>>>
>>>> I.e. using a tool immediately after generating the linker output.
>>>> However, I don't think this is likely actually done by anybody, and I think
>>>> it's probably safe to change the behaviour here. I'd rather be universal
>>>> across the tools (e.g. always read from stdin) than do this frankly. An
>>>> error message about a missing input file might be nice in some cases
>>>> (llvm-readelf, llvm-objdump, llvm-nm), but I think we definitely want to
>>>> support the option of stdin redirection if nothing else but for test
>>>> purposes. If it's complicated to achieve both the error under
>>>> non-redirection cases, and no error in redirection cases then I'd prefer
>>>> the latter.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>>
>>>> James
>>>>
>>>>
>>>>
>>>> On Wed, 26 Jun 2019 at 08:28, Alex Brachet-Mialot via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>> Sounds good, I'll work on removing these in favor of defaulting to
>>>> stdin then?
>>>>
>>>>
>>>>
>>>> > I think it would be much friendlier to just print "file or pipe
>>>> expected" and then print the help.
>>>>
>>>> Do you have thoughts on this? I'm not sure there is a clean way to do
>>>> this, the cleanest would be through getFileOrSTDIN(), but I'm not sure all
>>>> of its users want this behavior. I don't think we need it personally, but
>>>> if you think its a good quality of life change to the tools and worth
>>>> working on, I'd be happy to do so.
>>>>
>>>>
>>>>
>>>> On Wed, Jun 26, 2019 at 1:41 AM Fāng-ruì Sòng <maskray at google.com>
>>>> wrote:
>>>>
>>>> GNU addr2line, nm, objdump, and size default to a.out when no input
>>>> file is specified.
>>>> Among llvm binary utilities, llvm-nm llvm-objdump llvm-size
>>>> llvm-dwarfdump default to a.out.
>>>>
>>>> I agree with Michael that a.out behavior may not be used by many
>>>> people. If people don't care too much
>>>> about these utilities' compatibility with GNU, deleting the default
>>>> a.out LGTM.
>>>>
>>>> (I am opposed to make more utilities default to a.out)
>>>>
>>>>
>>>>
>>>> On Wed, Jun 26, 2019 at 9:02 AM Alex Brachet-Mialot via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>> > Does anyone actually use the default to a.out behavior?
>>>>
>>>> This is a good point. What bugs me is continuity across the tools, I
>>>> agree with you that it isn't particularly useful to default to a.out. But
>>>> we are kind of stuck with the weird way that GNU's binutils do things. I am
>>>> not in favor of llvm-objdump defaulting to a.out, but llvm-readelf giving
>>>> this warning message. My guess is that moving away from using a.out by
>>>> default for llvm-objdump, llvm-nm and others whose gnu counter parts do
>>>> this would be more disruptive than my proposal.
>>>>
>>>>
>>>>
>>>> As Jake pointed out we use "-" to describe stdin/stdout, GNU's tools do
>>>> not do this, so I think there is some precedence for us slightly modifying
>>>> behavior when we can reasonably say things will not happen, like the file
>>>> "-" existing.
>>>>
>>>>
>>>>
>>>> On Tue, Jun 25, 2019 at 8:28 PM Michael Spencer <bigcheesegs at gmail.com>
>>>> wrote:
>>>>
>>>> On Tue, Jun 25, 2019 at 4:58 PM Alex Brachet-Mialot via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>> Some binutils, nm comes to mind, when to input file is specified will
>>>> default to a.out. Others do not do this and read from stdin by default. The
>>>> rest of this email will be specifically referencing these which read from
>>>> stdin, and not the tools which for various reasons do things differently.
>>>>
>>>>
>>>>
>>>> I propose that we change the behavior of these tools to use a.out when
>>>> appropriate. By appropriate I mean firstly, no input file specified and
>>>> also no stream redirection to stdin. These are the file types of stdin in
>>>> these scenarios:
>>>>
>>>> $ writes-to-stdout | prog # named pipe (fifo)
>>>>
>>>> $ prog < file # regular file
>>>>
>>>> $ prog # reading from tty, character device
>>>>
>>>>
>>>>
>>>> Perhaps if stdin is a named pipe or regular file, then the default
>>>> behavior should be as it always was, to read from stdin, but if stdin is a
>>>> tty then we should use a.out as a default file. This lets these tools act
>>>> the same as their gnu counterparts (when meaningful) but also adds what I
>>>> think is convenient to not have to specify a.out.
>>>>
>>>>
>>>>
>>>> This proposal would look something like this:
>>>>
>>>> $ llvm-strings # not meanigful to read from stdin here, look for a.out
>>>>
>>>> $ llvm-strings < file # use stdin
>>>>
>>>>
>>>>
>>>> I may have got the behavior of stream redirection wrong here, or missed
>>>> a situation when reading from the terminal is useful. I would love some
>>>> feedback.
>>>>
>>>>
>>>>
>>>> Best,
>>>>
>>>> Alex
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Does anyone actually use the default to a.out behavior?  I think it
>>>> would be much friendlier to just print "file or pipe expected" and then
>>>> print the help.
>>>>
>>>>
>>>>
>>>> - Michael Spencer
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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/20190708/74b9ad25/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4849 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190708/74b9ad25/attachment-0001.bin>


More information about the llvm-dev mailing list