Why user/type/role identifiers duplicated to a block/decl's symtab?

Why user/type/role identifiers duplicated to a block/decl's symtab?

[HarryCiao]

[-- Attachment #1.1: Type: text/plain, Size: 864 bytes --]


Hi Joshua and Stephen,

I happened to have one more question about the link & expand process.

Now that once the link process is complete, the base.p_xxx tables would be "complete", that is, it would not only contain all identifiers defined in p_xxx tables of all modules(AKA, the global block of a module), but also all identifiers defined in avrule_decl_t.symtab[] for all block/decl of all modules.

Then, why would we need to duplicate user/role/type identifiers in a block/decl to its counterpart in the base module? Furthermore, why would we have to copy them once again to the out module?

Maybe the answer would be quite obvious, but I may need your hint to break it through :-)

Please also refer to the attached pdf for a picture I've drawn for the copy/merge of symtabs during link & expand.

Many thanks for your time!

Best regards,
Harry 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 1100 bytes --]

[-- Attachment #2: link_expand_graphic.pdf --]
[-- Type: application/pdf, Size: 47109 bytes --]

Re: Why user/type/role identifiers duplicated to a block/decl's symtab?

[Joshua Brindle]

HarryCiao wrote:
> Hi Joshua and Stephen,
> 
> I happened to have one more question about the link & expand process.
> 
> Now that once the link process is complete, the base.p_xxx tables would be 
> "complete", that is, it would not only contain all identifiers defined in p_xxx 
> tables of all modules(AKA, the global block of a module), but also all 
> identifiers defined in avrule_decl_t.symtab[] for all block/decl of all modules.
> 

Sorry for the late response, I think the PDF caused this to go to my spam folder...

It wasn't strictly necessary to have full symbol tables per avrule_block in
order to track declaration and requiring symbols but they were used because the
hash table implementation and all supporting functions were already present in
the library. In retrospect this could be a source of excess memory consumption
and module size on disk but it was simply easier and faster to implement at the
time.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.