* .eh_frame problem
@ 1999-03-02 21:56 Mark E.
1999-03-03 16:53 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Mark E. @ 1999-03-02 21:56 UTC (permalink / raw)
To: gas2
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?
Mark
---
Mark Elbrecht
snowball3@usa.net http://members.xoom.com/snowball3/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: .eh_frame problem
1999-03-02 21:56 .eh_frame problem Mark E.
@ 1999-03-03 16:53 ` Ian Lance Taylor
1999-03-03 21:00 ` Mark E.
1999-03-03 21:15 ` Mark E.
0 siblings, 2 replies; 6+ messages in thread
From: Ian Lance Taylor @ 1999-03-03 16:53 UTC (permalink / raw)
To: snowball3; +Cc: gas2
From: "Mark E." <snowball3@usa.net>
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[34567]-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.
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: .eh_frame problem
1999-03-03 16:53 ` Ian Lance Taylor
@ 1999-03-03 21:00 ` Mark E.
1999-03-03 21:15 ` Mark E.
1 sibling, 0 replies; 6+ messages in thread
From: Mark E. @ 1999-03-03 21:00 UTC (permalink / raw)
To: gas2
> 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.
The problem does goes away when using BFD_ASSEMBLER gas. But
I'll take a look and see if there is a solution for non-BFD_ASSEMBLER
gas. We'd use BFD_ASSEMBER gas in 2.9.1 but if you'll recall it has
that bug I reported and you fixed in late October where incorrect fixups
are written out making the object files unusable.
Mark
---
Mark Elbrecht
snowball3@usa.net http://members.xoom.com/snowball3/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: .eh_frame problem
1999-03-03 16:53 ` Ian Lance Taylor
1999-03-03 21:00 ` Mark E.
@ 1999-03-03 21:15 ` Mark E.
1999-03-04 14:32 ` Ian Lance Taylor
1 sibling, 1 reply; 6+ messages in thread
From: Mark E. @ 1999-03-03 21:15 UTC (permalink / raw)
To: gas2
> 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.
>
Here's the code:
#ifdef BFD_ASSEMBLER
#define md_maybe_text() \
((bfd_get_section_flags (stdoutput, now_seg) &
SEC_CODE) != 0)
#else
#define md_maybe_text() \
(now_seg != data_section && now_seg !=
bss_section)
#endif
It seems to me, to parallel the BFD_ASSEMBER
version, that the !BFD_ASSEMBER version should
be something like:
#define md_maybe_text() (now_seg ==
text_section)
Mark
---
Mark Elbrecht
snowball3@usa.net http://members.xoom.com/snowball3/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: .eh_frame problem
1999-03-03 21:15 ` Mark E.
@ 1999-03-04 14:32 ` Ian Lance Taylor
0 siblings, 0 replies; 6+ messages in thread
From: Ian Lance Taylor @ 1999-03-04 14:32 UTC (permalink / raw)
To: snowball3; +Cc: gas2
From: "Mark E." <snowball3@usa.net>
Date: Thu, 4 Mar 1999 00:15:52 -0500
Here's the code:
#ifdef BFD_ASSEMBLER
#define md_maybe_text() \
((bfd_get_section_flags (stdoutput, now_seg) &
SEC_CODE) != 0)
#else
#define md_maybe_text() \
(now_seg != data_section && now_seg !=
bss_section)
#endif
It seems to me, to parallel the BFD_ASSEMBER
version, that the !BFD_ASSEMBER version should
be something like:
#define md_maybe_text() (now_seg ==
text_section)
That would not be parallel, since when using COFF or ELF it is
possible for a section other than text_section to contain code. This
will happen if you compile with -ffunction-sections, for example.
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: .eh_frame problem
@ 1999-03-03 7:17 Mark E.
0 siblings, 0 replies; 6+ messages in thread
From: Mark E. @ 1999-03-03 7:17 UTC (permalink / raw)
To: gas2
> 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 forgot to mention DJGPP (i[34567]-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?
Mark
---
Mark Elbrecht
snowball3@usa.net http://members.xoom.com/snowball3/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-03-04 14:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-03-02 21:56 .eh_frame problem Mark E.
1999-03-03 16:53 ` Ian Lance Taylor
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.
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).