[review v3] slotinfo in struct dtv_slotinfo_list should be flexible array [BZ #25...

[Sandra Loosemore]

On 11/12/19 11:42 AM, Florian Weimer wrote:
> * Sandra Loosemore:
> 
>> I don't have any state on this particular change or what it is trying to
>> accomplish, but the linker error is the sort of thing that happens when
>> the compiler sees a reference to an object it thinks will be put in the
>> small data section, but the actual definition of the object puts it
>> somewhere else (e.g., because it is too big for small data) -- in this
>> case the .bss section.  Are there conflicting declarations about the
>> size of the object?  If that's unavoidable for some reason, another way
>> to suppress GP-relative addressing on this object would be to give it an
>> explicit .bss section attribute everywhere it's declared.
> 
> Thanks for providing this information.  Here is a small reproducer:
> 
> enum { size = 100 };
> 
> struct flexible
> {
>    int length;
>    int data[];
> };
> 
> struct inflexible
> {
>    int length;
>    int data[size];
> };
> 
> static struct flexible flexible =
>    {
>     .data = { [size - 1] = 0, }
>    };
> 
> static struct inflexible inflexible =
>    {
>     .data = { [size - 1] = 0, }
>    };
> 
> struct flexible *
> get_flexible (void)
> {
>    return &flexible;
> }
> 
> struct inflexible *
> get_inflexible (void)
> {
>    return &inflexible;
> }
> 
> It results in:
> 
> 	.file	"t.c"
> 	.section	.text
> 	.align	2
> 	.global	get_flexible
> 	.type	get_flexible, @function
> get_flexible:
> 	addi	r2, gp, %gprel(flexible)
> 	ret
> 	.size	get_flexible, .-get_flexible
> 	.align	2
> 	.global	get_inflexible
> 	.type	get_inflexible, @function
> get_inflexible:
> 	movhi	r2, %hiadj(inflexible)
> 	addi	r2, r2, %lo(inflexible)
> 	ret
> 	.size	get_inflexible, .-get_inflexible
> 	.section	.bss
> 	.type	inflexible, @object
> 	.size	inflexible, 404
> 	.align	2
> inflexible:
> 	.zero	404
> 	.type	flexible, @object
> 	.size	flexible, 404
> 	.align	2
> flexible:
> 	.zero	404
> 	.ident	"GCC: (GNU) 9.2.1 20191101 [gcc-9-branch revision 277712]"
> 
> I think this shows that the backend uses the static type size (as in
> sizeof) to determine whether an object goes into the small data
> section, not the allocated object size.
> 
> The linker only sees the allocated object size, so it places the
> object wrongly (although it could perhaps do something smarter because
> it can see the relocations).
> 
> If the object is not placed into .bss, the choice of .sdata vs .data
> is also based on the static type size, so that would need fixing too.
> 
> I don't know how to work around that in the source code.  My
> preference would be to fix the backend.  I guess we could back out the
> commit and disable the warning for GCC 10 instead.
> 

OK, having a self-contained test case is very helpful.  I'll take a look 
at fixing this in GCC, although I might not get to it for a few days. 
Probably the solution is to not use GP-relative addressing for any 
object declared with a flexible array member.

-Sandra