--- Comment #23 from pinskia at gcc dot gnu dot org 2009-06-10 16:32
---
*** Bug 40403 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #22 from mark at codesourcery dot com 2008-12-29 23:48 ---
Subject: Re: miscalculation of asm labels with -g3
stsp at users dot sourceforge dot net wrote:
> Can this possibly be solved by emitting
> a warning if the asm in global scope is
> used with -ffunction-sections?
--- Comment #21 from stsp at users dot sourceforge dot net 2008-12-29
22:16 ---
> I agree with Steven that there are some cases (like -ffunction-sections) where
> even popping back from the debug section after generating it doesn't work.
Can this possibly be solved by emitting
a warnin
--- Comment #20 from bonzini at gnu dot org 2008-12-29 12:26 ---
*** Bug 26908 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #19 from mmitchel at gcc dot gnu dot org 2008-12-28 18:41
---
I agree with Steven that there are some cases (like -ffunction-sections) where
even popping back from the debug section after generating it doesn't work.
However, I'm not sure that's a reason not to do it -- redu
--- Comment #18 from pinskia at gcc dot gnu dot org 2008-12-28 14:03
---
> Do you think someone depended himself on -g3 and is not compiling his programs
> with -g[012], so that this gcc behavior is worth keeping?
It just happens to work at -O0, does not mean it is a bug in GCC, likew
--- Comment #17 from stsp at users dot sourceforge dot net 2008-12-28
13:54 ---
> Which part of "...as I don't think people are trying to..." gives you the
> certainty that really "people don't"?
What gives me that certainty is the
fact that this happens only with -g3.
Do you think some
--- Comment #16 from steven at gcc dot gnu dot org 2008-12-28 13:23 ---
In fact, Mark's suggestion wouldn't actually work in all cases. With
-ffunction-sections, your function definition may end up in a section that will
be eliminated by the linker. And if the preceding section was a n
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-28 13:15 ---
Which part of "...as I don't think people are trying to..." gives you the
certainty that really "people don't"?
Anyway, as far as I'm concerned, this is end of discussion. There is nothing
stopping you from working
--- Comment #14 from stsp at users dot sourceforge dot net 2008-12-28
13:04 ---
And what Mark says, is:
---
But, we could make sure that we always pop back from the debug section to
whatever the preceding section was after emitting debug information. That
seems reasonable to me, as I
--- Comment #13 from stsp at users dot sourceforge dot net 2008-12-28
13:03 ---
The problem is that -g and -g3 do
behave differently. You can't break any
code by making -g3 to behave similar to
-g, or can you?
Its exactly the opposite. -g3 breaks
the code that otherwise works fine (dose
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-28 12:51 ---
Undesirable. As Mark already pointed out, we'd probably end up breaking legacy
code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
--- Comment #11 from stsp at users dot sourceforge dot net 2008-12-28
12:33 ---
> but I wouldn't
> want you to expect Mark, nor anyone else, to actually implement that.
Is this because it would be too
much work to implement, or is it
really undesireable?
Just wondering.
--
http://g
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-28 12:20 ---
Re. comment #9
This is imho a bug, but I'd probably just fix it with a small documentation
update. Mark tends to describe the situation as it should be, but I wouldn't
want you to expect Mark, nor anyone else, to ac
--- Comment #9 from stsp at users dot sourceforge dot net 2008-12-28 09:40
---
OK, Andrew, why do you do this?
Mark have confirmed the existance of
the bug here, yet you resolve it as
a duplicate of an INVALID bug.
Why not to fix the -g3 instead of
always closing this?
Anyway, this is t
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-12-28 02:33 ---
*** This bug has been marked as a duplicate of 26908 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from stsp at users dot sourceforge dot net 2008-01-11 22:02
---
Thank you for the prompt reply!
I also think simply changing to the previous
section is the good fix because the main problem,
as I see it, is that the -g3 currently has the
different behaveour than the othe
--- Comment #6 from mmitchel at gcc dot gnu dot org 2008-01-11 21:23
---
I do think this is a bug. It's certainly not going to meet user expectations.
I think this is another case of a GCC extension that could have been
better-designed. If we were starting from scratch, I think sayi
--- Comment #5 from stsp at users dot sourceforge dot net 2008-01-11 20:14
---
Actually I don't believe it is not a bug.
The properly functional code cannot be
miscompiled that easily only because of
the different -g option.
Adding Mark to CC for the final judgement
on this. :)
--
s
--- Comment #4 from stsp at users dot sourceforge dot net 2007-10-29 17:49
---
> Also, even if the asm code is put into
> another section, why it cannot be called
> from there?
This section does not seem to have "a",
so that's why...
But its still nasty that the current
section depends
--- Comment #3 from stsp at users dot sourceforge dot net 2007-10-28 19:25
---
Ohh... thanks for taking a look.
But is it documented anywhere that the
inline asm _must_ specify the section?
I thought the asm code, as well as the
C code, will utilize the .text, unless
the opposite is spe
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-28 18:59 ---
Your inline-asm is incorrect as you did not place the symbol in any section so
it just defaults to what ever section is currently there (which in the -g3 case
is the debugging section).
This corrects the issue:
asm
--- Comment #1 from stsp at users dot sourceforge dot net 2007-10-28 18:55
---
Created an attachment (id=14428)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14428&action=view)
the test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
23 matches
Mail list logo
