Hi Dan,
lld takes a -emit-yaml option, which emits the intermediate
representation(atoms) in YAML form.
By default output goes to stdout, the user can control it by using the
-o option too.
The way its handled is, similiar to this piece of pseudo-code
if (dash_o_option)
outputFile = dash_o_option->value()
else
outputFile = "-"
When lld tries to mix things that go to stdout using llvm::outs() and
-emit-yaml, it starts to get this error.
If there is a restriction like this, possibly it has to be mentioned
somewhere for usecases (or) raw_fd_ostream should not be accepting a '-'
in the argument.
What do you think ?
Thanks
Shankar Easwaran
On 8/14/2013 2:02 PM, Dan Gohman wrote:> The high-level answer is that library code shouldn't hardcode output
paths,
> including "-" and including using llvm::outs(). Library code
should (in
> general) instead accept an ostream in its API and write to wherever it is
> being asked to write. If this is followed, the only place in any program
> using llvm::outs() is code which is not part of a "library" --
i.e. it is
> the "main" code, and it should only do so if it is a program
which doesn't
> open file names which could be "-".
>
> Do you have a use-case where this restriction is too restrictive?
>
> As a random aside, a more aggressive answer could be that "-" is
a kind of
> hack, and that it would be a better approach to use /dev/stdout and
> /dev/stdin instead of "-", because they wouldn't require
special-case
> logic. Unfortunately, this may not be sufficiently portable.
>
> Dan
>
>
> On Wed, Aug 14, 2013 at 8:28 AM, Shankar Easwaran
> <shankare at codeaurora.org>wrote:
>
>> Hi,
>>
>> When I run the below example, it results in :-
>>
>> hello
>> world
>> LLVM ERROR: IO failure on output stream.
>>
>> Testcase :-
>>
>> #include <llvm/Support/raw_ostream.h>
>>
>> int fn() {
>> std::string errorInfo;
>> llvm::raw_fd_ostream out("-", errorInfo);
>> out << "world\n";
>> return 0;
>> }
>> int main(int argc, char **argv) {
>> llvm::outs() << "hello\n";
>> fn();
>> return 0;
>> }
>>
>> I tried to fix this by making llvm::outs(), not close the stdout
>> descriptor, but I think its wrong. Recommendations ?
>>
>> Thanks
>>
>> Shankar Easwaran
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted
>> by the Linux Foundation
>>
>>
>>
>> ______________________________**_________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>
http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation
On 8/14/2013 2:53 PM, Shankar Easwaran wrote:> Hi Dan, > > lld takes a -emit-yaml option, which emits the intermediate > representation(atoms) in YAML form. > > By default output goes to stdout, the user can control it by using the > -o option too. > > The way its handled is, similiar to this piece of pseudo-code > > if (dash_o_option) > outputFile = dash_o_option->value() > else > outputFile = "-" > > When lld tries to mix things that go to stdout using llvm::outs() and > -emit-yaml, it starts to get this error. > > If there is a restriction like this, possibly it has to be mentioned > somewhere for usecases (or) raw_fd_ostream should not be accepting a > '-' in the argument. > > What do you think ? > > Thanks > > Shankar Easwaran > > On 8/14/2013 2:02 PM, Dan Gohman wrote: >> The high-level answer is that library code shouldn't hardcode output >> paths, >> including "-" and including using llvm::outs(). Library code should (in >> general) instead accept an ostream in its API and write to wherever >> it is >> being asked to write. If this is followed, the only place in any program >> using llvm::outs() is code which is not part of a "library" -- i.e. >> it is >> the "main" code, and it should only do so if it is a program which >> doesn't >> open file names which could be "-". >> >> Do you have a use-case where this restriction is too restrictive? >> >> As a random aside, a more aggressive answer could be that "-" is a >> kind of >> hack, and that it would be a better approach to use /dev/stdout and >> /dev/stdin instead of "-", because they wouldn't require special-case >> logic. Unfortunately, this may not be sufficiently portable. >> >> Dan >> >> >> On Wed, Aug 14, 2013 at 8:28 AM, Shankar Easwaran >> <shankare at codeaurora.org>wrote: >> >>> Hi, >>> >>> When I run the below example, it results in :- >>> >>> hello >>> world >>> LLVM ERROR: IO failure on output stream. >>> >>> Testcase :- >>> >>> #include <llvm/Support/raw_ostream.h> >>> >>> int fn() { >>> std::string errorInfo; >>> llvm::raw_fd_ostream out("-", errorInfo); >>> out << "world\n"; >>> return 0; >>> } >>> int main(int argc, char **argv) { >>> llvm::outs() << "hello\n"; >>> fn(); >>> return 0; >>> } >>> >>> I tried to fix this by making llvm::outs(), not close the stdout >>> descriptor, but I think its wrong. Recommendations ? >>> >>> Thanks >>> >>> Shankar Easwaran >>> >>> -- >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >>> hosted >>> by the Linux Foundation >>> >>> >>> >>> ______________________________**_________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >>> >>> > >-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
Would it be appropriate for lld's other output to go to standard error instead of standard output, since standard output may be used for YAML output? Dan On Wed, Aug 14, 2013 at 12:53 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:> Hi Dan, > > lld takes a -emit-yaml option, which emits the intermediate > representation(atoms) in YAML form. > > By default output goes to stdout, the user can control it by using the -o > option too. > > The way its handled is, similiar to this piece of pseudo-code > > if (dash_o_option) > outputFile = dash_o_option->value() > else > outputFile = "-" > > When lld tries to mix things that go to stdout using llvm::outs() and > -emit-yaml, it starts to get this error. > > If there is a restriction like this, possibly it has to be mentioned > somewhere for usecases (or) raw_fd_ostream should not be accepting a '-' in > the argument. > > What do you think ? > > Thanks > > Shankar Easwaran > > > On 8/14/2013 2:02 PM, Dan Gohman wrote: > >> The high-level answer is that library code shouldn't hardcode output >> paths, >> including "-" and including using llvm::outs(). Library code should (in >> general) instead accept an ostream in its API and write to wherever it is >> being asked to write. If this is followed, the only place in any program >> using llvm::outs() is code which is not part of a "library" -- i.e. it is >> the "main" code, and it should only do so if it is a program which doesn't >> open file names which could be "-". >> >> Do you have a use-case where this restriction is too restrictive? >> >> As a random aside, a more aggressive answer could be that "-" is a kind of >> hack, and that it would be a better approach to use /dev/stdout and >> /dev/stdin instead of "-", because they wouldn't require special-case >> logic. Unfortunately, this may not be sufficiently portable. >> >> Dan >> >> >> On Wed, Aug 14, 2013 at 8:28 AM, Shankar Easwaran >> <shankare at codeaurora.org>**wrote: >> >> Hi, >>> >>> When I run the below example, it results in :- >>> >>> hello >>> world >>> LLVM ERROR: IO failure on output stream. >>> >>> Testcase :- >>> >>> #include <llvm/Support/raw_ostream.h> >>> >>> int fn() { >>> std::string errorInfo; >>> llvm::raw_fd_ostream out("-", errorInfo); >>> out << "world\n"; >>> return 0; >>> } >>> int main(int argc, char **argv) { >>> llvm::outs() << "hello\n"; >>> fn(); >>> return 0; >>> } >>> >>> I tried to fix this by making llvm::outs(), not close the stdout >>> descriptor, but I think its wrong. Recommendations ? >>> >>> Thanks >>> >>> Shankar Easwaran >>> >>> -- >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted >>> by the Linux Foundation >>> >>> >>> >>> ______________________________****_________________ >>> >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/****mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev> >>> <http:**//lists.cs.uiuc.edu/mailman/**listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >>> > >>> >>> > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by the Linux Foundation > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130814/f5043d6a/attachment.html>
Hi Dan, The other messages, need to go to stdout as well. Using stderr to output for a switch like --verbose is wrong in my opinion. On 8/14/2013 4:44 PM, Dan Gohman wrote:> Would it be appropriate for lld's other output to go to standard error > instead of standard output, since standard output may be used for YAML > output? > > Dan > > On Wed, Aug 14, 2013 at 12:53 PM, Shankar Easwaran > <shankare at codeaurora.org>wrote: > >> Hi Dan, >> >> lld takes a -emit-yaml option, which emits the intermediate >> representation(atoms) in YAML form. >> >> By default output goes to stdout, the user can control it by using the -o >> option too. >> >> The way its handled is, similiar to this piece of pseudo-code >> >> if (dash_o_option) >> outputFile = dash_o_option->value() >> else >> outputFile = "-" >> >> When lld tries to mix things that go to stdout using llvm::outs() and >> -emit-yaml, it starts to get this error. >> >> If there is a restriction like this, possibly it has to be mentioned >> somewhere for usecases (or) raw_fd_ostream should not be accepting a '-' in >> the argument. >> >> What do you think ? >> >> Thanks >> >> Shankar Easwaran >> >> >> On 8/14/2013 2:02 PM, Dan Gohman wrote: >> >>> The high-level answer is that library code shouldn't hardcode output >>> paths, >>> including "-" and including using llvm::outs(). Library code should (in >>> general) instead accept an ostream in its API and write to wherever it is >>> being asked to write. If this is followed, the only place in any program >>> using llvm::outs() is code which is not part of a "library" -- i.e. it is >>> the "main" code, and it should only do so if it is a program which doesn't >>> open file names which could be "-". >>> >>> Do you have a use-case where this restriction is too restrictive? >>> >>> As a random aside, a more aggressive answer could be that "-" is a kind of >>> hack, and that it would be a better approach to use /dev/stdout and >>> /dev/stdin instead of "-", because they wouldn't require special-case >>> logic. Unfortunately, this may not be sufficiently portable. >>> >>> Dan >>> >>> >>> On Wed, Aug 14, 2013 at 8:28 AM, Shankar Easwaran >>> <shankare at codeaurora.org>**wrote: >>> >>> Hi, >>>> When I run the below example, it results in :- >>>> >>>> hello >>>> world >>>> LLVM ERROR: IO failure on output stream. >>>> >>>> Testcase :- >>>> >>>> #include <llvm/Support/raw_ostream.h> >>>> >>>> int fn() { >>>> std::string errorInfo; >>>> llvm::raw_fd_ostream out("-", errorInfo); >>>> out << "world\n"; >>>> return 0; >>>> } >>>> int main(int argc, char **argv) { >>>> llvm::outs() << "hello\n"; >>>> fn(); >>>> return 0; >>>> } >>>> >>>> I tried to fix this by making llvm::outs(), not close the stdout >>>> descriptor, but I think its wrong. Recommendations ? >>>> >>>> Thanks >>>> >>>> Shankar Easwaran >>>> >>>> -- >>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted >>>> by the Linux Foundation >>>> >>>> >>>> >>>> ______________________________****_________________ >>>> >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/****mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev> >>>> <http:**//lists.cs.uiuc.edu/mailman/**listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >>>> >> -- >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted >> by the Linux Foundation >> >>-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation