This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See crosstool-NG for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Johannes, All,

On Friday 26 October 2012 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.
[--SNIP--]
> I just ran into an endless loop with today's ct-ng, which was caused
> by a patch failing to apply in CT_Patch.  The problem is that
> the failed command uses stdin redirection.

Ah, good catch.

[--SNIP--]
> The easiest fix for this particular case would be to use "patch -i patch"
> instead of "patch <patch" (-i is in POSIX), which would also have the
> advantage that the patch filename would show up in the failed command.

Yep, let's use "patch -i".
I was not happy with the redirection anyway.

> But in general I guess the fix might be:
> 
> 
> --- functions.orig	2012-10-26 14:04:35.767316717 +0200
> +++ functions	2012-10-26 14:19:06.921870258 +0200
> @@ -46,7 +46,7 @@ CT_OnError() {
>              old_trap="$(trap -p ERR)"
>              trap -- ERR
>              (
> -                exec >&6
> +                exec >&6 2>&7 <&8
>                  printf "\r         \n\nCurrent command"
>                  if [ -n "${cur_cmd}" ]; then
>                      printf ":\n  %s\n" "${cur_cmd}"
> @@ -131,7 +131,7 @@ set +o hashall
>  
>  # Log policy:
>  #  - first of all, save stdout so we can see the live logs: fd #6
> -exec 6>&1
> +exec 6>&1 7>&2 8<&0
>  #  - then point stdout to the log file
>  tmp_log_file="${CT_TOP_DIR}/build.log"
>  rm -f "${tmp_log_file}"

Care to send a proper patch with your SoB line, please?

> Another issue is that "1  fixed, continue with next build command"
> doesn't seem to work since the exit status isn't cleared
> and CT_DoExecLog() fails again.  Maybe we need something like
> "${CT_BUILD_DIR}/repeat" for the "continue" case?

I'll double check, but I remember it to work for me...
I even added this code to test retry/resume/abort:
    CT_DoExecLog DEBUG false false-01
    CT_DoExecLog DEBUG false false-02
    CT_DoExecLog DEBUG false false-03

And I was able to either retry/resume/abort.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]