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

Sat Jul 6 13:19:29 PDT 2019

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/20190706/47613ceb/attachment.html>