Re: DJGPP and alignment

Re: DJGPP and alignment

[Mark E.]

> Note for coff-go32.c I made the attached patch relative to my last one.
> 

D'oh! Forgot the ChangeLog for BFD:

1999-07-21 Mark Elbrecht <snowball3@bigfoot.com>

* coff-go32.c (COFF_DEFAULT_SECTION_ALIGNMENT_POWER): 
Define to 4.
* coff-i386.c: Define 
COFF_DEFAULT_SECTION_ALIGNMENT_POWER only if not already 
defined.

--- 
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/

Re: DJGPP and alignment

[Mark E.]

> > Or it would if .ctors and .dtors were not specially handled in
> > coff_new_section_hook in coffcode.h.  So you're OK on constructors and
> > destructors if you do indeed use the section names .ctors and .dtors.
> > 

How about a new define just for the alignment of the .data and .text 
sections (so it can be set to our desired 16 bytes) and let the current 
alignment flag be used for all other sections. Does sound safe 
enough?

Mark

--- 
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/

Re: DJGPP and alignment

[John Marshall]

Richard Henderson writes:
> I fear you're getting yourself into trouble, since there's no
> way to change the section alignment in coff. 

Yeah.  I've just found this out the long hard way.

I've been adding a collect-sections-to-make-data kind of thing to
m68kcoff (it does the same sort of job as .rel.sdata in mipsecoff:
loadtime relocations for data sections).  My data is 10 byte records.
It seems I have three choices:

1.  Admit defeat and pad each record to 12 bytes.
2.  Override coff_new_section_hook like in coff-sh.c.
3.  Add yet another special case for my little section to
    coff_new_section_hook in coffcode.h.

Is there any advice as to the "right way"?  At the moment I'm using #2,
but it feels like overkill, and, for a bfd neophyte like me, it took ages
to figure out.  I feel like maybe the "spirit of coff" is #1.

