Thanks, Eli. Next question is how to get the layout of the original C++ class from LLVM IR? Regards, Hu Hong On 29 December 2016 at 01:57, Friedman, Eli <efriedma at codeaurora.org> wrote:> On 12/28/2016 5:41 AM, Hong Hu via llvm-dev wrote: > > Hi all, > > I'm writing a pass to understand the memory access to C++ class members. > For each GetElementPtr instruction, I check the second index to the class > pointer, to figure out which member it is intended to access. > > However, due to the structure padding, there are some fake members > inserted into the structure. For example, when GEP works on the 5th element > of the padded structure, it may in fact works on the originally 3rd one, if > there are two paddings before the original 3rd member. > > Is there any way to map this "5th" access to the original "3rd" one? For > example, some APIs to tell whether one member is a real member, or a padded > one? > > > I would suggest converting the index of the struct GEP into an offset in > bytes; see StructLayout::getElementOffset. You can then compare that to > the layout of the original C++ class. > > -Eli > > -- > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161229/d782fa4c/attachment.html>
Reid Kleckner via llvm-dev
2016-Dec-29 02:50 UTC
[llvm-dev] Structure Padding and GetElementPtr
Only Clang really knows the original structure layout. You can pass '-Xclang -fdump-record-layouts', though, to see the layout during compilation. The DICompositeType metadata produced when compiling with debug info might contain enough information to describe the original layout. On Wed, Dec 28, 2016 at 6:44 PM, Hong Hu via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Thanks, Eli. > > Next question is how to get the layout of the original C++ class from LLVM > IR? > > Regards, > Hu Hong > > On 29 December 2016 at 01:57, Friedman, Eli <efriedma at codeaurora.org> > wrote: > >> On 12/28/2016 5:41 AM, Hong Hu via llvm-dev wrote: >> >> Hi all, >> >> I'm writing a pass to understand the memory access to C++ class members. >> For each GetElementPtr instruction, I check the second index to the class >> pointer, to figure out which member it is intended to access. >> >> However, due to the structure padding, there are some fake members >> inserted into the structure. For example, when GEP works on the 5th element >> of the padded structure, it may in fact works on the originally 3rd one, if >> there are two paddings before the original 3rd member. >> >> Is there any way to map this "5th" access to the original "3rd" one? For >> example, some APIs to tell whether one member is a real member, or a padded >> one? >> >> >> I would suggest converting the index of the struct GEP into an offset in >> bytes; see StructLayout::getElementOffset. You can then compare that to >> the layout of the original C++ class. >> >> -Eli >> >> -- >> Employee of Qualcomm Innovation Center, Inc. >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >> >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161228/24e3a6e4/attachment.html>
Here is an example:
I can define two classes: A and Apad:
class A {
bool b1, b2;
double d1;
int i1;
};
class Apad {
bool b1, b2;
bool pad1[6];
double d1;
int i1;
bool pad2[4];
};
A and Apad will have the same layout, from the LLVM IR level:
%class.A = type <{ i8, i8, [6 x i8], double, i32, [4 x i8] }>
%class.Apad = type { i8, i8, [6 x i8], double, i32, [4 x i8] }
Regards,
Hu Hong
On 29 December 2016 at 10:44, Hong Hu <huhong789 at gmail.com> wrote:
> Thanks, Eli.
>
> Next question is how to get the layout of the original C++ class from LLVM
> IR?
>
> Regards,
> Hu Hong
>
> On 29 December 2016 at 01:57, Friedman, Eli <efriedma at
codeaurora.org>
> wrote:
>
>> On 12/28/2016 5:41 AM, Hong Hu via llvm-dev wrote:
>>
>> Hi all,
>>
>> I'm writing a pass to understand the memory access to C++ class
members.
>> For each GetElementPtr instruction, I check the second index to the
class
>> pointer, to figure out which member it is intended to access.
>>
>> However, due to the structure padding, there are some fake members
>> inserted into the structure. For example, when GEP works on the 5th
element
>> of the padded structure, it may in fact works on the originally 3rd
one, if
>> there are two paddings before the original 3rd member.
>>
>> Is there any way to map this "5th" access to the original
"3rd" one? For
>> example, some APIs to tell whether one member is a real member, or a
padded
>> one?
>>
>>
>> I would suggest converting the index of the struct GEP into an offset
in
>> bytes; see StructLayout::getElementOffset. You can then compare that
to
>> the layout of the original C++ class.
>>
>> -Eli
>>
>> --
>> Employee of Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161229/6c88824d/attachment.html>
Yes, Reid. I have used these methods to figure out the layout. Now my question is to build a map between the original layout and the new layout. I show one example below. When LLVM IR access the 4th (starting from 0th) member (i32) of the class A, the map will tell that in fact it is accessing the originally 3rd member (i1). Any suggestion? Regards, Hu Hong On 29 December 2016 at 10:50, Reid Kleckner <rnk at google.com> wrote:> Only Clang really knows the original structure layout. You can pass > '-Xclang -fdump-record-layouts', though, to see the layout during > compilation. The DICompositeType metadata produced when compiling with > debug info might contain enough information to describe the original layout. > > On Wed, Dec 28, 2016 at 6:44 PM, Hong Hu via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Thanks, Eli. >> >> Next question is how to get the layout of the original C++ class from >> LLVM IR? >> >> Regards, >> Hu Hong >> >> On 29 December 2016 at 01:57, Friedman, Eli <efriedma at codeaurora.org> >> wrote: >> >>> On 12/28/2016 5:41 AM, Hong Hu via llvm-dev wrote: >>> >>> Hi all, >>> >>> I'm writing a pass to understand the memory access to C++ class members. >>> For each GetElementPtr instruction, I check the second index to the class >>> pointer, to figure out which member it is intended to access. >>> >>> However, due to the structure padding, there are some fake members >>> inserted into the structure. For example, when GEP works on the 5th element >>> of the padded structure, it may in fact works on the originally 3rd one, if >>> there are two paddings before the original 3rd member. >>> >>> Is there any way to map this "5th" access to the original "3rd" one? For >>> example, some APIs to tell whether one member is a real member, or a padded >>> one? >>> >>> >>> I would suggest converting the index of the struct GEP into an offset in >>> bytes; see StructLayout::getElementOffset. You can then compare that >>> to the layout of the original C++ class. >>> >>> -Eli >>> >>> -- >>> Employee of Qualcomm Innovation Center, Inc. >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >>> >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161229/a923b79d/attachment.html>
Daniel Berlin via llvm-dev
2016-Dec-29 03:00 UTC
[llvm-dev] Structure Padding and GetElementPtr
Yes. LLVM types != C++ types. There is no mapping except that produced if you add debug info. On Wed, Dec 28, 2016 at 6:51 PM, Hong Hu via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Here is an example: > > I can define two classes: A and Apad: > > class A { > bool b1, b2; > double d1; > int i1; > }; > > class Apad { > bool b1, b2; > bool pad1[6]; > double d1; > int i1; > bool pad2[4]; > }; > > A and Apad will have the same layout, from the LLVM IR level: > > %class.A = type <{ i8, i8, [6 x i8], double, i32, [4 x i8] }> > %class.Apad = type { i8, i8, [6 x i8], double, i32, [4 x i8] } > > Regards, > Hu Hong > > On 29 December 2016 at 10:44, Hong Hu <huhong789 at gmail.com> wrote: > >> Thanks, Eli. >> >> Next question is how to get the layout of the original C++ class from >> LLVM IR? >> >> Regards, >> Hu Hong >> >> On 29 December 2016 at 01:57, Friedman, Eli <efriedma at codeaurora.org> >> wrote: >> >>> On 12/28/2016 5:41 AM, Hong Hu via llvm-dev wrote: >>> >>> Hi all, >>> >>> I'm writing a pass to understand the memory access to C++ class members. >>> For each GetElementPtr instruction, I check the second index to the class >>> pointer, to figure out which member it is intended to access. >>> >>> However, due to the structure padding, there are some fake members >>> inserted into the structure. For example, when GEP works on the 5th element >>> of the padded structure, it may in fact works on the originally 3rd one, if >>> there are two paddings before the original 3rd member. >>> >>> Is there any way to map this "5th" access to the original "3rd" one? For >>> example, some APIs to tell whether one member is a real member, or a padded >>> one? >>> >>> >>> I would suggest converting the index of the struct GEP into an offset in >>> bytes; see StructLayout::getElementOffset. You can then compare that >>> to the layout of the original C++ class. >>> >>> -Eli >>> >>> -- >>> Employee of Qualcomm Innovation Center, Inc. >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >>> >>> >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161228/0f830944/attachment.html>