* Re: gcc HEAD bad stabs (?)
@ 2003-09-12 18:33 Michael Elizabeth Chastain
0 siblings, 0 replies; 9+ messages in thread
From: Michael Elizabeth Chastain @ 2003-09-12 18:33 UTC (permalink / raw)
To: drow, gdb
drow> I agree that this is a bug. Factorial is not inside of main,
drow> so stabs with its address shouldn't be either.
Thanks. Bugzilla, here I come.
Michael C
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcc HEAD bad stabs (?)
@ 2003-09-13 0:40 Michael Elizabeth Chastain
0 siblings, 0 replies; 9+ messages in thread
From: Michael Elizabeth Chastain @ 2003-09-13 0:40 UTC (permalink / raw)
To: cgf; +Cc: gdb
cgf> You seem to be discounting the impact of email which summarizes a trend.
cgf> Everyone knows that gcc is getting slower and slower, too. There may
cgf> even be bugs filed against that fact. But often when someone posts hard
cgf> facts showing the trend, there is a flurry of interest and activity. I'm
cgf> sure that the gdb community would respond similarly.
You are right; I didn't think of it that way.
I'm still at the annoying stage where I see a problem but I don't
like any suggestions for fixing it, even when I ask for them.
Mmmm, sorry about that.
At least we're all aware there is a problem now; and some specific PR's
are getting fixed in gcc land.
Michael C
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcc HEAD bad stabs (?)
@ 2003-09-13 0:17 Michael Elizabeth Chastain
2003-09-13 0:36 ` Christopher Faylor
0 siblings, 1 reply; 9+ messages in thread
From: Michael Elizabeth Chastain @ 2003-09-13 0:17 UTC (permalink / raw)
To: cgf; +Cc: gdb
cgf> Hmm. Have you considered sending email with a subject like "The
cgf> continual degradation of stabs with gcc" or something like that?
cgf> I'd do it but then someone would ask for details...
Well, gcc has a process in place: I file P1 bugs, I mark them
as "[3.4 regression]", Mark Mitchell in his capacity as release manager
tracks all the regression bugs. We can't really make other people
fix bugs. Look to our own house; the number of open gdb bugs goes up
and up and up.
When the season comes to cut the 3.4 branch I will complain if there
are ANY open debug info regressions at that time. But they are
months away from cutting their branch.
I think we just have to suck it up and accept that gcc HEAD is
dangerously unstable, and keep filing regression bugs. It's dangerous
for anybody to ship a compiler out of gcc HEAD! The gcc 3.3 branch is
healthy and I haven't had trouble with it in the test bed.
Another thing gdb can do is fix some of our tests that fluctuate from
run to run, so that it's easier to tell people "run the gdb test suite
before and after and compare the results". And contribute to Dan
Kegel's crossgcc project so that it does crossgdb as well.
Michael C
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcc HEAD bad stabs (?)
2003-09-13 0:17 Michael Elizabeth Chastain
@ 2003-09-13 0:36 ` Christopher Faylor
0 siblings, 0 replies; 9+ messages in thread
From: Christopher Faylor @ 2003-09-13 0:36 UTC (permalink / raw)
To: Michael Elizabeth Chastain; +Cc: gdb
On Fri, Sep 12, 2003 at 08:17:42PM -0400, Michael Elizabeth Chastain wrote:
>cgf> Hmm. Have you considered sending email with a subject like "The
>cgf> continual degradation of stabs with gcc" or something like that?
>cgf> I'd do it but then someone would ask for details...
>
>Well, gcc has a process in place: I file P1 bugs, I mark them as "[3.4
>regression]", Mark Mitchell in his capacity as release manager tracks
>all the regression bugs. We can't really make other people fix bugs.
>Look to our own house; the number of open gdb bugs goes up and up and
>up.
You seem to be discounting the impact of email which summarizes a trend.
Everyone knows that gcc is getting slower and slower, too. There may
even be bugs filed against that fact. But often when someone posts hard
facts showing the trend, there is a flurry of interest and activity. I'm
sure that the gdb community would respond similarly.
Anyway, you asked for suggestions on what you could do. I responded. I
certainly know how the free software world works and wasn't suggesting
that we could force anyone to do anything.
cgf
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcc HEAD bad stabs (?)
@ 2003-09-12 22:24 Michael Elizabeth Chastain
2003-09-13 0:01 ` Christopher Faylor
0 siblings, 1 reply; 9+ messages in thread
From: Michael Elizabeth Chastain @ 2003-09-12 22:24 UTC (permalink / raw)
To: cgf, gdb
cgf> "again"? When did it stop?
Okay, "again" is not quite what I meant to say. I really meant:
"once again, gcc HEAD has a new bug". I'm starting to expect 1-2
of these per week.
cgf> Things seem to be getting worse and worse.
They are. I'm opening bugs against gcc HEAD faster than the gcc
people are closing them. And I still have several regressions
left over from the April-June period when I wasn't around.
As far as I can see, the only feedback loop for gcc debug info
changes is me running the test suite. Ideas for improving this
welcomed.
Maybe I should set up a separate test bed and spin it
1-2 times per day with gcc HEAD, binutils 2.14, gdb 5.3.91.
Michael C
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcc HEAD bad stabs (?)
2003-09-12 22:24 Michael Elizabeth Chastain
@ 2003-09-13 0:01 ` Christopher Faylor
0 siblings, 0 replies; 9+ messages in thread
From: Christopher Faylor @ 2003-09-13 0:01 UTC (permalink / raw)
To: Michael Elizabeth Chastain; +Cc: gdb
On Fri, Sep 12, 2003 at 06:24:28PM -0400, Michael Elizabeth Chastain wrote:
>cgf> "again"? When did it stop?
>
>Okay, "again" is not quite what I meant to say. I really meant:
>"once again, gcc HEAD has a new bug". I'm starting to expect 1-2
>of these per week.
>
>cgf> Things seem to be getting worse and worse.
>
>They are. I'm opening bugs against gcc HEAD faster than the gcc
>people are closing them. And I still have several regressions
>left over from the April-June period when I wasn't around.
>
>As far as I can see, the only feedback loop for gcc debug info
>changes is me running the test suite. Ideas for improving this
>welcomed.
I think you're providing a valuable service. It's too bad that
generating correct debug info doesn't seem to be a sexy thing to
do, so it ends up getting worse and worse.
Hmm. Have you considered sending email with a subject like "The
continual degradation of stabs with gcc" or something like that?
I'd do it but then someone would ask for details...
cgf
^ permalink raw reply [flat|nested] 9+ messages in thread
* gcc HEAD bad stabs (?)
@ 2003-09-12 8:11 Michael Elizabeth Chastain
2003-09-12 14:33 ` Daniel Jacobowitz
2003-09-12 21:05 ` Christopher Faylor
0 siblings, 2 replies; 9+ messages in thread
From: Michael Elizabeth Chastain @ 2003-09-12 8:11 UTC (permalink / raw)
To: gdb
I think gcc HEAD is emitting bad stabs again,
and need some confirmation before I can file a bug report.
The questionable stabs happen when 'main' calls 'factorial',
but there is no prototype for 'factorial' yet. Here are all
the stabs after the boilerplate stabs. The full source code
and assembly code are at the end of the message.
# some stabs for factorial
.stabs "factorial:F(0,3)",36,0,13,factorial
.stabs "value:p(0,3)",160,0,12,8
.stabs "value:r(0,3)",64,0,12,3
.stabs "",36,0,0,.Lscope0-factorial
# some stabs for main
.stabs "main:F(0,3)",36,0,6,main
.stabs "argc:p(0,3)",160,0,5,8
.stabs "argv:p(0,21)=*(3,36)",160,0,5,12
.stabs "envp:p(0,21)",160,0,5,16
.stabs "/usr/include/stdlib.h",132,0,0,.Ltext1
.stabs "z0.c",132,0,0,.Ltext2
# stray stab for factorial!!
.stabs "factorial:F(0,3)",36,0,13,factorial
# end of main
.stabs "",36,0,0,.Lscope1-main
.stabs "",100,0,0,.Letext
Look at that stray stab for factorial, which occurs just
before the stab for .Lscope1-main!
This causes a subtle problem in gdb. gdb gets a bogus endaddr
for the block with main in it, so find_function_start_sal fails
to adjust for the prologue properly, so the breakpoint at the
beginning of an instruction happens too early. The bad block
probably causes more problems, too.
I searched gcc and isolated the problem to this patch:
Fri Sep 5 07:35:16 CEST 2003 Jan Hubicka <jh@suse.cz>
* opts.c (decode_options): Enable unit-at-a-time at -O2.
* params.def (max-inline-insns-single): Set to 500
(max-inline-insns-auto): Set to 150
* invoke.texi (max-inline-insns-single, max-inline-insns-auto): Update.
It looks like we're getting the first whiff of unit-at-a-time problems.
Most of the gdb test suite runs at -O0 so it won't cover this yet.
Am I right in believing that this is a gcc bug in stabs emitter?
If so, I will file a PR against gcc.
Michael C
=== z0.c
#include <stdio.h>
#include <stdlib.h>
int
main (int argc, char *argv [], char **envp)
{
printf ("%d\n", factorial (atoi ("6")));
return 0;
}
int
factorial (int value)
{
if (value > 1) {
value *= factorial (value - 1);
}
return (value);
}
=== z0.s
=== compiled with: gcc -O2 -gstabs+ -S
.file "z0.c"
.stabs "/berman/home/mgnu/gcc/breako2/",100,0,0,.Ltext0
.stabs "z0.c",100,0,0,.Ltext0
.text
.Ltext0:
.stabs "gcc2_compiled.",60,0,0,0
.stabs "_Bool:t(0,1)=@s8;-16;",128,0,0,0
.stabs "unsigned int:t(0,2)=r(0,2);0000000000000;0037777777777;",128,0,0,0
.stabs "int:t(0,3)=r(0,3);-2147483648;2147483647;",128,0,0,0
.stabs "__builtin_va_list:t(0,4)=*(0,5)=r(0,5);0;127;",128,0,0,0
.stabs "long long unsigned int:t(0,6)=@s64;r(0,6);0000000000000;01777777777777777777777;",128,0,0,0
.stabs "long long int:t(0,7)=@s64;r(0,7);01000000000000000000000;0777777777777777777777;",128,0,0,0
.stabs "long unsigned int:t(0,8)=r(0,8);0000000000000;0037777777777;",128,0,0,0
.stabs "long int:t(0,9)=r(0,9);-2147483648;2147483647;",128,0,0,0
.stabs "complex long double:t(0,10)=R5;24;0;",128,0,0,0
.stabs "complex double:t(0,11)=R4;16;0;",128,0,0,0
.stabs "complex float:t(0,12)=R3;8;0;",128,0,0,0
.stabs "complex int:t(0,13)=s8real:(0,3),0,32;imag:(0,3),32,32;;",128,0,0,0
.stabs "long double:t(0,14)=r(0,3);12;0;",128,0,0,0
.stabs "double:t(0,15)=r(0,3);8;0;",128,0,0,0
.stabs "float:t(0,16)=r(0,3);4;0;",128,0,0,0
.stabs "unsigned char:t(0,17)=@s8;r(0,17);0;255;",128,0,0,0
.stabs "signed char:t(0,18)=@s8;r(0,18);-128;127;",128,0,0,0
.stabs "short unsigned int:t(0,19)=@s16;r(0,19);0;65535;",128,0,0,0
.stabs "short int:t(0,20)=@s16;r(0,20);-32768;32767;",128,0,0,0
.stabs "char:t(0,5)",128,0,0,0
.stabs "/usr/include/stdio.h",130,0,0,0
.stabs "/berman/fsf/shelf/2003-09-05-06-00-00/berman/install/target/native/gcc/gcc-HEAD-binutils-2.14/lib/gcc/i686-pc-linux-gnu/3.4/include/stddef.h",130,0,0,0
.stabs "size_t:t(2,1)=(0,2)",128,0,213,0
.stabn 162,0,0,0
.stabs "/usr/include/bits/types.h",130,0,0,0
.stabs "__u_char:t(3,1)=(0,17)",128,0,32,0
.stabs "__u_short:t(3,2)=(0,19)",128,0,33,0
.stabs "__u_int:t(3,3)=(0,2)",128,0,34,0
.stabs "__u_long:t(3,4)=(0,8)",128,0,35,0
.stabs "__u_quad_t:t(3,5)=(0,6)",128,0,37,0
.stabs "__quad_t:t(3,6)=(0,7)",128,0,38,0
.stabs "__int8_t:t(3,7)=(0,18)",128,0,49,0
.stabs "__uint8_t:t(3,8)=(0,17)",128,0,50,0
.stabs "__int16_t:t(3,9)=(0,20)",128,0,51,0
.stabs "__uint16_t:t(3,10)=(0,19)",128,0,52,0
.stabs "__int32_t:t(3,11)=(0,3)",128,0,53,0
.stabs "__uint32_t:t(3,12)=(0,2)",128,0,54,0
.stabs "__int64_t:t(3,13)=(0,7)",128,0,56,0
.stabs "__uint64_t:t(3,14)=(0,6)",128,0,57,0
.stabs "__qaddr_t:t(3,15)=(3,16)=*(3,6)",128,0,59,0
.stabs "__dev_t:t(3,17)=(3,5)",128,0,61,0
.stabs "__uid_t:t(3,18)=(3,3)",128,0,62,0
.stabs "__gid_t:t(3,19)=(3,3)",128,0,63,0
.stabs "__ino_t:t(3,20)=(3,4)",128,0,64,0
.stabs "__mode_t:t(3,21)=(3,3)",128,0,65,0
.stabs "__nlink_t:t(3,22)=(3,3)",128,0,66,0
.stabs "__off_t:t(3,23)=(0,9)",128,0,67,0
.stabs "__loff_t:t(3,24)=(3,6)",128,0,68,0
.stabs "__pid_t:t(3,25)=(0,3)",128,0,69,0
.stabs "__ssize_t:t(3,26)=(0,3)",128,0,70,0
.stabs "__rlim_t:t(3,27)=(3,4)",128,0,71,0
.stabs "__rlim64_t:t(3,28)=(3,5)",128,0,72,0
.stabs "__id_t:t(3,29)=(3,3)",128,0,73,0
.stabs "__fsid_t:t(3,30)=(3,31)=s8__val:(3,32)=ar(3,33)=r(3,33);0000000000000;0037777777777;;0;1;(0,3),0,64;;",128,0,78,0
.stabs "__daddr_t:t(3,34)=(0,3)",128,0,81,0
.stabs "__caddr_t:t(3,35)=(3,36)=*(0,5)",128,0,82,0
.stabs "__time_t:t(3,37)=(0,9)",128,0,83,0
.stabs "__useconds_t:t(3,38)=(0,2)",128,0,84,0
.stabs "__suseconds_t:t(3,39)=(0,9)",128,0,85,0
.stabs "__swblk_t:t(3,40)=(0,9)",128,0,86,0
.stabs "__clock_t:t(3,41)=(0,9)",128,0,88,0
.stabs "__clockid_t:t(3,42)=(0,3)",128,0,91,0
.stabs "__timer_t:t(3,43)=(0,3)",128,0,94,0
.stabs "__key_t:t(3,44)=(0,3)",128,0,101,0
.stabs "__ipc_pid_t:t(3,45)=(0,19)",128,0,104,0
.stabs "__blksize_t:t(3,46)=(0,9)",128,0,108,0
.stabs "__blkcnt_t:t(3,47)=(0,9)",128,0,113,0
.stabs "__blkcnt64_t:t(3,48)=(3,6)",128,0,114,0
.stabs "__fsblkcnt_t:t(3,49)=(3,4)",128,0,117,0
.stabs "__fsblkcnt64_t:t(3,50)=(3,5)",128,0,118,0
.stabs "__fsfilcnt_t:t(3,51)=(3,4)",128,0,121,0
.stabs "__fsfilcnt64_t:t(3,52)=(3,5)",128,0,122,0
.stabs "__ino64_t:t(3,53)=(3,5)",128,0,125,0
.stabs "__off64_t:t(3,54)=(3,24)",128,0,128,0
.stabs "__t_scalar_t:t(3,55)=(0,9)",128,0,131,0
.stabs "__t_uscalar_t:t(3,56)=(0,8)",128,0,132,0
.stabs "__intptr_t:t(3,57)=(0,3)",128,0,135,0
.stabs "__socklen_t:t(3,58)=(0,2)",128,0,138,0
.stabs "/usr/include/bits/pthreadtypes.h",130,0,0,0
.stabs "/usr/include/bits/sched.h",130,0,0,0
.stabs "__sched_param:T(5,1)=s4__sched_priority:(0,3),0,32;;",128,0,0,0
.stabn 162,0,0,0
.stabs "_pthread_fastlock:T(4,1)=s8__status:(0,9),0,32;__spinlock:(0,3),32,32;;",128,0,0,0
.stabs "_pthread_descr:t(4,2)=(4,3)=*(4,4)=xs_pthread_descr_struct:",128,0,35,0
.stabs "__pthread_attr_s:T(4,5)=s36__detachstate:(0,3),0,32;__schedpolicy:(0,3),32,32;__schedparam:(5,1),64,32;__inheritsched:(0,3),96,32;__scope:(0,3),128,32;__guardsize:(2,1),160,32;__stackaddr_set:(0,3),192,32;__stackaddr:(4,6)=*(4,7)=(4,7),224,32;__stacksize:(2,1),256,32;;",128,0,0,0
.stabs "pthread_attr_t:t(4,8)=(4,5)",128,0,52,0
.stabs "pthread_cond_t:t(4,9)=(4,10)=s12__c_lock:(4,1),0,64;__c_waiting:(4,2),64,32;;",128,0,60,0
.stabs "pthread_condattr_t:t(4,11)=(4,12)=s4__dummy:(0,3),0,32;;",128,0,67,0
.stabs "pthread_key_t:t(4,13)=(0,2)",128,0,70,0
.stabs "pthread_mutex_t:t(4,14)=(4,15)=s24__m_reserved:(0,3),0,32;__m_count:(0,3),32,32;__m_owner:(4,2),64,32;__m_kind:(0,3),96,32;__m_lock:(4,1),128,64;;",128,0,83,0
.stabs "pthread_mutexattr_t:t(4,16)=(4,17)=s4__mutexkind:(0,3),0,32;;",128,0,90,0
.stabs "pthread_once_t:t(4,18)=(0,3)",128,0,94,0
.stabs "pthread_t:t(4,19)=(0,8)",128,0,140,0
.stabn 162,0,0,0
.stabn 162,0,0,0
.stabs "FILE:t(1,1)=(1,2)=xs_IO_FILE:",128,0,46,0
.stabs "__FILE:t(1,3)=(1,2)",128,0,62,0
.stabs "/usr/include/libio.h",130,0,0,0
.stabs "/usr/include/_G_config.h",130,0,0,0
.stabs "/berman/fsf/shelf/2003-09-05-06-00-00/berman/install/target/native/gcc/gcc-HEAD-binutils-2.14/lib/gcc/i686-pc-linux-gnu/3.4/include/stddef.h",130,0,0,0
.stabs "wchar_t:t(8,1)=(0,9)",128,0,325,0
.stabs "wint_t:t(8,2)=(0,2)",128,0,354,0
.stabn 162,0,0,0
.stabs "/usr/include/wchar.h",130,0,0,0
.stabs "__mbstate_t:t(9,1)=(9,2)=s8__count:(0,3),0,32;__value:(9,3)=u4__wch:(8,2),0,32;__wchb:(9,4)=ar(3,33);0;3;(0,5),0,32;;,32,32;;",128,0,79,0
.stabn 162,0,0,0
.stabs "_G_fpos_t:t(7,1)=(7,2)=s12__pos:(3,23),0,32;__state:(9,1),32,64;;",128,0,30,0
.stabs "_G_fpos64_t:t(7,3)=(7,4)=s16__pos:(3,54),0,64;__state:(9,1),64,64;;",128,0,35,0
.stabs "/usr/include/gconv.h",130,0,0,0
.stabs " :T(10,1)=e__GCONV_OK:0,__GCONV_NOCONV:1,__GCONV_NODB:2,__GCONV_NOMEM:3,__GCONV_EMPTY_INPUT:4,__GCONV_FULL_OUTPUT:5,__GCONV_ILLEGAL_INPUT:6,__GCONV_INCOMPLETE_INPUT:7,__GCONV_ILLEGAL_DESCRIPTOR:8,__GCONV_INTERNAL_ERROR:9,;",128,0,0,0
.stabs " :T(10,2)=e__GCONV_IS_LAST:1,__GCONV_IGNORE_ERRORS:2,;",128,0,0,0
.stabs "__gconv_fct:t(10,3)=(10,4)=*(10,5)=f(0,3)",128,0,72,0
.stabs "__gconv_init_fct:t(10,6)=(10,7)=*(10,8)=f(0,3)",128,0,75,0
.stabs "__gconv_end_fct:t(10,9)=(10,10)=*(10,11)=f(4,7)",128,0,76,0
.stabs "__gconv_trans_fct:t(10,12)=(10,13)=*(10,14)=f(0,3)",128,0,85,0
.stabs "__gconv_trans_context_fct:t(10,15)=(10,16)=*(10,17)=f(0,3)",128,0,90,0
.stabs "__gconv_trans_query_fct:t(10,18)=(10,19)=*(10,20)=f(0,3)",128,0,94,0
.stabs "__gconv_trans_init_fct:t(10,21)=(10,22)=*(10,23)=f(0,3)",128,0,97,0
.stabs "__gconv_trans_end_fct:t(10,24)=(10,25)=*(10,26)=f(4,7)",128,0,98,0
.stabs "__gconv_trans_data:T(10,27)=s20__trans_fct:(10,12),0,32;__trans_context_fct:(10,15),32,32;__trans_end_fct:(10,24),64,32;__data:(4,6),96,32;__next:(10,28)=*(10,27),128,32;;",128,0,0,0
.stabs "__gconv_step:T(10,29)=s56__shlib_handle:(10,30)=*(10,31)=xs__gconv_loaded_object:,0,32;__modname:(10,32)=*(10,33)=k(0,5),32,32;__counter:(0,3),64,32;__from_name:(3,36),96,32;__to_name:(3,36),128,32;__fct:(10,3),160,32;__init_fct:(10,6),192,32;__end_fct:(10,9),224,32;__min_needed_from:(0,3),256,32;__max_needed_from:(0,3),288,32;__min_needed_to:(0,3),320,32;__max_needed_to:(0,3),352,32;__stateful:(0,3),384,32;__data:(4,6),416,32;;",128,0,0,0
.stabs "__gconv_step_data:T(10,34)=s36__outbuf:(10,35)=*(0,17),0,32;__outbufend:(10,35),32,32;__flags:(0,3),64,32;__invocation_counter:(0,3),96,32;__internal_use:(0,3),128,32;__statep:(10,36)=*(9,1),160,32;__state:(9,1),192,64;__trans:(10,28),256,32;;",128,0,0,0
.stabs "__gconv_info:T(10,37)=s8__nsteps:(2,1),0,32;__steps:(10,38)=*(10,29),32,32;;",128,0,0,0
.stabs "__gconv_t:t(10,39)=(10,40)=*(10,37)",128,0,173,0
.stabn 162,0,0,0
.stabs "_G_iconv_t:t(7,5)=(7,6)=u44__cd:(10,37),0,64;__combined:(7,7)=s44__cd:(10,37),0,64;__data:(10,34),64,288;;,0,352;;",128,0,53,0
.stabs "_G_int16_t:t(7,8)=(0,20)",128,0,55,0
.stabs "_G_int32_t:t(7,9)=(0,3)",128,0,56,0
.stabs "_G_uint16_t:t(7,10)=(0,19)",128,0,57,0
.stabs "_G_uint32_t:t(7,11)=(0,2)",128,0,58,0
.stabn 162,0,0,0
.stabs "/berman/fsf/shelf/2003-09-05-06-00-00/berman/install/target/native/gcc/gcc-HEAD-binutils-2.14/lib/gcc/i686-pc-linux-gnu/3.4/include/stdarg.h",130,0,0,0
.stabs "__gnuc_va_list:t(11,1)=(0,4)",128,0,43,0
.stabn 162,0,0,0
.stabs "_IO_lock_t:t(6,1)=(4,7)",128,0,172,0
.stabs "_IO_marker:T(6,2)=s12_next:(6,3)=*(6,2),0,32;_sbuf:(6,4)=*(1,2),32,32;_pos:(0,3),64,32;;",128,0,0,0
.stabs "__codecvt_result:T(6,5)=e__codecvt_ok:0,__codecvt_partial:1,__codecvt_error:2,__codecvt_noconv:3,;",128,0,0,0
.stabs "_IO_FILE:T(1,2)=s148_flags:(0,3),0,32;_IO_read_ptr:(3,36),32,32;_IO_read_end:(3,36),64,32;_IO_read_base:(3,36),96,32;_IO_write_base:(3,36),128,32;_IO_write_ptr:(3,36),160,32;_IO_write_end:(3,36),192,32;_IO_buf_base:(3,36),224,32;_IO_buf_end:(3,36),256,32;_IO_save_base:(3,36),288,32;_IO_backup_base:(3,36),320,32;_IO_save_end:(3,36),352,32;_markers:(6,3),384,32;_chain:(6,4),416,32;_fileno:(0,3),448,32;_flags2:(0,3),480,32;_old_offset:(3,23),512,32;_cur_column:(0,19),544,16;_vtable_offset:(0,18),560,8;_shortbuf:(6,6)=ar(3,33);0;0;(0,5),568,8;_lock:(6,7)=*(6,1),576,32;_offset:(3,54),608,64;__pad1:(4,6),672,32;__pad2:(4,6),704,32;_mode:(0,3),736,32;_unused2:(6,8)=ar(3,33);0;51;(0,5),768,416;;",128,0,0,0
.stabs "_IO_FILE:t(6,9)=(1,2)",128,0,327,0
.stabs "__io_read_fn:t(6,10)=(6,11)=f(3,26)",128,0,350,0
.stabs "__io_write_fn:t(6,12)=(6,13)=f(3,26)",128,0,359,0
.stabs "__io_seek_fn:t(6,14)=(6,15)=f(0,3)",128,0,367,0
.stabs "__io_close_fn:t(6,16)=(6,17)=f(0,3)",128,0,370,0
.stabn 162,0,0,0
.stabs "fpos_t:t(1,4)=(7,1)",128,0,88,0
.stabn 162,0,0,0
.stabs "/usr/include/stdlib.h",130,0,0,0
.stabs "div_t:t(12,1)=(12,2)=s8quot:(0,3),0,32;rem:(0,3),32,32;;",128,0,99,0
.stabs "ldiv_t:t(12,3)=(12,4)=s8quot:(0,9),0,32;rem:(0,9),32,32;;",128,0,107,0
.stabs "/usr/include/sys/types.h",130,0,0,0
.stabs "u_char:t(13,1)=(3,1)",128,0,34,0
.stabs "u_short:t(13,2)=(3,2)",128,0,35,0
.stabs "u_int:t(13,3)=(3,3)",128,0,36,0
.stabs "u_long:t(13,4)=(3,4)",128,0,37,0
.stabs "quad_t:t(13,5)=(3,6)",128,0,38,0
.stabs "u_quad_t:t(13,6)=(3,5)",128,0,39,0
.stabs "fsid_t:t(13,7)=(3,30)",128,0,40,0
.stabs "loff_t:t(13,8)=(3,24)",128,0,45,0
.stabs "ino_t:t(13,9)=(3,20)",128,0,49,0
.stabs "dev_t:t(13,10)=(3,17)",128,0,61,0
.stabs "gid_t:t(13,11)=(3,19)",128,0,66,0
.stabs "mode_t:t(13,12)=(3,21)",128,0,71,0
.stabs "nlink_t:t(13,13)=(3,22)",128,0,76,0
.stabs "uid_t:t(13,14)=(3,18)",128,0,81,0
.stabs "off_t:t(13,15)=(3,23)",128,0,87,0
.stabs "pid_t:t(13,16)=(3,25)",128,0,99,0
.stabs "id_t:t(13,17)=(3,29)",128,0,104,0
.stabs "ssize_t:t(13,18)=(3,26)",128,0,109,0
.stabs "daddr_t:t(13,19)=(3,34)",128,0,115,0
.stabs "caddr_t:t(13,20)=(3,35)",128,0,116,0
.stabs "key_t:t(13,21)=(3,44)",128,0,122,0
.stabs "/usr/include/time.h",130,0,0,0
.stabs "time_t:t(14,1)=(3,37)",128,0,76,0
.stabs "clockid_t:t(14,2)=(3,42)",128,0,92,0
.stabs "timer_t:t(14,3)=(3,43)",128,0,104,0
.stabn 162,0,0,0
.stabs "ulong:t(13,22)=(0,8)",128,0,150,0
.stabs "ushort:t(13,23)=(0,19)",128,0,151,0
.stabs "uint:t(13,24)=(0,2)",128,0,152,0
.stabs "int8_t:t(13,25)=(0,18)",128,0,190,0
.stabs "int16_t:t(13,26)=(0,20)",128,0,191,0
.stabs "int32_t:t(13,27)=(0,3)",128,0,192,0
.stabs "int64_t:t(13,28)=(0,7)",128,0,193,0
.stabs "u_int8_t:t(13,29)=(0,17)",128,0,196,0
.stabs "u_int16_t:t(13,30)=(0,19)",128,0,197,0
.stabs "u_int32_t:t(13,31)=(0,2)",128,0,198,0
.stabs "u_int64_t:t(13,32)=(0,6)",128,0,199,0
.stabs "register_t:t(13,33)=(0,3)",128,0,201,0
.stabs "/usr/include/sys/select.h",130,0,0,0
.stabs "/usr/include/bits/sigset.h",130,0,0,0
.stabs "__sig_atomic_t:t(16,1)=(0,3)",128,0,23,0
.stabs "__sigset_t:t(16,2)=(16,3)=s128__val:(16,4)=ar(3,33);0;31;(0,8),0,1024;;",128,0,31,0
.stabn 162,0,0,0
.stabs "sigset_t:t(15,1)=(16,2)",128,0,38,0
.stabs "/usr/include/time.h",130,0,0,0
.stabs "timespec:T(17,1)=s8tv_sec:(3,37),0,32;tv_nsec:(0,9),32,32;;",128,0,0,0
.stabn 162,0,0,0
.stabs "/usr/include/bits/time.h",130,0,0,0
.stabs "timeval:T(18,1)=s8tv_sec:(3,37),0,32;tv_usec:(3,39),32,32;;",128,0,0,0
.stabn 162,0,0,0
.stabs "suseconds_t:t(15,2)=(3,39)",128,0,49,0
.stabs "__fd_mask:t(15,3)=(0,9)",128,0,55,0
.stabs "fd_set:t(15,4)=(15,5)=s128__fds_bits:(15,6)=ar(3,33);0;31;(15,3),0,1024;;",128,0,78,0
.stabs "fd_mask:t(15,7)=(15,3)",128,0,85,0
.stabn 162,0,0,0
.stabs "blkcnt_t:t(13,34)=(3,47)",128,0,230,0
.stabs "fsblkcnt_t:t(13,35)=(3,49)",128,0,234,0
.stabs "fsfilcnt_t:t(13,36)=(3,51)",128,0,238,0
.stabn 162,0,0,0
.stabs "random_data:T(12,5)=s28fptr:(12,6)=*(13,27),0,32;rptr:(12,6),32,32;state:(12,6),64,32;rand_type:(0,3),96,32;rand_deg:(0,3),128,32;rand_sep:(0,3),160,32;end_ptr:(12,6),192,32;;",128,0,0,0
.stabs "drand48_data:T(12,7)=s24__x:(12,8)=ar(3,33);0;2;(0,19),0,48;__old_x:(12,8),48,48;__c:(0,19),96,16;__init:(0,19),112,16;__a:(0,6),128,64;;",128,0,0,0
.stabs "__compar_fn_t:t(12,9)=(12,10)=*(12,11)=f(0,3)",128,0,720,0
.stabn 162,0,0,0
.p2align 4,,15
.stabs "factorial:F(0,3)",36,0,13,factorial
.stabs "value:p(0,3)",160,0,12,8
.globl factorial
.type factorial, @function
factorial:
.stabn 68,0,13,.LM1-factorial
.LM1:
pushl %ebp
movl %esp, %ebp
pushl %ebx
subl $4, %esp
movl 8(%ebp), %ebx
.stabn 68,0,14,.LM2-factorial
.LM2:
cmpl $1, %ebx
jg .L5
.stabn 68,0,18,.LM3-factorial
.LM3:
popl %edx
movl %ebx, %eax
popl %ebx
popl %ebp
ret
.p2align 4,,7
.L5:
.stabn 68,0,15,.LM4-factorial
.LM4:
leal -1(%ebx), %eax
movl %eax, (%esp)
call factorial
.stabn 68,0,18,.LM5-factorial
.LM5:
popl %edx
.stabn 68,0,15,.LM6-factorial
.LM6:
imull %eax, %ebx
.stabn 68,0,18,.LM7-factorial
.LM7:
movl %ebx, %eax
popl %ebx
popl %ebp
ret
.size factorial, .-factorial
.stabs "value:r(0,3)",64,0,12,3
.Lscope0:
.stabs "",36,0,0,.Lscope0-factorial
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "6"
.LC1:
.string "%d\n"
.text
.p2align 4,,15
.stabs "main:F(0,3)",36,0,6,main
.stabs "argc:p(0,3)",160,0,5,8
.stabs "argv:p(0,21)=*(3,36)",160,0,5,12
.stabs "envp:p(0,21)",160,0,5,16
.globl main
.type main, @function
main:
.stabn 68,0,6,.LM8-main
.LM8:
.LBB2:
pushl %ebp
movl %esp, %ebp
subl $24, %esp
andl $-16, %esp
.LBB3:
.LBB4:
.LBB5:
.stabs "/usr/include/stdlib.h",132,0,0,.Ltext1
.Ltext1:
.stabn 68,0,317,.LM9-main
.LM9:
movl $0, 12(%esp)
movl $10, 8(%esp)
movl $0, 4(%esp)
movl $.LC0, (%esp)
call __strtol_internal
.LBE5:
.LBE4:
.LBE3:
.LBE2:
.stabn 68,0,382,.LM10-main
.LM10:
movl %eax, (%esp)
call factorial
movl %eax, 4(%esp)
movl $.LC1, (%esp)
call printf
.stabs "z0.c",132,0,0,.Ltext2
.Ltext2:
.stabn 68,0,9,.LM11-main
.LM11:
leave
xorl %eax, %eax
ret
.size main, .-main
.stabs "factorial:F(0,3)",36,0,13,factorial
.Lscope1:
.stabs "",36,0,0,.Lscope1-main
.text
.stabs "",100,0,0,.Letext
.Letext:
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4 20030905 (experimental)"
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: gcc HEAD bad stabs (?)
2003-09-12 8:11 Michael Elizabeth Chastain
@ 2003-09-12 14:33 ` Daniel Jacobowitz
2003-09-12 21:05 ` Christopher Faylor
1 sibling, 0 replies; 9+ messages in thread
From: Daniel Jacobowitz @ 2003-09-12 14:33 UTC (permalink / raw)
To: gdb
On Fri, Sep 12, 2003 at 04:11:15AM -0400, Michael Elizabeth Chastain wrote:
> I think gcc HEAD is emitting bad stabs again,
> and need some confirmation before I can file a bug report.
>
> The questionable stabs happen when 'main' calls 'factorial',
> but there is no prototype for 'factorial' yet. Here are all
> the stabs after the boilerplate stabs. The full source code
> and assembly code are at the end of the message.
>
> # some stabs for factorial
> .stabs "factorial:F(0,3)",36,0,13,factorial
> .stabs "value:p(0,3)",160,0,12,8
> .stabs "value:r(0,3)",64,0,12,3
> .stabs "",36,0,0,.Lscope0-factorial
> # some stabs for main
> .stabs "main:F(0,3)",36,0,6,main
> .stabs "argc:p(0,3)",160,0,5,8
> .stabs "argv:p(0,21)=*(3,36)",160,0,5,12
> .stabs "envp:p(0,21)",160,0,5,16
> .stabs "/usr/include/stdlib.h",132,0,0,.Ltext1
> .stabs "z0.c",132,0,0,.Ltext2
> # stray stab for factorial!!
> .stabs "factorial:F(0,3)",36,0,13,factorial
> # end of main
> .stabs "",36,0,0,.Lscope1-main
> .stabs "",100,0,0,.Letext
>
> Look at that stray stab for factorial, which occurs just
> before the stab for .Lscope1-main!
>
> This causes a subtle problem in gdb. gdb gets a bogus endaddr
> for the block with main in it, so find_function_start_sal fails
> to adjust for the prologue properly, so the breakpoint at the
> beginning of an instruction happens too early. The bad block
> probably causes more problems, too.
I agree that this is a bug. Factorial is not inside of main, so stabs
with its address shouldn't be either.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcc HEAD bad stabs (?)
2003-09-12 8:11 Michael Elizabeth Chastain
2003-09-12 14:33 ` Daniel Jacobowitz
@ 2003-09-12 21:05 ` Christopher Faylor
1 sibling, 0 replies; 9+ messages in thread
From: Christopher Faylor @ 2003-09-12 21:05 UTC (permalink / raw)
To: gdb
On Fri, Sep 12, 2003 at 04:11:15AM -0400, Michael Elizabeth Chastain wrote:
>I think gcc HEAD is emitting bad stabs again,
"again"? When did it stop? Last time I checked objects built with head
were still screwed up as you reported in another bugzilla. Things seem
to be getting worse and worse.
cgf
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-09-13 0:40 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-12 18:33 gcc HEAD bad stabs (?) Michael Elizabeth Chastain
-- strict thread matches above, loose matches on Subject: below --
2003-09-13 0:40 Michael Elizabeth Chastain
2003-09-13 0:17 Michael Elizabeth Chastain
2003-09-13 0:36 ` Christopher Faylor
2003-09-12 22:24 Michael Elizabeth Chastain
2003-09-13 0:01 ` Christopher Faylor
2003-09-12 8:11 Michael Elizabeth Chastain
2003-09-12 14:33 ` Daniel Jacobowitz
2003-09-12 21:05 ` Christopher Faylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox