[foreign] RFR: record padding is not emitted correctly

[Maurizio Cimadamore]

On 14/06/18 17:00, Sundararajan Athijegannathan wrote:
> On anon$xyz where xyz is file position: there may be more than one 
> header files jextracted for an application. Should the file name be 
> part of name generated in addition to file position?
We can defo add file name in here

Maurizio
>
> On negative offsets: I think we should throw exception - even if that 
> breaks current test - as binder won't be able to do much with negative 
> offsets anyway.
>
> -Sundar
>
> On 14/06/18, 8:07 PM, Maurizio Cimadamore wrote:
>> Hi,
>> this is an overhaul of how jextract adds padding to record layouts - 
>> the general strategy is this:
>>
>> 1) make sure that fields are emitted at the correct expected offset, 
>> if not , add prefix padding
>> 2) make sure that record size matches the expected one, if not add 
>> trailing padding
>>
>> Note that (1) should onlyy apply to structs, not unions, as for 
>> unions, you always restart from the base offset for each field; so, 
>> assumption is, base offset should already be in sync because of outer 
>> padding (if needed).
>>
>> To get there, the Utils::getRecordLayoutInternal now does a recursive 
>> walk, as anonymous nested records must join the dance too.
>>
>> I also did a followup fix on the patch that Sundar sent yesterday; in 
>> short, using Utils:getIdentifier doesn't always work. For typedefs it 
>> does the right thing, but for anonymous records it just gives a 
>> random blob of text mentioning the source location; I tweaked this so 
>> that if I see that the output contains '::', I generate a synthetic 
>> string "anon$xyz", where xyz is the offset in the source for that 
>> anon record.
>>
>>
>> I also noted that when structs contain incomplete arrays 
>> (e.g.flexible array members), clang fails to return correct offset 
>> for anything inside the struct, and returns -2 instead. Right now I'm 
>> accepting it (as did the old impl, and the one in the nicl branch), 
>> but I believe it would be better to punt with an exception (after all 
>> the generated layout will be all wrong) - but if I do so, the 
>> StructTest, which contains an incomplete array, will fail. Opinions?
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/padding_layout/
>>
>> Cheers
>> Maurizio
>>