Re: Problematic __attribute__((section(" "))) and gcc alignment

[Mathieu Desnoyers]

* Sam Ravnborg (sam@xxxxxxxxxxxx) wrote:
> On Thu, Jun 21, 2007 at 04:32:36PM -0400, Mathieu Desnoyers wrote:
> > Hi,
> > 
> > I just realized, working on my marker infrastructure, that a lot of 
> > __attribute__((section(" "))) should probably come along with an
> > aligned() attribute. Since there are no data structures of size greater
> > or equal to 32 bytes put in these sections later referred to by
> > __sectionname_start[] and __sectionname_end[], the problem is never
> > encountered (AFAIK). But as soon as these structures will reach 32 bytes
> > in size, things will go ill:
> > 
> > Let's take arch/i386/boot/video.h as an example:
> > 
> > it defines 
> > 
> > struct card_info {
> >         const char *card_name;
> >         int (*set_mode)(struct mode_info *mode);
> >         int (*probe)(void);
> >         struct mode_info *modes;
> >         int nmodes;             /* Number of probed modes so far */
> >         int unsafe;             /* Probing is unsafe, only do after "scan" */
> >         u16 xmode_first;        /* Unprobed modes to try to call anyway */
> >         u16 xmode_n;            /* Size of unprobed mode range */
> > };
> > 
> > Which is 28 bytes in size (so it is ok for now). If one single field is
> > added, gcc will start aligning this structure on 32 bytes boundaries.
> > (see http://gcc.gnu.org/ml/gcc-bugs/1999-11/msg00914.html)
> > 
> > We then have
> > #define __videocard struct card_info __attribute__((section(".videocards")))
> > extern struct card_info video_cards[], video_cards_end[];
> > 
> > Which instructs gcc to put these structures in the .videocards section.
> > The linker scripts arch/i386/boot/setup.ld will assign video_cards and
> > video_cards_end as pointers to the beginning and the end of this
> > section. video_cards[0] is therefore expected to give the first
> > structure in the section.
> 
> The linker will align the start of the section to the biggest alignment
> required by any member in the section. So gcc should tell the linker
> that video_cards needs 32 bytes alignemnt and we are not facing trobles.
> 
> BUT this requires that the labels in the linker script file are
> correct assigned like this:
> 
>  .tracedata : AT(ADDR(.tracedata) - LOAD_OFFSET) {
>         __tracedata_start = .;
>         *(.tracedata)
>         __tracedata_end = .;
>   }
> 
> If the assignment of __tracedata_start was doen just before the .tracedata
> we would not use the alignment imposed by linker and would see the error you describe.
> 

Hi Sam,

I was experiencing problems with my addons to the DATA_DATA macro,
declaring stuff in the .data section. It looked like: 

(vmlinux.lds.h) in -mm :

/* .data section */
#define DATA_DATA                                                       \
        *(.data)                                                        \
        *(.data.init.refok)                                             \
        . = ALIGN(8);                                                  \
        VMLINUX_SYMBOL(__start___markers) = .;                          \
        *(__markers)                                                    \
        VMLINUX_SYMBOL(__stop___markers) = .;

All this is declared within the .data section. However, I could not
declare a different section within this macro, because it is already
placed in a section; i.e.

(arch/i386/vmlinux.lds.S) in -mm :
  . = ALIGN(4096);
  .data : AT(ADDR(.data) - LOAD_OFFSET) {       /* Data */
        DATA_DATA
        CONSTRUCTORS
        } :data

Using . = ALIGN(32); fixed my issue, but I wonder if there would be some
way to express the ".tracedata : AT(ADDR(.tracedata) - LOAD_OFFSET)"
that would automatically take care of alignment within this macro?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/