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

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190626/61ec71d6/attachment.html>

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/20190626/3ba40719/attachment.html>

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/20190704/b9040b88/attachment.html>