Modify the size of the attributes field to comply with msc limitations.

Reduce attributes size to comply with msc limitations.

It turned out that shared verified boot library fails to
work properly when compiled by msc in BIOS environment.

The culprit was identified as failing 64 bit logical
operations by preprocessor. It is probably possible to 
come up with a certain compile flag set to fix the
operations, but it is not easy to modify and control the BIOS
compilation environment.

The alternative solution is to limit the size of the field
in question to 16 bits (especially since this is the only
part of the attributes field which is supposed to be
altered by firmware.

A union is being introduced in firmware/lib/cgptlib/include/gpt.h:GptEntry to allow
accessing the field both as a 64 bit entity and a top
16 bit field. All places where this field is used are
being modified appropriately.

tests/Makefile is being fixed to allow controlling test run
from the top level directory.

Tested by building everything and running tests. 
All tests pass.

[Bill Richardson, 2010-06-19 09:15:48]

I didn't think about it earlier when we were talking about it, but if the
problem is only with the shifting in the preprocessor and not the compiler
itself (which is likely), you should be able to fix it in the header file alone
by just declaring the mask as a numeric constant instead of a shift:

#define MASK 0x00f0000000000000ULL

[vb, 2010-06-19 17:32:45]

On Sat, Jun 19, 2010 at 2:15 AM,  <wfrichar@chromium.org> wrote:
> I didn't think about it earlier when we were talking about it, but if the
> problem is only with the shifting in the preprocessor and not the compiler
> itself (which is likely), you should be able to fix it in the header file
> alone
> by just declaring the mask as a numeric constant instead of a shift:
>
> #define MASK 0x00f0000000000000ULL
>

Ah, a good idea. I did not think about it, but indeed it would be a
much smaller modification (the definitions though would be less
readable). Another advantage of the fix as proposed is that it clearly
defines which part of the 64 bit field can be modified.

I'll let Randall pitch in, if he also thinks the simpler change would
be enough - I'll do it.

>
>
> http://codereview.chromium.org/2799019/show
>

[Randall Spangler, 2010-06-19 18:46:18]

Kelly and I tried defining the mask as Bill suggests, but MSVC was still
unhappy with it.  Silly compiler...

On Sat, Jun 19, 2010 at 10:32 AM, Vadim Bendebury <vbendeb@chromium.org>wrote:

> On Sat, Jun 19, 2010 at 2:15 AM,  <wfrichar@chromium.org> wrote:
> > I didn't think about it earlier when we were talking about it, but if the
> > problem is only with the shifting in the preprocessor and not the
> compiler
> > itself (which is likely), you should be able to fix it in the header file
> > alone
> > by just declaring the mask as a numeric constant instead of a shift:
> >
> > #define MASK 0x00f0000000000000ULL
> >
>
> Ah, a good idea. I did not think about it, but indeed it would be a
> much smaller modification (the definitions though would be less
> readable). Another advantage of the fix as proposed is that it clearly
> defines which part of the 64 bit field can be modified.
>
> I'll let Randall pitch in, if he also thinks the simpler change would
> be enough - I'll do it.
>
> >
> >
> > http://codereview.chromium.org/2799019/show
> >
>

[Randall Spangler, 2010-06-21 15:27:53]

LGTM