[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] inet_chksum.c misbehaving with compiler optimisation?
From: |
FreeRTOS Info |
Subject: |
Re: [lwip-users] inet_chksum.c misbehaving with compiler optimisation? |
Date: |
Mon, 21 Nov 2011 20:19:37 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 |
Hi Kieran,
On 21/11/2011 19:40, Kieran Mansley wrote:
>
> On 20 Nov 2011, at 22:06, Richard Barry wrote:
>
>> Does this make any sort of sense?
>
> Not really. I can't see how a bug in that code would cause the
> symptoms you describe. My guess is that the optimisation is causing
> a change in timing that leads to some race condition being exposed.
> E.g. if it is running faster there is more chance of packets backing
> up, resulting in a queue that then becomes corrupted. When it was
> running slower the packets never backed up and so there was no queue,
> and no chance for corruption. Unfortunately this means that the file
> being optimised may not have the bug that you're seeing.
I agree it seems unlikely to be something in that file. The file, from
my inspection, is just a stand along C file will a few functions. No
static data, no volatile data.
However, I don't think your suggestion that it might be a speed of
execution issue that is highlighting, rather than causing, an error is
likely either. My rationale being that, I can have optimisation in
*all* files set to -O0 (an there are a lot of files in the project)
except inet_chksum.c, which has -O1, and the problem occurs. Therefore
the application and stack are going to be running at near identical
speed to when everything has -O0. It is only optimisation on that file
that seems to be causing (probably highlighting, rather than causing) a
problem. The inverse is also true, optimising *all* files to the max,
and having inet_chksum.c without optimisation does not show the problem,
and then everything really will be running much faster.
Does the fact that the problem only seems to occur when the data being
transmitted exceeds a single Ethernet frame give any clues as to where
else there could be a problem?
I can try stepping through inet_chksum to see if I can see if an issue
arises, but stepping optimised code, even when optimisation is low, is a
bit tricky.
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.