No subject
Tue Jul 12 12:13:23 PDT 2011
hinge went down and as a result I went stand still and today finally it got=
repaired so I posting mails now<br><br>Before:- <a href=3D"https://plus.go=
ogle.com/photos/116529244529884985253/albums/posts/5627211613228363730">htt=
ps://plus.google.com/photos/116529244529884985253/albums/posts/562721161322=
8363730</a><br>
After:- <a href=3D"https://plus.google.com/photos/116529244529884985253/alb=
ums/posts/5628545749910118610">https://plus.google.com/photos/1165292445298=
84985253/albums/posts/5628545749910118610</a><br><br><div class=3D"gmail_qu=
ote">
On Tue, Jul 5, 2011 at 12:18 AM, Jamey Sharp <span dir=3D"ltr"><<a href=
=3D"mailto:jamey at minilop.net">jamey at minilop.net</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex;">
<div class=3D"im">On Mon, Jul 04, 2011 at 03:42:24AM +0530, vikash agrawal =
wrote:<br>
> Also it has been long I am trying to patch a bug, I had several discus=
sion<br>
> with pharris ( I apologise for pestering you so much ) over the same. =
I am<br>
> still studying c_client.py and a quick glance of it reveals<br>
> '_c_serialize_helper_insert_ =A0function', with context being =
sizeof, is<br>
> responsible for xcb_str_sizeof in xproto.c. So I believe this might ne=
ed<br>
> some hacks.<br>
> Also, if I am not wrong there is a problem with xcb_str_next with resp=
ect<br>
> master and 1.7, but for this I have a very n00b and basic idea like if=
<br>
> self.c_next_name =3D=3D 'xcb_str_next': # and then necessary c=
onditions of<br>
> _c('whatever'); might solve the purpose. If this feels a way t=
hen can we<br>
> specifically do the same for other buggy issues.<br>
<br>
</div>I'm sorry to say, the problem is not specific to xcb_str_next or =
to<br>
strings at all. The good news is that it should be solvable in a general<br=
>
way, without hacks for specific types. I wrote some about this here:<br>
<br>
<a href=3D"http://lists.freedesktop.org/archives/xcb/2011-March/006837.html=
" target=3D"_blank">http://lists.freedesktop.org/archives/xcb/2011-March/00=
6837.html</a><br>
<br>
Here is a sketch of an algorithm that I believe is correct for<br>
statically computing alignment padding for all X types. I'll use the<br=
>
terms from xcbgen/xtypes.py.<br>
<br>
First, compute the minimum alignment requirement for every type:<br>
<br>
- For every SimpleType and ExprType, including the standard types like<br>
=A0CARD8, the alignment required equals the size of the type, but no more<=
br>
=A0than 4 bytes. So CARD8 needs 1 byte, INT16 needs 2 bytes, FLOAT needs<b=
r>
=A04 bytes, and DOUBLE also needs 4 bytes.<br>
<br>
- For ListTypes, the alignment is the same as the member type's<br>
=A0alignment.<br>
<br>
- Request, Reply, Event, and Error types always have 4-byte alignment.<br>
<br>
- For StructType and UnionType, the alignment is the maximum alignment<br>
=A0needed by any field in the struct or union. So STR, which is a struct<b=
r>
=A0containing a CARD8 and a list of CARD8, only needs 1-byte alignment;<br=
>
=A0but a struct containing an INT16 and a DOUBLE needs 4-byte alignment.<b=
r>
<br>
I haven't thought about the rules for Switch or Bitcase yet.<br>
<br>
I think implementing the above in proto/xcbgen would be a good target<br>
for something to finish by the time of the mid-term review. The rest of<br>
the algorithm is below.<br></blockquote><div><br>I think I have successfull=
y completed till here<br>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;">
<br>
Once you know the alignment of every type, you can insert correct<br>
padding. Only ComplexTypes actually insert padding anywhere.<br></blockquot=
e><div><br>This will require a hack in which source file? c_client.py ?<br>=
[ Before I have thought to write the code in a separate file but couldn'=
;t get any idea on how do I test it ]<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.=
8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
You need to keep track of the byte offset of every field in a complex<br>
type, modulo 4. The first field in a complex type is at offset 0.<br></bloc=
kquote><div><br>How will I know when a type is being instantiated? and what=
is its size?<br>As it will needed to for me to track offset <br>Technicall=
y I plan to use dictionary, with :-<br>
<br>'<name or type >' =3D [ <offset_before_padding>, &l=
t;offset_after_adding_size>, <final_offset>, <offset_of_next_el=
ement> ] <br><br><a href=3D"https://plus.google.com/photos/1165292445298=
84985253/albums/posts/5628547337483047250">https://plus.google.com/photos/1=
16529244529884985253/albums/posts/5628547337483047250</a><br>
<br>and may be, I will use linked list but I am not sure for the LL at this=
point of time<br>but I not able to understand where do I bring this hack t=
o get most of it and I am sure I will have 4-5 errors wrt module.resole() a=
nd etc so how do I cater that<br>
<br>Also can there e a better way for the above<br>=A0<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px=
solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
For each field you add, first check whether its alignment requirements<br>
are met, and if not, insert padding. So if you try to add a CARD16,<br>
which has 2-byte alignment, at offset 1, then you need 1 byte of<br>
padding. To add a CARD32, needing 4-byte alignment, at offset 1, you<br>
need 3 bytes of padding.<br>
<br>
Once you've added any needed padding, add the field itself. Then the ne=
w<br>
byte offset is the old offset, plus the padding, plus the size of the<br>
field, mod 4.<br>
<br>
After you've added all the fields, insert final padding for the<br>
alignment of the ComplexType itself. If this was a struct that had a<br>
CARD32 field in it, or it was a Request/Reply/Event/Error, then you need<br=
>
to make sure the final byte offset, mod 4, is 0. If its maximum<br>
alignment was 2, then the final byte offset mod 2 must be 0. This<br>
ensures that a list of values of this type has correct padding between<br>
the members.<br>
<br>
The spot where this is a little difficult is if the complex type<br>
contains a list or a variable-length structure. The easy case is when a<br>
field has 4-byte alignment: Then you know that no matter what its length<br=
>
turns out to be, afterward the byte offset (mod 4) is always 0.<br>
<br>
Otherwise, the byte offset after adding the field is not a constant, but<br=
>
a (potentially complicated) expression. For example, if the field is a<br>
list of fixed-size members, then you need to add sizeof(member) times<br>
the list's expression. You'll eventually emit these complicated byt=
e<br>
offset expressions into the generated C code, when inserting padding for<br=
>
some following field.<br>
<br>
At that point I think the bug will be fixed, and we'll be quite pleased=
<br>
with your Summer of Code project. :-) But there's one more improvement:=
<br>
<br>
Since we only care about the byte offset mod 4, many complicated byte<br>
offset expressions can be simplified. For example, if there are two<br>
lists of CARD16s in a row that both use the same length expression, then<br=
>
you might construct this byte offset expression:<br>
=A0 =A0 =A0 =A0old_offset + ((2 * length) + (2 * length)) % 4<br>
But that turns out to just equal "old_offset", because (4 * x) % =
4 =3D=3D 0<br>
for all x. This is a generalization of the above case where fields with<br>
4-byte alignment always result in a byte offset of 0.<br>
<br>
I hope that helps!<br>
<font color=3D"#888888">Jamey<br>
</font></blockquote></div><br>Love<br><br>Vikash Agrawal<br>
--00221546fd661bfe4d04a7e43041--
More information about the Xcb
mailing list