* .gnu.linkonce COFF support
@ 1999-07-13 14:42 Mark E.
1999-07-13 14:55 ` Ian Lance Taylor
1999-07-13 18:45 ` DJ Delorie
0 siblings, 2 replies; 8+ messages in thread
From: Mark E. @ 1999-07-13 14:42 UTC (permalink / raw)
To: binutils
Hello Ian and the list,
Some questions about possibilities for DJGPP COFF. Would enabling
.gnu.linkonce.* for DJGPP COFF improve template support much over
what weak symbols do already? This would require enabling the long
section name feature (> 8 characters) , but it can be turned on by one
line.
And from what I can gather from reading the source, existing object
files would still be readable by the new binutils binaries produced (ld,
objdump, etc). without this feature. Did I read correctly? And also new
object files using just short names produced with the long section
name feature would be readable by old binutils binaries?
Mark
---
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: .gnu.linkonce COFF support
1999-07-13 14:42 .gnu.linkonce COFF support Mark E.
@ 1999-07-13 14:55 ` Ian Lance Taylor
1999-07-13 18:45 ` DJ Delorie
1 sibling, 0 replies; 8+ messages in thread
From: Ian Lance Taylor @ 1999-07-13 14:55 UTC (permalink / raw)
To: snowball3; +Cc: binutils
From: "Mark E." <snowball3@bigfoot.com>
Date: Tue, 13 Jul 1999 17:41:22 -0400
Some questions about possibilities for DJGPP COFF. Would enabling
.gnu.linkonce.* for DJGPP COFF improve template support much over
what weak symbols do already?
My understanding is that it would. At least when using ELF, current
g++ generates the required template functions whenever it needs them.
Thus in a final link you may wind up with many copies of a particular
template function. The .gnu.linkonce.* sections are used to throw
away the unnecessary duplicates, resulting in a smaller program.
However, there are other schemes g++ can use to generate template
functions. They all have various disadvantages. The disadvantage of
the ELF scheme is that g++ compiles a bunch of duplicate code you
don't need, so compilations take longer, and also your object files
are bigger; the advantage is that you don't have to think about it,
and your final executable is no larger than it has to be.
I'm not up on all the details. I don't know which scheme is used for
DJGPP.
This would require enabling the long
section name feature (> 8 characters) , but it can be turned on by one
line.
As I recall DJGPP doesn't use BFD_ASSEMBLER, so I think you'll
probably need at least two lines: one in BFD and one in gas.
And from what I can gather from reading the source, existing object
files would still be readable by the new binutils binaries produced (ld,
objdump, etc). without this feature. Did I read correctly? And also new
object files using just short names produced with the long section
name feature would be readable by old binutils binaries?
Yes, this should all be correct. In fact, old binutils binaries
should be able to read new object files with long names, but the long
section names will look funny.
Ian
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: .gnu.linkonce COFF support
1999-07-13 14:42 .gnu.linkonce COFF support Mark E.
1999-07-13 14:55 ` Ian Lance Taylor
@ 1999-07-13 18:45 ` DJ Delorie
1999-07-13 19:20 ` Ian Lance Taylor
1999-07-13 21:22 ` Mark E.
1 sibling, 2 replies; 8+ messages in thread
From: DJ Delorie @ 1999-07-13 18:45 UTC (permalink / raw)
To: snowball3; +Cc: binutils
> Some questions about possibilities for DJGPP COFF. Would enabling
> .gnu.linkonce.* for DJGPP COFF improve template support much over
> what weak symbols do already? This would require enabling the long
> section name feature (> 8 characters) , but it can be turned on by one
> line.
The "long section name feature" is a remnant from PE's specs, and
binutils doesn't implement it properly. The right way is to use a
specially designated symbol (usually the function name's symbol) as
the unique id, not the section name. I would discourage adding broken
support to DJGPP when it needs to be fixed for PE anyway. If you want
to go this route, figure out how to do it the right way (the MS PE
way) so that we won't have to jump through hoops later when the PE
support is fixed.
There are some additional symbol *types* defined for PE that DJGPP
could use to help with templatest, but I've never studied the C++
problems long enough to be sure.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: .gnu.linkonce COFF support
1999-07-13 18:45 ` DJ Delorie
@ 1999-07-13 19:20 ` Ian Lance Taylor
1999-07-14 4:32 ` DJ Delorie
1999-07-13 21:22 ` Mark E.
1 sibling, 1 reply; 8+ messages in thread
From: Ian Lance Taylor @ 1999-07-13 19:20 UTC (permalink / raw)
To: dj; +Cc: snowball3, binutils
Date: Tue, 13 Jul 1999 21:45:49 -0400 (EDT)
From: DJ Delorie <dj@delorie.com>
> Some questions about possibilities for DJGPP COFF. Would enabling
> .gnu.linkonce.* for DJGPP COFF improve template support much over
> what weak symbols do already? This would require enabling the long
> section name feature (> 8 characters) , but it can be turned on by one
> line.
The "long section name feature" is a remnant from PE's specs, and
binutils doesn't implement it properly. The right way is to use a
specially designated symbol (usually the function name's symbol) as
the unique id, not the section name. I would discourage adding broken
support to DJGPP when it needs to be fixed for PE anyway. If you want
to go this route, figure out how to do it the right way (the MS PE
way) so that we won't have to jump through hoops later when the PE
support is fixed.
I'm not sure this is quite right.
The COMDAT section support in the binutils is wrong, and it does work
the way you say.
The long section name support is different and unrelated. As far as I
know, the binutils support long section names as they are used and
generated by the Microsoft tools.
I took Mark's question to be literally about .gnu.linkonce.*, as in
the GNU extension to ELF, which was perhaps an error. It's true that
I wouldn't recommend using PE style COMDAT sections right now, since
that work will change.
Ian
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: .gnu.linkonce COFF support
1999-07-13 19:20 ` Ian Lance Taylor
@ 1999-07-14 4:32 ` DJ Delorie
1999-07-14 17:02 ` Ian Lance Taylor
0 siblings, 1 reply; 8+ messages in thread
From: DJ Delorie @ 1999-07-14 4:32 UTC (permalink / raw)
To: ian; +Cc: snowball3, binutils
> The long section name support is different and unrelated. As far as I
> know, the binutils support long section names as they are used and
> generated by the Microsoft tools.
There are two ways of implementing long section names in COFF: the gnu
way, and the PE way. We got that wrong too. The GNU way is to store
the name in the string table. The PE way is to use multiple auxents.
As far as *using* long section names for various features, that's OK
with me, except for the COMDAT thing.
Not, of course, that I care about what MS's format says, since djgpp
is independent of PE, but I'd hate to see us do the work twice if we
can do it once for both platforms.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: .gnu.linkonce COFF support
1999-07-14 4:32 ` DJ Delorie
@ 1999-07-14 17:02 ` Ian Lance Taylor
1999-07-14 17:04 ` Mark E.
0 siblings, 1 reply; 8+ messages in thread
From: Ian Lance Taylor @ 1999-07-14 17:02 UTC (permalink / raw)
To: dj; +Cc: snowball3, binutils
Date: Wed, 14 Jul 1999 07:32:19 -0400 (EDT)
From: DJ Delorie <dj@delorie.com>
> The long section name support is different and unrelated. As far as I
> know, the binutils support long section names as they are used and
> generated by the Microsoft tools.
There are two ways of implementing long section names in COFF: the gnu
way, and the PE way. We got that wrong too. The GNU way is to store
the name in the string table. The PE way is to use multiple auxents.
As far as *using* long section names for various features, that's OK
with me, except for the COMDAT thing.
I do have some vague memory of that now. The code implemented by the
binutils is the approach described in the Microsoft PE documentation--
I just checked again. But perhaps the Microsoft tools actually do
something different.
Ian
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: .gnu.linkonce COFF support
1999-07-14 17:02 ` Ian Lance Taylor
@ 1999-07-14 17:04 ` Mark E.
0 siblings, 0 replies; 8+ messages in thread
From: Mark E. @ 1999-07-14 17:04 UTC (permalink / raw)
To: Ian Lance Taylor, snowball3, binutils
> I do have some vague memory of that now. The code implemented by the
> binutils is the approach described in the Microsoft PE documentation--
> I just checked again. But perhaps the Microsoft tools actually do
> something different.
My understanding comes from coffcode.h and coffgen.c in bfd.
COFF long section names are enabled by defining
COFF_LONG_SECTION_NAMES. This feature is implemented by
storing the long names in the string table and storing a pointer to the
table entry in the section's name field. I assume this would have to
done in a way compatible with Microsoft since its used with PE
COMDAT. There also seems to be a long filename feature enabled by
COFF_LONG_FILE_NAMES which does much the same thing for the
.file directive.
PE targets define COFF_LONG_SECTION_NAMES because COMDAT
sections need long section names. PE COMDAT seems to do more
than just be a overly complicated way of emulating .gnu.linkonce for
g++, but isn't currently implemented in binutils (as DJ notes).
So it seems PE COMDAT is dependant on having long names, but
long names aren't dependant on PE COMDAT. Therefore, DJGPP
should be able to use long section names in implementing
.gnu.linkonce support without tangling with PE COMDAT?
Mark
---
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: .gnu.linkonce COFF support
1999-07-13 18:45 ` DJ Delorie
1999-07-13 19:20 ` Ian Lance Taylor
@ 1999-07-13 21:22 ` Mark E.
1 sibling, 0 replies; 8+ messages in thread
From: Mark E. @ 1999-07-13 21:22 UTC (permalink / raw)
To: binutils
> The "long section name feature" is a remnant from PE's specs, and
> binutils doesn't implement it properly. The right way is to use a
Ian addressed your concern, so I'll skip it. BTW, if I'm going to enable
long section names, I'll let djgpp-workers know beforehand. I don't the
change, if it even happens, should affect the debuggers since the bytes
in the sections with long section names will be put into the .text and
.data sections by the linker script anyway (once modifed of course).
> There are some additional symbol *types* defined for PE that DJGPP
> could use to help with templatest, but I've never studied the C++
> problems long enough to be sure.
>
Thanks, I'll take a look.
---
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~1999-07-14 17:04 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-07-13 14:42 .gnu.linkonce COFF support Mark E.
1999-07-13 14:55 ` Ian Lance Taylor
1999-07-13 18:45 ` DJ Delorie
1999-07-13 19:20 ` Ian Lance Taylor
1999-07-14 4:32 ` DJ Delorie
1999-07-14 17:02 ` Ian Lance Taylor
1999-07-14 17:04 ` Mark E.
1999-07-13 21:22 ` Mark E.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).