(Also BTW:
Mark E writes:
> But coff_new_section_hook doesn't mention .idata, perhaps you meant 
> coff_set_alignment_hook?

I also found out the long hard way that coff_set_alignment_hook only
applies when reading in a bfd file.  If you want special alignment
handling for sections created in the linker, I think you want
coff_new_section_hook.  But maybe this isn't your situation.)

    John

Re: DJGPP and alignment

[Ian Lance Taylor]

   From: John Marshall <John_W_Marshall@palm.com>
   Date: Thu, 22 Jul 1999 08:23:26 -0700 (PDT)

   I've been adding a collect-sections-to-make-data kind of thing to
   m68kcoff (it does the same sort of job as .rel.sdata in mipsecoff:
   loadtime relocations for data sections).  My data is 10 byte records.
   It seems I have three choices:

   1.  Admit defeat and pad each record to 12 bytes.
   2.  Override coff_new_section_hook like in coff-sh.c.
   3.  Add yet another special case for my little section to
       coff_new_section_hook in coffcode.h.

   Is there any advice as to the "right way"?  At the moment I'm using #2,
   but it feels like overkill, and, for a bfd neophyte like me, it took ages
   to figure out.  I feel like maybe the "spirit of coff" is #1.

I think the right way is choice 2, as you are doing.

Actually, I think the right way is to switch to ELF, which permits the
alignment to be specified on a section by section basis.

Ian

Re: DJGPP and alignment

[Mark E.]

> Actually, I think the right way is to switch to ELF, which permits the
> alignment to be specified on a section by section basis.
> 

Thank you for answering the question I was going to ask. The subject 
about adding ELF as a non-default target has come up on the list so 
DJGPP folks can experiment with ELF. I'd like to enable it in my tree 
and see how much larger the executables become. 

 From looking over the config files, it looks like an easy thing to do to 
add generic i386 ELF. From looking over gas, it seems like it can 
generate  one object format without having to reconfigure. Did I miss 
something or is there a way I've overlooked? 

Mark 


--- 
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/

Re: DJGPP and alignment

[Ian Lance Taylor]

   From: "Mark E." <snowball3@bigfoot.com>
   Date: Thu, 22 Jul 1999 16:34:05 -0400

    From looking over the config files, it looks like an easy thing to do to 
   add generic i386 ELF. From looking over gas, it seems like it can 
   generate  one object format without having to reconfigure. Did I miss 
   something or is there a way I've overlooked? 

It's easy to add ELF support to BFD, ld, and the binutils proper.
It's not easy to make a single gas binary generate either ELF or COFF.
However, I believe Robert Lipe did have this working for SCO, and his
code is in the tree, so it might be reasonably simple for this
specific combination.

Ian

DJGPP and alignment

[Mark E.]

Hello again,
A consensus of the DJGPP workers has decided that the default 
alignment should be 16 bytes instead of the current 4 bytes since 16 is 
the recommended Intel alignment.

Do I need another to handle the non-BFD case or does this one cover 
it?

Note for coff-go32.c I made the attached patch relative to my last one.

Mark

--- 
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/

Re: DJGPP and alignment

[Donn Terry]

I don't know whether this applies to you guys or not, because
I don't know much about DJGPP, but when I did something similar
for Interix, I found that there was one other required change:
certain sections assume that they are 4 byte aligned, and a
specific override for them is required.  In my case, there's
a test in coff_new_section_hook in coffcode.h that looks to
see if the section is .stabs (etc.) and on NT I had to add
the .idata section to the list.  (I also had to add .pdata,
but that doesn't apply to x86 architectures.)

Hope this is useful, but recognize it might not be relevant.

Donn

Mark E. wrote:
> 
> Hello again,
> A consensus of the DJGPP workers has decided that the default
> alignment should be 16 bytes instead of the current 4 bytes since 16 is
> the recommended Intel alignment.
> 
> Do I need another to handle the non-BFD case or does this one cover
> it?
> 
> Note for coff-go32.c I made the attached patch relative to my last one.
> 
> Mark
> 
> ---
> Mark Elbrecht, snowball3@bigfoot.com
> http://snowball.frogspace.net/
> 
> *** bfd/coff-go32.new   Wed Jul 21 11:56:50 1999
> --- bfd/coff-go32.c     Wed Jul 21 11:52:44 1999
> *************** Foundation, Inc., 59 Temple Place - Suit
> *** 21,26 ****
> --- 21,27 ----
>   #define TARGET_SYM            go32coff_vec
>   #define TARGET_NAME           "coff-go32"
>   #define TARGET_UNDERSCORE     '_'
> + #define COFF_DEFAULT_SECTION_ALIGNMENT_POWER (4)
>   #define COFF_LONG_SECTION_NAMES
>   #define COFF_SUPPORT_GNU_LINKONCE
> 
> *** coff-i386.c 1999/07/19 14:55:15     1.3
> --- coff-i386.c 1999/07/21 15:58:14
> *************** static reloc_howto_type *coff_i386_rtype
> *** 45,51 ****
> --- 45,54 ----
> 
>            bfd_vma *));
> 
> + #ifndef COFF_DEFAULT_SECTION_ALIGNMENT_POWER
>   #define COFF_DEFAULT_SECTION_ALIGNMENT_POWER (2)
> + #endif
> +
>   /* The page size is a guess based on ELF.  */
> 
>   #define COFF_PAGE_SIZE 0x1000
> *** bfd/coff-go32.new   Wed Jul 21 11:56:50 1999
> --- bfd/coff-go32.c     Wed Jul 21 12:02:36 1999
> ***************
> *** 1,5 ****
>   /* BFD back-end for Intel 386 COFF files (go32 variant).
> !    Copyright 1990, 1991, 1992, 1993, 1994 Free Software Foundation,
> Inc.
>      Written by DJ Delorie.
> 
>   This file is part of BFD, the Binary File Descriptor library.
> --- 1,5 ----
>   /* BFD back-end for Intel 386 COFF files (go32 variant).
> !    Copyright 1990, 1991, 1992, 1993, 1994, 1999 Free Software
> Foundation, Inc.
>      Written by DJ Delorie.
> 
>   This file is part of BFD, the Binary File Descriptor library.
> *************** Foundation, Inc., 59 Temple Place - Suit
> *** 21,26 ****
> --- 21,27 ----
>   #define TARGET_SYM            go32coff_vec
>   #define TARGET_NAME           "coff-go32"
>   #define TARGET_UNDERSCORE     '_'
> + #define COFF_DEFAULT_SECTION_ALIGNMENT_POWER (4)
>   #define COFF_LONG_SECTION_NAMES
>   #define COFF_SUPPORT_GNU_LINKONCE
> 

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: DJGPP and alignment

[Mark E.]

> specific override for them is required.  In my case, there's
> a test in coff_new_section_hook in coffcode.h that looks to
> see if the section is .stabs (etc.) and on NT I had to add
> the .idata section to the list.  (I also had to add .pdata,
> but that doesn't apply to x86 architectures.)
> 

Thanks for bringing this to my attention, I hadn't noticed it. But 
coff_new_section_hook doesn't mention .idata, perhaps you meant 
coff_set_alignment_hook?

--- 
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/

Re: DJGPP and alignment

[Richard Henderson]

On Wed, Jul 21, 1999 at 12:07:18PM -0400, Mark E. wrote:
> A consensus of the DJGPP workers has decided that the default 
> alignment should be 16 bytes instead of the current 4 bytes since 16 is 
> the recommended Intel alignment.

I fear you're getting yourself into trouble, since there's no
way to change the section alignment in coff. 

If you do any sort of collect-sections-to-make-data kinds of
things like .ctors or .dtors, that'll break.  Do you know that
you're using collect2 to construct constructor lists?


r~

Re: DJGPP and alignment

[Mark E.]

Hello Richard,

> I fear you're getting yourself into trouble, since there's no
> way to change the section alignment in coff. 

Since the documentation is silent on this, what does 
COFF_DEFAULT_SECTION_ALIGNMENT_POWER do then? My tests 
show it does increase the size of the object files and executables 
accordingly.

> If you do any sort of collect-sections-to-make-data kinds of
> things like .ctors or .dtors, that'll break.  Do you know that
> you're using collect2 to construct constructor lists?

I'm not 100% sure, but I don't think so. The linker script groups them 
together in the .data section and surrounds them with special symbols 
(djgpp_first_ctor, etc.) defined in the script.

Mark

--- 
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/

Re: DJGPP and alignment

[Ian Lance Taylor]

   From: "Mark E." <snowball3@bigfoot.com>
   Date: Wed, 21 Jul 1999 20:30:51 -0400

   > I fear you're getting yourself into trouble, since there's no
   > way to change the section alignment in coff. 

   Since the documentation is silent on this, what does 
   COFF_DEFAULT_SECTION_ALIGNMENT_POWER do then? My tests 
   show it does increase the size of the object files and executables 
   accordingly.

Richard means that COFF can not change the alignment on a section by
section basis (i960 COFF is an exception).  The alignment is fixed to
a specific value: COFF_DEFAULT_SECTION_ALIGNMENT_POWER.

   > If you do any sort of collect-sections-to-make-data kinds of
   > things like .ctors or .dtors, that'll break.  Do you know that
   > you're using collect2 to construct constructor lists?

   I'm not 100% sure, but I don't think so. The linker script groups them 
   together in the .data section and surrounds them with special symbols 
   (djgpp_first_ctor, etc.) defined in the script.

Yes, but *(.ctors) in the linker will align each .ctors section in an
input file to COFF_DEFAULT_SECTION_ALIGNMENT_POWER, which will put
unsightly zero values in the .ctors section in the output file.

Or it would if .ctors and .dtors were not specially handled in
coff_new_section_hook in coffcode.h.  So you're OK on constructors and
destructors if you do indeed use the section names .ctors and .dtors.

Ian

Re: DJGPP and alignment

[Donn Terry]

Ian Lance Taylor wrote:

>    From: "Mark E." <snowball3@bigfoot.com>
>    Date: Wed, 21 Jul 1999 20:30:51 -0400
>
>    > I fear you're getting yourself into trouble, since there's no
>    > way to change the section alignment in coff.
>
>    Since the documentation is silent on this, what does
>    COFF_DEFAULT_SECTION_ALIGNMENT_POWER do then? My tests
>    show it does increase the size of the object files and executables
>    accordingly.
>
> Richard means that COFF can not change the alignment on a section by
> section basis (i960 COFF is an exception).  The alignment is fixed to
> a specific value: COFF_DEFAULT_SECTION_ALIGNMENT_POWER.

Except for the special cases discussed below.  (And... MS PE format does
have a way to encode the alignment of each section contribution in the
file header, but it's not currently honored by ld.)

>
>
>    > If you do any sort of collect-sections-to-make-data kinds of
>    > things like .ctors or .dtors, that'll break.  Do you know that
>    > you're using collect2 to construct constructor lists?
>
>    I'm not 100% sure, but I don't think so. The linker script groups them
>    together in the .data section and surrounds them with special symbols
>    (djgpp_first_ctor, etc.) defined in the script.
>
> Yes, but *(.ctors) in the linker will align each .ctors section in an
> input file to COFF_DEFAULT_SECTION_ALIGNMENT_POWER, which will put
> unsightly zero values in the .ctors section in the output file.
>
> Or it would if .ctors and .dtors were not specially handled in
> coff_new_section_hook in coffcode.h.  So you're OK on constructors and
> destructors if you do indeed use the section names .ctors and .dtors.
>

To answer Mark's question to me in this context: it's defintely
coff_new_section_hook.
The existing (approved) code handles .stabs,  .ctors and .dtors.  With the
proposed
change (which I otherwise think is a good idea) .idata (and .pdata, if you
care) need
to be added to the list.  In the case of .ctors and .dtors, I think Ian is
right to characterize
the zeros as "unsightly".  For  .idata and .pdata, they're catastrophic.

In the fullness of time, I will submit changes that handle this (if this
doesn't beat me
to it) but it will be a while before I get things into a package that's
going to get approved.

Donn

Re: DJGPP and alignment

[Ian Lance Taylor]

   Date: Wed, 21 Jul 1999 21:23:59 -0600
   From: Donn Terry <donn@verinet.com>

   In the case of .ctors and .dtors, I think Ian is
   right to characterize
   the zeros as "unsightly".  For  .idata and .pdata, they're catastrophic.

Just for the record, I was being facetious.  Zeroes are also
catastrophic in .ctors and .dtors.  The code in gcc's crtbegin file
will call each address in the .ctors section.  If there is a zero
there, it will wind up jumping to the zero address.

Ian

Re: DJGPP and alignment

[Mark E.]

> Or it would if .ctors and .dtors were not specially handled in
> coff_new_section_hook in coffcode.h.  So you're OK on constructors and
> destructors if you do indeed use the section names .ctors and .dtors.
> 

Ouch, we don't. Our linker script has .ctor and .dtor (yep, no 's'). I just 
checked out DJGPP's config files from cvs and sure enough it's .ctor 
and .dtor that are emitted. I suppose either a test for .ctor and .dtor 
would have to be added in the COFF new section hook, or gcc can be 
changed for 3.0 to emit .ctors and .dtors and then fixup the linker script 
so either would work. 

At any rate, I'd like to hear from the DJGPP folks before deciding 
whether or not to proceed with the patch given the conflict.

Mark

--- 
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/

Re: DJGPP and alignment

[Eli Zaretskii]

> I suppose either a test for .ctor and .dtor
> would have to be added in the COFF new section hook, or gcc can be
> changed for 3.0 to emit .ctors and .dtors and then fixup the linker script
> do either would work. 

I prefer the former alternative.  It seems to be easier and has an
advantage of being local to Binutils, unless I'm missing something.

Re: DJGPP and alignment

[Mark E.]

> 
> > I suppose either a test for .ctor and .dtor
> > would have to be added in the COFF new section hook, or gcc can be
> > changed for 3.0 to emit .ctors and .dtors and then fixup the linker script
> > do either would work. 
> 
> I prefer the former alternative.  It seems to be easier and has an
> advantage of being local to Binutils, unless I'm missing something.
> 

Same here. But since the section that needs to be modified has 
patches pending, I going to withdraw my alignment patch for now.

Mark

--- 
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/