L4Re + ARM

Adam Lackorzynski adam at os.inf.tu-dresden.de
Thu Apr 3 22:03:41 CEST 2014


On Wed Apr 02, 2014 at 15:52:19 -0400, Alexis Fajardo Moya wrote:
> Hello,
> El 02/04/14 12:24, Alexis Fajardo Moya escribió:
> >
> >=>=>=> lastmoduleend 0 received from rounded  this_module->end() 0
> Note this output. After move the first module (00, corresponding to fiasco),
> the "end" value of the variable
> 
> this_module
> 
> is 0.
> 
> After many printfs, I (aka. my team) discover the problem in the function
> 
> move_module (l4util_mb_info_t *mbi, int i, Region *from, Region *to, bool overlap_check)
> 
> after execute the sentence
> 
> memmove((void *)to->begin(), (void *)start, size);
> 
> the *begin* and *end* values of the region *to*, originally with values
> 711cf000 and 712256db, turns in 10101464c457f and 0. The *begin* and *end*
> values of the region *from* are set to the corresponding values of the
> region *to*, causing the problem in the assigment to *lastmoduleend*
> variable in the *move_modules* function, making false the comparision

Thanks for the analysis. This is strange because, for example, one of
the parameters is a stack variable and it gets overwritten. However, I
think the copying should be quite safe as there are couple of checks in
there for that reason. As I see you're using gcc-4.6. Would you mind
changing to a different one, such as Linaro's 4.8 version? The 4.6
series seem to contain some surprises sometimes.

http://releases.linaro.org/14.03/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux.tar.xz
(from http://www.linaro.org/downloads/)



Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/



More information about the l4-hackers mailing list