From: Ian Lance Taylor <email@example.com>
Subject: Re: .eh_frame problem
Date: Wed, 03 Mar 1999 16:53:00 -0000 [thread overview]
Message-ID: <199903040053.QAA03202@rtl.cygnus.com> (raw)
From: "Mark E." <firstname.lastname@example.org>
Date: Wed, 3 Mar 1999 00:56:54 -0500
Could somebody from binutils read the thread archived at
http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00547.html . It's
a thread about a padding problem with .eh_frame and at least DJGPP.
According to the egcs folks, this problem needs to be solved in gas.
Are they right?
I think it would be more reliable to fix this in gcc, but it could
also be fixed in gas. The basic problem is that gas doesn't know
whether a section contains code or not. Thus it has to guess about
how to align the contents of the section.
I forgot to mention DJGPP (i-pc-msdosdjgpp) uses COFF.
I wonder if .eh_frame should be given flagged like a data section (like
.edata and others are) in sec_to_stype_flags and in
style_to_sec_flags. Then wouldn't .eh_frame be padded with 0x0
instead of 0x90 (NOP) as it currently is?
I doubt it, since I think that djgpp doesn't use BFD_ASSEMBLER. If
you look at gas/config/tc-i386.h at md_maybe_text, you will see how
gas guesses whether to pad with 0x90 or 0.
What does egcs say in the .section directive for .eh_frame for djgpp?
Is there enough information there for the assembler to somehow know
that the section contains data rather than code? If there is, then we
should figure out how to get that information to md_maybe_text, as
should already work for the BFD_ASSEMBLER version of gas.
next prev parent reply other threads:[~1999-03-03 16:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-03-02 21:56 Mark E.
1999-03-03 16:53 ` Ian Lance Taylor [this message]
1999-03-03 21:00 ` Mark E.
1999-03-03 21:15 ` Mark E.
1999-03-04 14:32 ` Ian Lance Taylor
1999-03-03 7:17 Mark E.
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).