Bug 69840 - two ASAN help nits
Summary: two ASAN help nits
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: sanitizer (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Martin Liška
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-16 14:30 UTC by Tom Tromey
Modified: 2016-11-25 14:27 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Patch draft (7.22 KB, patch)
2016-02-19 15:31 UTC, Martin Liška
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Tromey 2016-02-16 14:30:22 UTC
I compiled my program with -fsanitize=address.
Then I ran it with "ASAN_OPTIONS=help=1 ./q".

I noticed that the output violates the GNU standards in a couple of ways.
First, it doesn't word wrap at 80 characters.  This makes it hard to
read on a traditional 80-char terminal.

Second, it prints to stderr, not stdout.  This makes it needlessly
hard to paginate.
Comment 1 Martin Liška 2016-02-19 15:31:22 UTC
Created attachment 37741 [details]
Patch draft

I've tried to sketch-up a simple patch that can do that.
As the original source of the modified code is in LLVM project (which is merged to GCC), please create a PR in LLVM and I'll try to apply to patch to current LLVM trunk. The patch can be send eventually.

Martin
Comment 2 Martin Liška 2016-05-12 14:16:59 UTC
Well, it looks llvm folk are not convinced about the behavior:
http://reviews.llvm.org/D17566

Do we want to do it in the GCC anyway or not?

Martin
Comment 3 Kostya Serebryany 2016-05-12 22:24:38 UTC
You don't :) 
The agreement between the teams was that the code in gcc is a verbatim copy of upstream. (Well, there was a single-line difference at some point)
If you break this assumption, the next merge will undo your change.
Or the next merge will become impossible.
Comment 4 Andrew Pinski 2016-05-12 22:30:48 UTC
Then we have to agree that this code breaks GNU output style.  Or it breaks LLVM output style.  It is one or the other, I rather see a way to do this dynamically of breaking up the lines (this was done in the past for GCC's diagnostic so it definitely can be done).
Comment 5 Martin Liška 2016-05-13 11:07:42 UTC
(In reply to Andrew Pinski from comment #4)
> Then we have to agree that this code breaks GNU output style.  Or it breaks
> LLVM output style.  It is one or the other, I rather see a way to do this
> dynamically of breaking up the lines (this was done in the past for GCC's
> diagnostic so it definitely can be done).

I like your idea, thus I've created a new version of pull request that directs the dump output format by a compiler macro (_GNU_HELP_OUTPUT).

Enabling the macro in Makefile.{am,in} would be the only necessary change in GCC.
Let's see what the LLVM folks will say about the change.
Comment 6 Martin Liška 2016-11-25 14:27:11 UTC
Well, the change was rejected by LLVM folks and I think it doesn't worth spending more time with that.