Re: [PATCH 0 of 1] Alternative debug-shell implementation

["Yann E. MORIN" <yann dot morin dot 1998 at free dot fr>]

Johannes, All,

On Wednesday 17 October 2012 12:15:21 Johannes Stezenbach wrote:
> > > On Mon, Oct 15, 2012 at 09:53:55PM +0200, Yann E. MORIN wrote:
> > > > Here is an alternate implementation of debug-shell, that I was working on
> > > > following your previous submission.

> My patch had this test:
> 
> +       if [ -t 0 -a -t 6 -a -t 2 ]; then
> +              ...
> +       else
> +               CT_DoLog WARN "CT_DEBUG_CT_FIXUP_SHELL disabled due to I/O redirection"
> +       fi
> 
> I haven't tested what happens if you run "c-ng build |& tee log" and
> then try to run an interactive shell, but I guess it can't work?

Right, I'll see what I can do to add ths check.

> Then, I'm running in this:
> 
> [INFO ]  Checking C library configuration
> [ERROR]    You did not provide an eglibc config file!
> [ERROR]
> [ERROR]  >>
> [ERROR]  >>  Build failed in step '(top-level)'
> [ERROR]  >>
> [ERROR]  >>  Error happened in: main[scripts/crosstool-NG.sh@585]
> 
> 
> Current command (unknown), exited with error code: 1
> Please fix it up and finish by exiting the shell with one of these values:
>     1  fixed, continue with next build command
>     3  abort build
> 
> ct-ng:~/tmp/tc/build>
> 
> Where scripts/crosstool-NG.sh@585 is "for step in ${CT_STEPS}; do".
> I guess we can live with that but since there is no command
> to fix or re-run it is a bit odd.

That's the question: for commands that are not run via CT_DoExecLog, do we
want to spawn the debug-shell anyway, even if we can't display the command
that failed? My opinion is: yes, because we ant to debug the fscking b!tch,
even it it means a bit of rummaging...

At least, with the location in the error message and/or the last INFO line
of the log, it should be relatively  easy to find the real location of the
original error.

And remember that the debug-shell is just that: a debug-shell. Stumbling
across such a case can be fixed by adding a CT_DoExecLog in front of the
offending command.

In this specific case, I don't see what's wrong after just a quick glance,
but I think it's better to fix CT_TestOrAbort (and the likes) to properly
fail. I'll look at it tonight, when back home.

Thanks for the review!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq