[U-Boot] U-Boot Bug with newer GCC

[U-Boot] U-Boot Bug with newer GCC

[Priebe, Sebastian]

Hello,

we are using u-boot in our embedded system with arm-1136jfs cpu.
We recently tried a new toolchain with GCC 4.7.2.
If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
U-Boot start normally and on hitting TAB the system freezes.
I tracked the problem down the variables __u_boot_cmd_start and __u_boot_cmd_end. Both are not valid with the new toolchain. And accessing one results in a system freeze.
Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad at linker scripts.

Can someone help here?

Thanks.
Sebastian


==========================================
CADCON
Ingenieurgesellschaft mbH & Co. KG
Geschaeftsfuehrer: Robert Bauer, Andreas Gundel
Sitz der Gesellschaft: D-86368 Gersthofen
Registergericht: Amtsgericht Augsburg HRA 14521
==========================================

[U-Boot] U-Boot Bug with newer GCC

[Wolfgang Denk]

Dear Sebastian,

In message <E70AF999396FDF4EAE40E195B847096109F5D3A9@SRVEXCH-2K10.CADCON.INTERN> you wrote:
> 
> we are using u-boot in our embedded system with arm-1136jfs cpu.

Which exact system / board configuration is this?

And which exact U-Boot version (git commit ID ?) is it?

> We recently tried a new toolchain with GCC 4.7.2.
> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.

We have been using GCC 4.7.2 for several months now, on many systems.
No such problems have been reported before, so I speculate if this is
really a problem with mainline code?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If a man had a child who'd gone  anti-social,  killed  perhaps,  he'd
still tend to protect that child.
	-- McCoy, "The Ultimate Computer", stardate 4731.3

[U-Boot] U-Boot Bug with newer GCC

[Jeroen Hofstee]

Hi Wolfgang,

On 02/01/2013 12:31 PM, Wolfgang Denk wrote:
>> We recently tried a new toolchain with GCC 4.7.2.
>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
> We have been using GCC 4.7.2 for several months now, on many systems.
> No such problems have been reported before, so I speculate if this is
> really a problem with mainline code?
The twister board has the same problem, tested
4e5eb45898b6f05fef3a4690399726c03bc1f398 with twister_config /
eldk 5.3 on a twister board (and it traps). So it does occur in mainline,
but it must be a combination of board config and code or something,
since also Albert did not know / didn't have this problem.

Regards,
Jeroen

[U-Boot] U-Boot Bug with newer GCC

[Wolfgang Denk]

Dear Sebastian,

In message <E70AF999396FDF4EAE40E195B847096109F5D6FD@SRVEXCH-2K10.CADCON.INTERN> you wrote:
> 
> We use a custom board configuration for our custom hardware.
> I can send parts of it, if needed.

Thanks, but no.  Parts are of no use to us.  Basicly you have to
options: have your code merged into mainline (to do that you have to
submit a complete set of patches here on the mailing list), or
maintain your out-of-tree port yourself (in which case David
Woodhouse's statement applies, see
http://article.gmane.org/gmane.linux.kernel.embedded/3534).

> We are currently using v2012.10.

This works fine for the mainline code.

> The toolchain is OSELAS.2012.12.0 (http://www.pengutronix.de/oselas/toolchain).

So eother it's an issue with your port, or with your toolchain.

> With toolchain OSELAS.2011.11.2 everything worked fine.
> We didn't change anything else.

Then this smells like a tool chain issue.  You might contact
Pengutronix support for help with their tool chain.

> So I suppose this might be a mainline problem.
> It seems like the mentioned variables don't get set correctly as before.

Well, no such problems are observed with mainline code and - for
example - ELDK 5.5 and 5.4-M3-rc1.  What makes you think it's a
mainline issue?  Can you prove such problems with mainline code, and
with a known to be working tool chain?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
1 1 was a race-horse, 2 2 was 1 2. When 1 1 1 1 race, 2 2 1 1 2.

[U-Boot] U-Boot Bug with newer GCC

[Wolfgang Denk]

Dear Jeroen Hofstee,

In message <510BFE48.3060206@myspectrum.nl> you wrote:
> Hi Wolfgang,
> 
> On 02/01/2013 12:31 PM, Wolfgang Denk wrote:
> >> We recently tried a new toolchain with GCC 4.7.2.
> >> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
> > We have been using GCC 4.7.2 for several months now, on many systems.
> > No such problems have been reported before, so I speculate if this is
> > really a problem with mainline code?
> The twister board has the same problem, tested
> 4e5eb45898b6f05fef3a4690399726c03bc1f398 with twister_config /
> eldk 5.3 on a twister board (and it traps). So it does occur in mainline,

Interesting - did you ever report this problem on the mailing list?
I cannot find any such information in the archives.  When was this
observed for the dfirst time?

> but it must be a combination of board config and code or something,
> since also Albert did not know / didn't have this problem.

So you think it's ARM specific?

Sebastian - I think you did not mention yet which SoC you're using -
is this also ARM?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Plan to throw one away. You will anyway."
                              - Fred Brooks, "The Mythical Man Month"

[U-Boot] U-Boot Bug with newer GCC

[Heiko Schocher]

Hello Wolfgang, Sebastian,

On 01.02.2013 12:31, Wolfgang Denk wrote:
> In message <E70AF999396FDF4EAE40E195B847096109F5D3A9@SRVEXCH-2K10.CADCON.INTERN> you wrote:
>>
>> we are using u-boot in our embedded system with arm-1136jfs cpu.
> 
> Which exact system / board configuration is this?
> 
> And which exact U-Boot version (git commit ID ?) is it?
> 
>> We recently tried a new toolchain with GCC 4.7.2.
>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
> 
> We have been using GCC 4.7.2 for several months now, on many systems.
> No such problems have been reported before, so I speculate if this is
> really a problem with mainline code?

Sebastian wrote On 01.02.2013 08:55:
> we are using u-boot in our embedded system with arm-1136jfs cpu.
> We recently tried a new toolchain with GCC 4.7.2.
> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
> U-Boot start normally and on hitting TAB the system freezes.
> I tracked the problem down the variables __u_boot_cmd_start and __u_boot_cmd_end. Both are not valid with the new toolchain. And accessing one results in a system freeze.
> Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad at linker scripts.

I just see some problems with ll_entry_* functions described in my
post here:
http://lists.denx.de/pipermail/u-boot/2013-February/145711.html

I do not know, if this is the same problem, as I face problems only
before relocation, after relocation all works fine ...

In this thread Marek wrote, that for this problem albert has
a solution ... (CCed albert and marek)

Albert? Can you help here?

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] U-Boot Bug with newer GCC

[Jeroen Hofstee]

Hello,

On 02/02/2013 09:37 AM, Heiko Schocher wrote:
> Hello Wolfgang, Sebastian,
>
> On 01.02.2013 12:31, Wolfgang Denk wrote:
>> In message <E70AF999396FDF4EAE40E195B847096109F5D3A9@SRVEXCH-2K10.CADCON.INTERN> you wrote:
>>> we are using u-boot in our embedded system with arm-1136jfs cpu.
>> Which exact system / board configuration is this?
>>
>> And which exact U-Boot version (git commit ID ?) is it?
>>
>>> We recently tried a new toolchain with GCC 4.7.2.
>>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
>> We have been using GCC 4.7.2 for several months now, on many systems.
>> No such problems have been reported before, so I speculate if this is
>> really a problem with mainline code?
> Sebastian wrote On 01.02.2013 08:55:
>> we are using u-boot in our embedded system with arm-1136jfs cpu.
>> We recently tried a new toolchain with GCC 4.7.2.
>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
>> U-Boot start normally and on hitting TAB the system freezes.
>> I tracked the problem down the variables __u_boot_cmd_start and __u_boot_cmd_end. Both are not valid with the new toolchain. And accessing one results in a system freeze.
>> Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad at linker scripts.
> I just see some problems with ll_entry_* functions described in my
> post here:
> http://lists.denx.de/pipermail/u-boot/2013-February/145711.html
>
> I do not know, if this is the same problem, as I face problems only
> before relocation, after relocation all works fine ...
>
> In this thread Marek wrote, that for this problem albert has
> a solution ... (CCed albert and marek)
>
> Albert? Can you help here?
I am tempted to think that is unrelated. First of all since you encounter
problems with the 4.6 toolchain. This trap is not present when
compiling with a 4.6 version (at least not for me).

Second, because I bothered Marex and Albert already with this
problem on irc and they concluded it could not be ll related.

Third, because dumping the array of commands to a console,
displays them all correctly.

Regards,
Jeroen

[U-Boot] U-Boot Bug with newer GCC

[Jeroen Hofstee]

Hello Wolfgang,

On 02/01/2013 10:42 PM, Wolfgang Denk wrote:
> Dear Jeroen Hofstee,
>
> In message <510BFE48.3060206@myspectrum.nl> you wrote:
>> Hi Wolfgang,
>>
>> On 02/01/2013 12:31 PM, Wolfgang Denk wrote:
>>>> We recently tried a new toolchain with GCC 4.7.2.
>>>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
>>> We have been using GCC 4.7.2 for several months now, on many systems.
>>> No such problems have been reported before, so I speculate if this is
>>> really a problem with mainline code?
>> The twister board has the same problem, tested
>> 4e5eb45898b6f05fef3a4690399726c03bc1f398 with twister_config /
>> eldk 5.3 on a twister board (and it traps). So it does occur in mainline,
> Interesting - did you ever report this problem on the mailing list?
> I cannot find any such information in the archives.  When was this
> observed for the dfirst time?

no, I haven't (did bother people on irc with it though). I saw it about a
month ago or so.  One of the things I tried was to find a working release,
but v2012.04 also traps. Since the arm relocation change is before that,
I didn't test earlier releases.

> So you think it's ARM specific?

Well I though so at least, currently I am in the dark actually. I will 
have a
look at Sebastian's suggestion that it could be the linker script /
variable placement. What I recall is that:

It traps at a strlen function in the command completion routine. Arguments
/ registers are nonsense, so it is not a simple unaligned access. Inserting
printfs / making unrelated changes can make it go away, change the trap
etc. So currently I only know that something is wrong somewhere. With
gcc from eldk 5.2.1 things work as expected.

> Sebastian - I think you did not mention yet which SoC you're using -
> is this also ARM?
He mentioned it, it is an arm-1136jfs.

Regards,

Jeroen

[U-Boot] U-Boot Bug with newer GCC

[Albert ARIBAUD]

Hi Jeroen,

On Sat, 02 Feb 2013 11:18:44 +0100, Jeroen Hofstee
<jeroen@myspectrum.nl> wrote:

> Hello,
> 
> On 02/02/2013 09:37 AM, Heiko Schocher wrote:
> > Hello Wolfgang, Sebastian,
> >
> > On 01.02.2013 12:31, Wolfgang Denk wrote:
> >> In message <E70AF999396FDF4EAE40E195B847096109F5D3A9@SRVEXCH-2K10.CADCON.INTERN> you wrote:
> >>> we are using u-boot in our embedded system with arm-1136jfs cpu.
> >> Which exact system / board configuration is this?
> >>
> >> And which exact U-Boot version (git commit ID ?) is it?
> >>
> >>> We recently tried a new toolchain with GCC 4.7.2.
> >>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
> >> We have been using GCC 4.7.2 for several months now, on many systems.
> >> No such problems have been reported before, so I speculate if this is
> >> really a problem with mainline code?
> > Sebastian wrote On 01.02.2013 08:55:
> >> we are using u-boot in our embedded system with arm-1136jfs cpu.
> >> We recently tried a new toolchain with GCC 4.7.2.
> >> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
> >> U-Boot start normally and on hitting TAB the system freezes.
> >> I tracked the problem down the variables __u_boot_cmd_start and __u_boot_cmd_end. Both are not valid with the new toolchain. And accessing one results in a system freeze.
> >> Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad at linker scripts.
> > I just see some problems with ll_entry_* functions described in my
> > post here:
> > http://lists.denx.de/pipermail/u-boot/2013-February/145711.html
> >
> > I do not know, if this is the same problem, as I face problems only
> > before relocation, after relocation all works fine ...
> >
> > In this thread Marek wrote, that for this problem albert has
> > a solution ... (CCed albert and marek)
> >
> > Albert? Can you help here?
> I am tempted to think that is unrelated. First of all since you encounter
> problems with the 4.6 toolchain. This trap is not present when
> compiling with a 4.6 version (at least not for me).
> 
> Second, because I bothered Marex and Albert already with this
> problem on irc and they concluded it could not be ll related.

To be more complete, the ll_entry problems are only seen before
relocation, are due to the way variables are referred to, and I do
indeed have a patch for this, that I'll send out today.

But the tab issue happens after relocation, and therefore is unrelated
to this ll_entry issue. AFAIK it has never been seen on mainline code,
and has been very elusive for those who experience it -- enabling debug
or simply adding/removing code makes it go away or reappear, leading me
to thinking that some of the added code either does a data abort itself,
or causes one in the mainline code it calls upon.

> Third, because dumping the array of commands to a console,
> displays them all correctly.
> 
> Regards,
> Jeroen

Amicalement,
-- 
Albert.

[U-Boot] U-Boot Bug with newer GCC

[Jeroen Hofstee]

Hello Albert,

On 02/02/2013 12:32 PM, Albert ARIBAUD wrote:
>
>>>
>>> Sebastian wrote On 01.02.2013 08:55:
>>>> we are using u-boot in our embedded system with arm-1136jfs cpu.
>>>> We recently tried a new toolchain with GCC 4.7.2.
>>>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
> [..] AFAIK it has never been seen on mainline code,
The twister board from mainline / current master also has
this problem. I believe the mt_ventoux will have it as well,
but can't test it.
> and has been very elusive for those who experience it -- enabling debug
> or simply adding/removing code makes it go away or reappear, leading me
> to thinking that some of the added code either does a data abort itself,
> or causes one in the mainline code it calls upon.
yes, it is confusing. The following patch will e.g. make the
trap go away on the twister. Yet there is nothing wrong with the
original code it touches (or I fail to see what it is).

Regards,
Jeroen

diff --git a/common/command.c b/common/command.c
index 50c8429..520bd39 100644
--- a/common/command.c
+++ b/common/command.c
@@ -185,7 +185,6 @@ static int complete_cmdv(int argc, char * const 
argv[], char last_char, int maxv
         cmd_tbl_t *cmdtp = ll_entry_start(cmd_tbl_t, cmd);
         const int count = ll_entry_count(cmd_tbl_t, cmd);
         const cmd_tbl_t *cmdend = cmdtp + count;
-       const char *p;
         int len, clen;
         int n_found = 0;
         const char *cmd;
@@ -224,11 +223,7 @@ static int complete_cmdv(int argc, char * const 
argv[], char last_char, int maxv
          * Some commands allow length modifiers (like "cp.b");
          * compare command name only until first dot.
          */
-       p = strchr(cmd, '.');
-       if (p == NULL)
-               len = strlen(cmd);
-       else
-               len = p - cmd;
+       len = strlen(cmd);

         /* return the partial matches */
         for (; cmdtp != cmdend; cmdtp++) {

[U-Boot] U-Boot Bug with newer GCC

[Marek Vasut]

Dear Jeroen Hofstee,

> Hello Albert,
> 
> On 02/02/2013 12:32 PM, Albert ARIBAUD wrote:
> >>> Sebastian wrote On 01.02.2013 08:55:
> >>>> we are using u-boot in our embedded system with arm-1136jfs cpu.
> >>>> We recently tried a new toolchain with GCC 4.7.2.
> >>>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE
> >>>> isn't working.
> > 
> > [..] AFAIK it has never been seen on mainline code,
> 
> The twister board from mainline / current master also has
> this problem. I believe the mt_ventoux will have it as well,
> but can't test it.
> 
> > and has been very elusive for those who experience it -- enabling debug
> > or simply adding/removing code makes it go away or reappear, leading me
> > to thinking that some of the added code either does a data abort itself,
> > or causes one in the mainline code it calls upon.
> 
> yes, it is confusing. The following patch will e.g. make the
> trap go away on the twister. Yet there is nothing wrong with the
> original code it touches (or I fail to see what it is).
> 
> Regards,
> Jeroen
> 
> diff --git a/common/command.c b/common/command.c
> index 50c8429..520bd39 100644
> --- a/common/command.c
> +++ b/common/command.c
> @@ -185,7 +185,6 @@ static int complete_cmdv(int argc, char * const
> argv[], char last_char, int maxv
>          cmd_tbl_t *cmdtp = ll_entry_start(cmd_tbl_t, cmd);
>          const int count = ll_entry_count(cmd_tbl_t, cmd);
>          const cmd_tbl_t *cmdend = cmdtp + count;
> -       const char *p;
>          int len, clen;
>          int n_found = 0;
>          const char *cmd;
> @@ -224,11 +223,7 @@ static int complete_cmdv(int argc, char * const
> argv[], char last_char, int maxv
>           * Some commands allow length modifiers (like "cp.b");
>           * compare command name only until first dot.
>           */
> -       p = strchr(cmd, '.');
> -       if (p == NULL)
> -               len = strlen(cmd);
> -       else
> -               len = p - cmd;
> +       len = strlen(cmd);
> 
>          /* return the partial matches */
>          for (; cmdtp != cmdend; cmdtp++) {

Could it be that 'cmd' is possibly not zero-terminated string?

Best regards,
Marek Vasut

[U-Boot] U-Boot Bug with newer GCC

[Jeroen Hofstee]

Hello Heiko,

On 02/02/2013 11:18 AM, Jeroen Hofstee wrote:
> Hello,
>
> On 02/02/2013 09:37 AM, Heiko Schocher wrote:
>> Hello Wolfgang, Sebastian,
>>
>> On 01.02.2013 12:31, Wolfgang Denk wrote:
>>> In message 
>>> <E70AF999396FDF4EAE40E195B847096109F5D3A9@SRVEXCH-2K10.CADCON.INTERN> you 
>>> wrote:
>>>> we are using u-boot in our embedded system with arm-1136jfs cpu.
>>> Which exact system / board configuration is this?
>>>
>>> And which exact U-Boot version (git commit ID ?) is it?
>>>
>>>> We recently tried a new toolchain with GCC 4.7.2.
>>>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE 
>>>> isn't working.
>>> We have been using GCC 4.7.2 for several months now, on many systems.
>>> No such problems have been reported before, so I speculate if this is
>>> really a problem with mainline code?
>> Sebastian wrote On 01.02.2013 08:55:
>>> we are using u-boot in our embedded system with arm-1136jfs cpu.
>>> We recently tried a new toolchain with GCC 4.7.2.
>>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE 
>>> isn't working.
>>> U-Boot start normally and on hitting TAB the system freezes.
>>> I tracked the problem down the variables __u_boot_cmd_start and 
>>> __u_boot_cmd_end. Both are not valid with the new toolchain. And 
>>> accessing one results in a system freeze.
>>> Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad 
>>> at linker scripts.
>> I just see some problems with ll_entry_* functions described in my
>> post here:
>> http://lists.denx.de/pipermail/u-boot/2013-February/145711.html
>>
>> I do not know, if this is the same problem, as I face problems only
>> before relocation, after relocation all works fine ...
>>
>> In this thread Marek wrote, that for this problem albert has
>> a solution ... (CCed albert and marek)
>>
>> Albert? Can you help here?
> I am tempted to think that is unrelated. First of all since you encounter
> problems with the 4.6 toolchain. This trap is not present when
> compiling with a 4.6 version (at least not for me).
>
> Second, because I bothered Marex and Albert already with this
> problem on irc and they concluded it could not be ll related.
>
> Third, because dumping the array of commands to a console,
> displays them all correctly.

For completeness, the third statement is wrong. It is only the case
for the working version, the table has incorrect values for
cmdtp->name in current master. So lets hope it is the same problem.
I will wait for Albert his patch and check again. Thanks for the pointer.

Regards,
Jeroen

[U-Boot] U-Boot Bug with newer GCC

[Marek Vasut]

Dear Heiko Schocher,

> Hello Jeroen,
> 
> On 02.02.2013 16:43, Jeroen Hofstee wrote:
> > Hello Heiko,
> > 
> > On 02/02/2013 11:18 AM, Jeroen Hofstee wrote:
> >> Hello,
> >> 
> >> On 02/02/2013 09:37 AM, Heiko Schocher wrote:
> >>> Hello Wolfgang, Sebastian,
> >>> 
> >>> On 01.02.2013 12:31, Wolfgang Denk wrote:
> >>>> In message
> >>>> <E70AF999396FDF4EAE40E195B847096109F5D3A9@SRVEXCH-2K10.CADCON.INTERN>
> >>>> you
> >>>> 
> >>>> wrote:
> >>>>> we are using u-boot in our embedded system with arm-1136jfs cpu.
> >>>> 
> >>>> Which exact system / board configuration is this?
> >>>> 
> >>>> And which exact U-Boot version (git commit ID ?) is it?
> >>>> 
> >>>>> We recently tried a new toolchain with GCC 4.7.2.
> >>>>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE
> >>>>> isn't working.
> >>>> 
> >>>> We have been using GCC 4.7.2 for several months now, on many systems.
> >>>> No such problems have been reported before, so I speculate if this is
> >>>> really a problem with mainline code?
> >>> 
> >>> Sebastian wrote On 01.02.2013 08:55:
> >>>> we are using u-boot in our embedded system with arm-1136jfs cpu.
> >>>> We recently tried a new toolchain with GCC 4.7.2.
> >>>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE
> >>>> isn't working.
> >>>> U-Boot start normally and on hitting TAB the system freezes.
> >>>> I tracked the problem down the variables __u_boot_cmd_start and
> >>>> __u_boot_cmd_end. Both are not valid with the new toolchain. And
> >>>> accessing one results in a system freeze.
> >>>> Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad
> >>>> at linker scripts.
> >>> 
> >>> I just see some problems with ll_entry_* functions described in my
> >>> post here:
> >>> http://lists.denx.de/pipermail/u-boot/2013-February/145711.html
> >>> 
> >>> I do not know, if this is the same problem, as I face problems only
> >>> before relocation, after relocation all works fine ...
> >>> 
> >>> In this thread Marek wrote, that for this problem albert has
> >>> a solution ... (CCed albert and marek)
> >>> 
> >>> Albert? Can you help here?
> >> 
> >> I am tempted to think that is unrelated. First of all since you
> >> encounter problems with the 4.6 toolchain. This trap is not present
> >> when
> >> compiling with a 4.6 version (at least not for me).
> >> 
> >> Second, because I bothered Marex and Albert already with this
> >> problem on irc and they concluded it could not be ll related.
> >> 
> >> Third, because dumping the array of commands to a console,
> >> displays them all correctly.
> > 
> > For completeness, the third statement is wrong. It is only the case
> > for the working version, the table has incorrect values for
> > cmdtp->name in current master. So lets hope it is the same problem.
> > I will wait for Albert his patch and check again. Thanks for the pointer.
> 
> Thanks for the info!
> In the meantime, I also tried with ELDK-5.3 and see the same
> issue (_u_boot_list_try__start is 0 before relocation).

It must be NULL before reloc. Albert rolled out a patch in [1], please give it a 
go. I believe Albert will be sending a followup RFC patch to the ML shortly.

[1] http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/fix-
linker-lists

Best regards,
Marek Vasut

[U-Boot] U-Boot Bug with newer GCC

[Heiko Schocher]

Hello Jeroen,

On 02.02.2013 16:43, Jeroen Hofstee wrote:
> Hello Heiko,
> 
> On 02/02/2013 11:18 AM, Jeroen Hofstee wrote:
>> Hello,
>>
>> On 02/02/2013 09:37 AM, Heiko Schocher wrote:
>>> Hello Wolfgang, Sebastian,
>>>
>>> On 01.02.2013 12:31, Wolfgang Denk wrote:
>>>> In message 
>>>> <E70AF999396FDF4EAE40E195B847096109F5D3A9@SRVEXCH-2K10.CADCON.INTERN> you 
>>>> wrote:
>>>>> we are using u-boot in our embedded system with arm-1136jfs cpu.
>>>> Which exact system / board configuration is this?
>>>>
>>>> And which exact U-Boot version (git commit ID ?) is it?
>>>>
>>>>> We recently tried a new toolchain with GCC 4.7.2.
>>>>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE 
>>>>> isn't working.
>>>> We have been using GCC 4.7.2 for several months now, on many systems.
>>>> No such problems have been reported before, so I speculate if this is
>>>> really a problem with mainline code?
>>> Sebastian wrote On 01.02.2013 08:55:
>>>> we are using u-boot in our embedded system with arm-1136jfs cpu.
>>>> We recently tried a new toolchain with GCC 4.7.2.
>>>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE 
>>>> isn't working.
>>>> U-Boot start normally and on hitting TAB the system freezes.
>>>> I tracked the problem down the variables __u_boot_cmd_start and 
>>>> __u_boot_cmd_end. Both are not valid with the new toolchain. And 
>>>> accessing one results in a system freeze.
>>>> Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad 
>>>> at linker scripts.
>>> I just see some problems with ll_entry_* functions described in my
>>> post here:
>>> http://lists.denx.de/pipermail/u-boot/2013-February/145711.html
>>>
>>> I do not know, if this is the same problem, as I face problems only
>>> before relocation, after relocation all works fine ...
>>>
>>> In this thread Marek wrote, that for this problem albert has
>>> a solution ... (CCed albert and marek)
>>>
>>> Albert? Can you help here?
>> I am tempted to think that is unrelated. First of all since you encounter
>> problems with the 4.6 toolchain. This trap is not present when
>> compiling with a 4.6 version (at least not for me).
>>
>> Second, because I bothered Marex and Albert already with this
>> problem on irc and they concluded it could not be ll related.
>>
>> Third, because dumping the array of commands to a console,
>> displays them all correctly.
> 
> For completeness, the third statement is wrong. It is only the case
> for the working version, the table has incorrect values for
> cmdtp->name in current master. So lets hope it is the same problem.
> I will wait for Albert his patch and check again. Thanks for the pointer.

Thanks for the info!
In the meantime, I also tried with ELDK-5.3 and see the same
issue (_u_boot_list_try__start is 0 before relocation).

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] U-Boot Bug with newer GCC

[Jeroen Hofstee]

Hello,

On 02/02/2013 04:43 PM, Jeroen Hofstee wrote:
>
>>> Sebastian wrote On 01.02.2013 08:55:
>>>> we are using u-boot in our embedded system with arm-1136jfs cpu.
>>>> We recently tried a new toolchain with GCC 4.7.2.
>>>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE 
>>>> isn't working.
>>>
>> I am tempted to think that is unrelated. First of all since you 
>> encounter
>> problems with the 4.6 toolchain. This trap is not present when
>> compiling with a 4.6 version (at least not for me).
>>
Well, that turned out to be wrong, don't know exactly why, but it
is related. Perhaps because it is not a toolchain issue I took it for,
but slightly different placement between the different compiler
versions.
>> Second, because I bothered Marex and Albert already with this
>> problem on irc and they concluded it could not be ll related.
>>
It might be that code running before relocation could corrupt
the data used after relocation. Which would flaw the argument,
"after relocation ll should be fine".
>> Third, because dumping the array of commands to a console,
>> displays them all correctly.
>
> For completeness, the third statement is wrong. It is only the case
> for the working version, the table has incorrect values for
> cmdtp->name in current master. So lets hope it is the same problem.
> I will wait for Albert his patch and check again. Thanks for the pointer.
>
So it seems to be, that patch at least solves this issue.
Sebastian: can you check if this is resolved also resolved for your board
after applying http://patchwork.ozlabs.org/patch/217695/

Regards,
Jeroen

[U-Boot] U-Boot Bug with newer GCC

[Wolfgang Denk]

Dear Jeroen Hofstee,

In message <510D1D1E.7080705@myspectrum.nl> you wrote:
> 
> yes, it is confusing. The following patch will e.g. make the
> trap go away on the twister. Yet there is nothing wrong with the
> original code it touches (or I fail to see what it is).

Note that your patch breaks commands that use length modifiers ...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
News is what a chap who doesn't care much  about  anything  wants  to
read. And it's only news until he's read it. After that it's dead.
                           - Evelyn Waugh _Scoop_ (1938) bk. 1, ch. 5

[U-Boot] U-Boot Bug with newer GCC

[Wolfgang Denk]

Dear Marek Vasut,

In message <201302021605.21681.marex@denx.de> you wrote:
> 
> Could it be that 'cmd' is possibly not zero-terminated string?

How would that ever happen?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
While most peoples' opinions change, the conviction of their correct-
ness never does.

[U-Boot] U-Boot Bug with newer GCC

[Jeroen Hofstee]

On 02/02/2013 10:22 PM, Wolfgang Denk wrote:
> Dear Jeroen Hofstee,
>
> In message <510D1D1E.7080705@myspectrum.nl> you wrote:
>> yes, it is confusing. The following patch will e.g. make the
>> trap go away on the twister. Yet there is nothing wrong with the
>> original code it touches (or I fail to see what it is).
> Note that your patch breaks commands that use length modifiers ...
>
> Best regards,
>
> Wolfgang Denk
>
I'm aware of that. This is not a patch to be applied, just to illustrate
the weirdness encountered (it explicitly says the code is fine before
this). This is resolved for now, see

http://patchwork.ozlabs.org/patch/217695/

Regards,
Jeroen

[U-Boot] U-Boot Bug with newer GCC

[Priebe, Sebastian]

Hello,

> So it seems to be, that patch at least solves this issue.
> Sebastian: can you check if this is resolved also resolved for your board after applying http://patchwork.ozlabs.org/patch/217695/

Apperently we are still working with v2012.10. Could someone be so kind and provide a patch for v2012.10?
We plan to upgrade to v2013.01, but not before the end of Februay.

> Then this smells like a tool chain issue.  You might contact Pengutronix support for help with their tool chain.

We already asked Pengutronix.
They use barebox with their toolchains and didn't have any problem with their new toolchain, yet.
In their barebox.lds they have:
 __barebox_cmd_start = .;
 __barebox_cmd : { KEEP(*(SORT_BY_NAME(.barebox_cmd*))) }
 __barebox_cmd_end = .;

And they thought
         __u_boot_cmd_start = .;
        .u_boot_cmd : { KEEP(*(.u_boot_cmd)) }
        __u_boot_cmd_end = .;

would solve the problem. But it didn't.

Best regards.
Sebastian




==========================================
CADCON
Ingenieurgesellschaft mbH & Co. KG
Geschaeftsfuehrer: Robert Bauer, Andreas Gundel
Sitz der Gesellschaft: D-86368 Gersthofen
Registergericht: Amtsgericht Augsburg HRA 14521
==========================================
-----Urspr?ngliche Nachricht-----
Von: Jeroen Hofstee [mailto:jeroen at myspectrum.nl]
Gesendet: Samstag, 2. Februar 2013 22:45
An: Wolfgang Denk
Cc: Jeroen Hofstee; Marek Vasut; Heiko Schocher; Priebe, Sebastian; u-boot at lists.denx.de
Betreff: Re: [U-Boot] U-Boot Bug with newer GCC

On 02/02/2013 10:22 PM, Wolfgang Denk wrote:
> Dear Jeroen Hofstee,
>
> In message <510D1D1E.7080705@myspectrum.nl> you wrote:
>> yes, it is confusing. The following patch will e.g. make the trap go
>> away on the twister. Yet there is nothing wrong with the original
>> code it touches (or I fail to see what it is).
> Note that your patch breaks commands that use length modifiers ...
>
> Best regards,
>
> Wolfgang Denk
>
I'm aware of that. This is not a patch to be applied, just to illustrate the weirdness encountered (it explicitly says the code is fine before this). This is resolved for now, see

http://patchwork.ozlabs.org/patch/217695/

Regards,
Jeroen

[U-Boot] U-Boot Bug with newer GCC

[Albert ARIBAUD]

Hi Sebastian,

On Mon, 4 Feb 2013 07:11:30 +0000, "Priebe, Sebastian"
<Sebastian.Priebe@cadcon.de> wrote:

> Hello,
> 
> > So it seems to be, that patch at least solves this issue.
> > Sebastian: can you check if this is resolved also resolved for your board after applying http://patchwork.ozlabs.org/patch/217695/
> 
> Apperently we are still working with v2012.10. Could someone be so kind and provide a patch for v2012.10?
> We plan to upgrade to v2013.01, but not before the end of Februay.

Did you try to 'apply --reject' the patch to 2012.10 and see how this
goes?

> > Then this smells like a tool chain issue.  You might contact Pengutronix support for help with their tool chain.
> 
> We already asked Pengutronix.
> They use barebox with their toolchains and didn't have any problem with their new toolchain, yet.
> In their barebox.lds they have:
>  __barebox_cmd_start = .;
>  __barebox_cmd : { KEEP(*(SORT_BY_NAME(.barebox_cmd*))) }
>  __barebox_cmd_end = .;
> 
> And they thought
>          __u_boot_cmd_start = .;
>         .u_boot_cmd : { KEEP(*(.u_boot_cmd)) }
>         __u_boot_cmd_end = .;
> 
> would solve the problem. But it didn't.

As long as symbols are defined at linker level it won't, I guess. My
patch actively changes the way the commands start and end symbols are
defined.

> Best regards.
> Sebastian

Amicalement,
-- 
Albert.

[U-Boot] U-Boot Bug with newer GCC

[Priebe, Sebastian]

Hello,

> Did you try to 'apply --reject' the patch to 2012.10 and see how this goes?

This only adds a newline in command.c.

Regards,
Sebastian





==========================================
CADCON
Ingenieurgesellschaft mbH & Co. KG
Geschaeftsfuehrer: Robert Bauer, Andreas Gundel
Sitz der Gesellschaft: D-86368 Gersthofen
Registergericht: Amtsgericht Augsburg HRA 14521
==========================================
-----Urspr?ngliche Nachricht-----
Von: Albert ARIBAUD [mailto:albert.u.boot at aribaud.net]
Gesendet: Montag, 4. Februar 2013 09:49
An: Priebe, Sebastian
Cc: Jeroen Hofstee; Wolfgang Denk; Marek Vasut; u-boot at lists.denx.de; Heiko Schocher
Betreff: Re: [U-Boot] U-Boot Bug with newer GCC

Hi Sebastian,

On Mon, 4 Feb 2013 07:11:30 +0000, "Priebe, Sebastian"
<Sebastian.Priebe@cadcon.de> wrote:

> Hello,
>
> > So it seems to be, that patch at least solves this issue.
> > Sebastian: can you check if this is resolved also resolved for your
> > board after applying http://patchwork.ozlabs.org/patch/217695/
>
> Apperently we are still working with v2012.10. Could someone be so kind and provide a patch for v2012.10?
> We plan to upgrade to v2013.01, but not before the end of Februay.

Did you try to 'apply --reject' the patch to 2012.10 and see how this goes?

> > Then this smells like a tool chain issue.  You might contact Pengutronix support for help with their tool chain.
>
> We already asked Pengutronix.
> They use barebox with their toolchains and didn't have any problem with their new toolchain, yet.
> In their barebox.lds they have:
>  __barebox_cmd_start = .;
>  __barebox_cmd : { KEEP(*(SORT_BY_NAME(.barebox_cmd*))) }
> __barebox_cmd_end = .;
>
> And they thought
>          __u_boot_cmd_start = .;
>         .u_boot_cmd : { KEEP(*(.u_boot_cmd)) }
>         __u_boot_cmd_end = .;
>
> would solve the problem. But it didn't.

As long as symbols are defined at linker level it won't, I guess. My patch actively changes the way the commands start and end symbols are defined.

> Best regards.
> Sebastian

Amicalement,
--
Albert.

[U-Boot] U-Boot Bug with newer GCC

[Albert ARIBAUD]

Hi Sebastian,

On Mon, 4 Feb 2013 11:28:26 +0000, "Priebe, Sebastian"
<Sebastian.Priebe@cadcon.de> wrote:

> Hello,
> 
> > Did you try to 'apply --reject' the patch to 2012.10 and see how this goes?
> 
> This only adds a newline in command.c.

Do you mean the only change you see at all is this new line addition? I
suspect there are other changes, which you missed, maybe because they
apply fine. What does a 'git status' produce?

Amicalement,
-- 
Albert.

[U-Boot] U-Boot Bug with newer GCC

[Priebe, Sebastian]

Hello,

> Do you mean the only change you see at all is this new line addition? I suspect there are other changes, which you missed, maybe because they apply fine. What does a 'git status' produce?

We are using svn, not git. There are too many differences. I can't apply the patch. There is no e.g. linker_list.h, etc...
svn status after patching show only command/command.c changed.

Greetings,
Sebastian





==========================================
CADCON
Ingenieurgesellschaft mbH & Co. KG
Geschaeftsfuehrer: Robert Bauer, Andreas Gundel
Sitz der Gesellschaft: D-86368 Gersthofen
Registergericht: Amtsgericht Augsburg HRA 14521
==========================================
-----Urspr?ngliche Nachricht-----
Von: Albert ARIBAUD [mailto:albert.u.boot at aribaud.net]
Gesendet: Montag, 4. Februar 2013 12:36
An: Priebe, Sebastian
Cc: Jeroen Hofstee; Wolfgang Denk; Marek Vasut; u-boot at lists.denx.de; Heiko Schocher
Betreff: Re: [U-Boot] U-Boot Bug with newer GCC

Hi Sebastian,

On Mon, 4 Feb 2013 11:28:26 +0000, "Priebe, Sebastian"
<Sebastian.Priebe@cadcon.de> wrote:

> Hello,
>
> > Did you try to 'apply --reject' the patch to 2012.10 and see how this goes?
>
> This only adds a newline in command.c.

Do you mean the only change you see at all is this new line addition? I suspect there are other changes, which you missed, maybe because they apply fine. What does a 'git status' produce?

Amicalement,
--
Albert.

[U-Boot] U-Boot Bug with newer GCC

[Albert ARIBAUD]

Hi Sebastian,

On Mon, 4 Feb 2013 14:23:17 +0000, "Priebe, Sebastian"
<Sebastian.Priebe@cadcon.de> wrote:

> Hello,
> 
> > Do you mean the only change you see at all is this new line addition? I suspect there are other changes, which you missed, maybe because they apply fine. What does a 'git status' produce?
> 
> We are using svn, not git. There are too many differences. I can't apply the patch. There is no e.g. linker_list.h, etc...
> svn status after patching show only command/command.c changed.

(maybe you should set your mailing tool to wrap at ~70 characters)

If there is no linker_list.h, then the patch is basically not
applicable -- you'd have to hand-port it by manually rewriting the
linker file to include sections instead of defining symbols, something
like

         .u_boot_cmd_start : { KEEP(*(.u_boot_cmd_start)) }
        .u_boot_cmd : { KEEP(*(.u_boot_cmd)) }
         .u_boot_cmd_end : { KEEP(*(.u_boot_cmd_end)) }

And then, somewhere in a C file, define __u_boot_cmd_start
as a 'struct {}' placed in section .u_boot_cmd_start, and
__u_boot_cmd_end as a struct {} placed in section .u_boot_cmd_end.

> Greetings,
> Sebastian

Amicalement,
-- 
Albert.

[U-Boot] U-Boot Bug with newer GCC

[Priebe, Sebastian]

Hello,

> (maybe you should set your mailing tool to wrap at ~70 characters)

Apperently I can't. The mailing tool (MS Outlook) setting are restricted by my companys IT.
I have no "root" rights on my windows machine. I develop only on my linux machine.

> If there is no linker_list.h, then the patch is basically not applicable -- you'd have to hand-port it by manually rewriting the linker file to include sections instead of defining symbols, something like

I will wait until we upgraded to v2013.01 and apply the patch then. The problem seems to be solved, as several mailings said.
I will work with the old toolchain until our upgrade. If the problem still exists after the upgrade I will scream again ;-)

Thanks for the fast support.
Sebastian




==========================================
CADCON
Ingenieurgesellschaft mbH & Co. KG
Geschaeftsfuehrer: Robert Bauer, Andreas Gundel
Sitz der Gesellschaft: D-86368 Gersthofen
Registergericht: Amtsgericht Augsburg HRA 14521
==========================================
-----Urspr?ngliche Nachricht-----
Von: Albert ARIBAUD [mailto:albert.u.boot at aribaud.net]
Gesendet: Montag, 4. Februar 2013 15:32
An: Priebe, Sebastian
Cc: Jeroen Hofstee; Wolfgang Denk; Marek Vasut; u-boot at lists.denx.de; Heiko Schocher
Betreff: Re: [U-Boot] U-Boot Bug with newer GCC

Hi Sebastian,

On Mon, 4 Feb 2013 14:23:17 +0000, "Priebe, Sebastian"
<Sebastian.Priebe@cadcon.de> wrote:

> Hello,
>
> > Do you mean the only change you see at all is this new line addition? I suspect there are other changes, which you missed, maybe because they apply fine. What does a 'git status' produce?
>
> We are using svn, not git. There are too many differences. I can't apply the patch. There is no e.g. linker_list.h, etc...
> svn status after patching show only command/command.c changed.

(maybe you should set your mailing tool to wrap at ~70 characters)

If there is no linker_list.h, then the patch is basically not applicable -- you'd have to hand-port it by manually rewriting the linker file to include sections instead of defining symbols, something like

         .u_boot_cmd_start : { KEEP(*(.u_boot_cmd_start)) }
        .u_boot_cmd : { KEEP(*(.u_boot_cmd)) }
         .u_boot_cmd_end : { KEEP(*(.u_boot_cmd_end)) }

And then, somewhere in a C file, define __u_boot_cmd_start as a 'struct {}' placed in section .u_boot_cmd_start, and __u_boot_cmd_end as a struct {} placed in section .u_boot_cmd_end.

> Greetings,
> Sebastian

Amicalement,
--
Albert.

[U-Boot] U-Boot Bug with newer GCC

[Wolfgang Denk]

Dear "Priebe, Sebastian",

In message <E70AF999396FDF4EAE40E195B847096109F5F87F@SRVEXCH-2K10.CADCON.INTERN> you wrote:
> 
> > (maybe you should set your mailing tool to wrap at ~70 characters)
> 
> Apperently I can't. The mailing tool (MS Outlook) setting are restricted by=
>  my companys IT.
> I have no "root" rights on my windows machine. I develop only on my linux m=
> achine.

Don't use this, then, to communicate with public mailing lists.

There are many other options available, including many free ones.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Software suppliers are trying to make their  software  packages  more
``user-friendly''.  .  .  .  Their best approach, so far, has been to
take all the old brochures, and stamp the words, ``user-friendly'' on
the cover.                                               - Bill Gates