Deal with fill value in .bss sections

[dmik]

BSS sections are initialized with zeroes and specifying a non-zero value in .align directives causes latest binutils to barf with this on code generated by GCC:

Warning: ignoring fill value in section `.bss'

The related binutils for OS/2 ticket containing an example and a suggested solution is here: http://trac.netlabs.org/ports/ticket/165.

[psmedley]

I believe the following in emx.h drive this:

/* If defined, a C expression whose value is a string containing the
   assembler operation to identify the following data as
   uninitialized global data.  If not defined, and neither
   `ASM_OUTPUT_BSS' nor `ASM_OUTPUT_ALIGNED_BSS' are defined,
   uninitialized global data will be output in the data section if
   `-fno-common' is passed, otherwise `ASM_OUTPUT_COMMON' will be
   used.  */
#undef BSS_SECTION_ASM_OP
#define BSS_SECTION_ASM_OP              "\t.bss"

&

/* This is how to output an assembler line that says to advance the
   location counter to a multiple of 2**LOG bytes.
   bird: Pad using int 3. */
#undef ASM_OUTPUT_ALIGN
#define ASM_OUTPUT_ALIGN(FILE,LOG) \
    if ((LOG)!=0) fprintf ((FILE), "\t.align %d,0xcc\n", LOG)

[psmedley]

Looks like the padding may be the issue, that's a point of difference compared to other architectures. I'll do some testing over the weekend

[psmedley]

Confirming that changing ASM_OUTPUT_ALIGN to remove the bird changes, ie to

/* This is how to output an assembler line
   that says to advance the location counter
   to a multiple of 2**LOG bytes.  */

#define ASM_OUTPUT_ALIGN(FILE,LOG)	\
  if ((LOG)!=0) fprintf ((FILE), "\t.align %d\n", (LOG))

stops the warning being generated. Now we just need to understand why bird changed the definition away from the "standard" definition

[SilvanScherrer]

the question is also, could it have been like that in the old gcc 335 times.

[psmedley]

@SilvanScherrer yes it is the same in gcc 3.3.5 - that header originates from GCC 3.3.5

[SilvanScherrer]

I more meant, if the origin was like that in 335. As the emx.h is probably a adjusted copy of another .h. And it might well be that back then the .bss was treated different.

[psmedley]

My assumption based on the comment " bird: Pad using int 3." is that he added the 0xcc.

Just confirmed that no other headers include 0xcc in the ASM_OUTPUT_ALIGN definition for GCC 3.3.5