diag color
Hi All, Reposting this here from gcc-help. I got the impression that I got colors in diag output depsite the fact that I got no GCC env var setup. The version I used is CX08$ cc --version cc (Ubuntu 5.4.0-6ubuntu1~16.04.1) 5.4.0 20160609 This is a bit of a problem because I don't use an xterm, and the term I used don't understand vt100 (xterm, etc..) escape sequence. my TERM env var is properly setup, emacs etc all works with my TERM and terminfo database that define how to do colors. Would it be posible that gcc honors the TERM variable setup, if using termcap/terminfo is too complicated, at least disable coloring if TERM is not vt100 compatible. Thanx in advance Cheers, Phi
Re: diag color
Hi,
Well, I can't 'easilly' change the makefiles I am using, they are not
mine,meaning I would have to 'patch' any build env Makefile each time
we do a refresh of the app sources. Then some gcc version don't
understand the -fno-diagnostics-color meaning the makefile patch would
have to be GCC version aware, that is a bit of a mess, and as you said
the vast majority use vt100, so those could have colors if they want
to.
While a simple getenv("TERM") to setup the default of the color
predicate before going to the sequence of testing CFLAGS, et the
optargs, would cost almost nothing.
I am not convince, ethically speaking, with the 'vast majority' concept.
I am more inclined by complexity, stabililty, risk vs benefit.
Here the risk is nil, benefit very moderate ==> easy to do.
With a cancer like propagation, vast majority use gcc, that impose
vt100, then by now the vast majority got rid of term so lets remove
termcap/terminfo. Hum... I don't really like this approach.
Cheers,
Phi
Re: diag color
Hi Jon, On Sun, Jul 31, 2016 at 1:16 PM, Jonathan Wakely > The manual says "Setting GCC_COLORS to the empty string disables colors." > > Did you try that? Setting it to an empty string in your env should > disable the coloured output. Yes it works, sounds a less intrusive one :) regarding old version compatibility, will export that. When looking quick at the src I din't spotted this getenv() that is not in the init() path as it should :) Thanx Phi
Re: diag color
Forgot to say that before posting I did try export GCC_COLORS=never after reading == -fno-diagnostics-colorUse color in diagnostics. WHEN is ‘never’, ‘always’, or ‘auto’. The default depends on how the compiler has been configured, it can be any of the above WHEN options or also ‘never’ if GCC_COLORS environment variable isn't present in the environment, and ‘auto’ otherwise. ‘auto’ means to use color only when the standard error is a terminal. The forms -fdiagnostics-color and -fno-diagnostics-color are aliases for -fdiagnostics-color=always and -fdiagnostics-color=never, respectively. == I admit I red this a bit too fast, and since the doc sez "if GCC_COLORS isn't present" I didn't infered what it does if set. I didn't saw the =never was a goof for the env var. I guess I must not be the only one trapped here. Yet I still believe it is wrongly coded, a very little logic in the init() path would allow every one to be happy :) Yet I will do the export :) Cheers, Phi
Re: diag color
Hi Manuel,
On Sun, Jul 31, 2016 at 3:16 PM, Manuel López-Ibáñez
wrote:
> On 31/07/16 13:16, phi gcc wrote:
>
> If you think you can code it better, prove it:
Why should I ? I am not a gcc designer, just humbelly reporting a
usability issue, where a gcc upgrade start to produce garbled
unreadable output on stderr.
At some point one suggested reading the source, I did it real quick,
and it appears trivial that getenv("TERM") is wrongly processed, made
a kind proposal as suggestion, that can indeed be implemented
otherwise by the code owner.
Now gcc team can simply trash this, but if gcc can't handle trivial
request like this, sounds a bit scary for the future :)
Jon sugested a valid work around that I can manage for a while that is
a gcc shell wrapper export the GCC_COLORS='' then call gcc.ori, it is
sloppy but workable.
If this is still accepted as a potential problem then lemme know the official
process to submit a bug report. If people on the list strongly think
this is not a problem, then it will save time, we close it period :)
Re: diag color
On Sun, Jul 31, 2016 at 10:54 PM, phi gcc wrote: > If this is still accepted as a potential problem then lemme know the official > process to submit a bug report. I oppsed here, I red your link and see the very last line about bugzilla will experiment this...
Re: diag color
bugzilla don't likes me, can't get in Ok let's forget participation then...
C mangling
Hi Gurus, I got functions named like this in my symbol table [21711] |0x81228250|0x01e5|FUNC |LOCAL|0| .text|ep_scan_ready_list.isra.7 This is a linux kernel. I gues this is a magle name for the function ep_scan_ready_list() that is has only 2 call sites like this ep_scan_ready_list( arg->ep, ep_read_events_proc, NULL, call_nests + 1, arg->locked); ep_scan_ready_list( ep, ep_send_events_proc, &esed, 0, false); The common arg is a function ptr 'ep_read_events_proc' so I guess gcc removed this paramter and called the cloned function instead. My question is. Is there a ref doc that explain how it is mangled. Can we use the .7 for somethings. Are there stuff in the dwarf that would help an unwinder crossing this symbol name to retrieve the removed parameter. Thanx in advance Cheers, Phi
