* gdb-internal: determining the type of a variable @ 2003-10-02 12:48 Roul Oldenburger 2003-10-02 15:35 ` Elena Zannoni 2003-10-02 15:40 ` Jim Blandy 0 siblings, 2 replies; 7+ messages in thread From: Roul Oldenburger @ 2003-10-02 12:48 UTC (permalink / raw) To: gdb Hello everybody, I hope to find advice here although this might be a gcc or 'stabs debuginformation format' related question. gdb can show lots of information for a variable or instance of a structure type but I need to know where and how it gets it from. Our executables are compiled with at least stabs debuginformation and I use 'objdump --stabs my_exe' to make use of it. The aim is to reconstruct arbitrarily nested structure type descriptions down to their final components. I try doing this by parsing objdump's output. Given the full name of a structure type inlcuding the name of the package where it is defined I will get the description of it. If the components are from other structure types I can determine them quit easily through the given typenumber/-identifier, but if the components are from a traditional basic type or a self-defined basic type I am not able to determine its type clearly. As an example I have the description of a structure 'sonar_description' given in the package 'awu_siso_shared_memory': 73884 LSYM 0 0 00000000 1565985 awu_siso_shared_memory__sonar_description:T(0,426)=s2500status:(0,123),0,8;\ 73885 LSYM 0 0 00000000 1566062 ref_count:(0,5),32,32;id:(0,7),64,32;transmit_method:(0,139),96,8;\ 73886 LSYM 0 0 00000000 1566130 transmit_power_level:(0,397),128,32;measuring_range:(0,382),160,384;\ 73887 LSYM 0 0 00000000 1566200 search_sector:(0,400),544,32;search_rotation:(0,148),576,8;\ 73888 LSYM 0 0 00000000 1566261 cw_pulse:(0,425),608,32;multi_number_of:(0,7),640,32;\ 73889 LSYM 0 0 00000000 1566316 multi_duration_of:(0,33),672,64;; The given information decribes the structure, but if I want to determine of what type the component 'multi_duration_of' is (grep ':t(0,33)=[r|@]'), I will get multiple possibilities - here are some: 210 LSYM 0 71 00000000 8722 awu_common__debug_mode_range___XDLU_1__1:t(0,33)=@s8;r(0,27);1;1; 371 LSYM 0 84 00000000 12939 awu_common__types__nlink_t:t(0,33)=r(0,29);0;-1; 441 LSYM 0 44 00000000 15165 awu_common__stdio__TTstringS2bP1___XDLU_1__71:t(0,33)=r(0,1);1;71; 6592 LSYM 0 120 00000000 184371 system__address:t(0,33)=r(0,33);0;-1; 19690 LSYM 0 109 00000000 425771 duration___XF_1_1000000000:t(0,33)=@s64;r(0,33);01000000000000000000000;0777777777777777777777; 180473 LSYM 0 120 00000000 184371 122185 LSYM 0 100 00000000 2948958 system__secondary_stack__Tmark_idB:t(0,33)=r(0,33);0;-1; 6835 LSYM 0 81 00000000 75724 awu_common__ipc__Tipc_permissionB:t(0,33)=r(0,33);-2147483648;2147483647; In fact the type is duration, but my problem is to distinguish between the different possibilities ... so looking for the typenumber alone is not enough. How does gdb does it?? What am I doing wrong? Probably looking at stabs does not give the right information to do this; or do i misinterpret stabs format? Thanks for any comments and help! Roul Oldenburger ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gdb-internal: determining the type of a variable 2003-10-02 12:48 gdb-internal: determining the type of a variable Roul Oldenburger @ 2003-10-02 15:35 ` Elena Zannoni 2003-10-02 15:40 ` Jim Blandy 1 sibling, 0 replies; 7+ messages in thread From: Elena Zannoni @ 2003-10-02 15:35 UTC (permalink / raw) To: Roul Oldenburger; +Cc: gdb Roul Oldenburger writes: > Hello everybody, > > I hope to find advice here although this might be a gcc or 'stabs > debuginformation format' related question. > > gdb can show lots of information for a variable or instance of a > structure type but I need to know where and how it gets it from. > > Our executables are compiled with at least stabs debuginformation and I > use 'objdump --stabs my_exe' to make use of it. > The aim is to reconstruct arbitrarily nested structure type descriptions > down to their final components. I try doing this by parsing objdump's > output. > > Given the full name of a structure type inlcuding the name of the > package where it is defined I will get the description of it. > If the components are from other structure types I can determine them > quit easily through the given typenumber/-identifier, but if the > components are from a traditional basic type or a self-defined basic > type I am not able to determine its type clearly. > > As an example I have the description of a structure 'sonar_description' > given in the package 'awu_siso_shared_memory': > > 73884 LSYM 0 0 00000000 1565985 > awu_siso_shared_memory__sonar_description:T(0,426)=s2500status:(0,123),0,8;\ > 73885 LSYM 0 0 00000000 1566062 > ref_count:(0,5),32,32;id:(0,7),64,32;transmit_method:(0,139),96,8;\ > 73886 LSYM 0 0 00000000 1566130 > transmit_power_level:(0,397),128,32;measuring_range:(0,382),160,384;\ > 73887 LSYM 0 0 00000000 1566200 > search_sector:(0,400),544,32;search_rotation:(0,148),576,8;\ > 73888 LSYM 0 0 00000000 1566261 > cw_pulse:(0,425),608,32;multi_number_of:(0,7),640,32;\ > 73889 LSYM 0 0 00000000 1566316 > multi_duration_of:(0,33),672,64;; > > The given information decribes the structure, but if I want to determine > of what type the component 'multi_duration_of' is (grep > ':t(0,33)=[r|@]'), I will get multiple possibilities - here are some: > > 210 LSYM 0 71 00000000 8722 > awu_common__debug_mode_range___XDLU_1__1:t(0,33)=@s8;r(0,27);1;1; > 371 LSYM 0 84 00000000 12939 > awu_common__types__nlink_t:t(0,33)=r(0,29);0;-1; > 441 LSYM 0 44 00000000 15165 > awu_common__stdio__TTstringS2bP1___XDLU_1__71:t(0,33)=r(0,1);1;71; > 6592 LSYM 0 120 00000000 184371 > system__address:t(0,33)=r(0,33);0;-1; > 19690 LSYM 0 109 00000000 425771 > duration___XF_1_1000000000:t(0,33)=@s64;r(0,33);01000000000000000000000;0777777777777777777777; > 180473 LSYM 0 120 00000000 184371 > 122185 LSYM 0 100 00000000 2948958 > system__secondary_stack__Tmark_idB:t(0,33)=r(0,33);0;-1; > 6835 LSYM 0 81 00000000 75724 > awu_common__ipc__Tipc_permissionB:t(0,33)=r(0,33);-2147483648;2147483647; > > > In fact the type is duration, but my problem is to distinguish between > the different possibilities ... so looking for the typenumber alone is > not enough. > > How does gdb does it?? I see that Ian answered your questions on the binutils list. As far as how gdb does it, look at stabsread.c, there is a big switch statement that handles the cases. elena > > What am I doing wrong? > > Probably looking at stabs does not give the right information to do > this; or do i misinterpret stabs format? > > Thanks for any comments and help! > > Roul Oldenburger ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gdb-internal: determining the type of a variable 2003-10-02 12:48 gdb-internal: determining the type of a variable Roul Oldenburger 2003-10-02 15:35 ` Elena Zannoni @ 2003-10-02 15:40 ` Jim Blandy 2003-10-06 14:42 ` Roul Oldenburger 1 sibling, 1 reply; 7+ messages in thread From: Jim Blandy @ 2003-10-02 15:40 UTC (permalink / raw) To: Roul Oldenburger; +Cc: gdb Roul Oldenburger <oldenburger.roul@rheinmetall-de.com> writes: > In fact the type is duration, but my problem is to distinguish between > the different possibilities ... so looking for the typenumber alone is > not enough. > > How does gdb does it?? > > What am I doing wrong? First, have you looked at the stabs document? The manual source is in gdb/doc/stabs.texi, and http://sources.redhat.com/gdb/documentation/ has a link to it on-line. However, I don't think that's the clearest description of what's going on. (Hmm, invest 15 minutes explaining it now, which I'll have to repeat the next time someone asks, or days trying to improve stabs.texi? My motto: "Fritter, fritter".) In general, type numbers are only going to be unique within a compilation unit; the stabs for a given compilation unit are delimited by N_SO stabs --- but note that there are also N_SO stabs that just set the working directory. See the stabs document for more details. However, if you see an EXCL stab, then your work is harder. EXCL stabs are produced by the linker when it factors out information repeated in all the .o files it's linking together so it only appears once in the executable. An EXCL stab points back to stabs earlier in the list that also belong in this compilation unit, but have been omitted to save space. The EXCL stuff depends on some trickiness with the type numbers. Originally, stabs type numbers were just that --- numbers --- and they were assigned sequentially. So you'd see something like: LSYM char:t2=r2;0;127; ... PSYM argv:p20=*21=*2 to declare argv's type as 'char **'. This meant that, if the same header file were #included into several compilation units, its types would be assigned whatever numbers came next in the sequence for that compilation unit. This makes it hard to recognize whether the stabs for two #inclusions of a file in different compilation units are really the same or not. But now, type numbers are (FILENUM,TYPENUM) pairs: LSYM char:t(0,2)=r(0,2);0;127; ... PSYM argv:p(10,1)=*(10,2)=*(0,2) Each time we start a new source file for an #inclusion, we assign it a new FILENUM, and start TYPENUM at one again. This means that, if the same header file gets #included into several different compilation units, the likelihood is that the type numbers introduced by that header file will differ only in the file number, not the type numbers, which makes it easier to determine whether the stabs produced by two #inclusions of the same file in two different compilation units are the same or not. The stabs introduced by a header file are bracketed by a BINCL / EINCL pair. If the linker sees a BINCL / EINCL pair where the name of the #included file is the same as some previous BINCL / EINCL pair, and the stabs contained therein differ only in their file numbers, then it replaces the second BINCL / EINCL pair and all the stabs between them with a single EXCL stab, which points back to the first BINCL / EINCL pair. Anyway, if you want to read stabs information in linked programs, not .o files, you'll need to understand that. See dbxread.c and stabsread.c for details. To say much more, I'd just have to refer to them, too. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gdb-internal: determining the type of a variable 2003-10-02 15:40 ` Jim Blandy @ 2003-10-06 14:42 ` Roul Oldenburger 2003-10-06 14:54 ` Daniel Jacobowitz 2003-10-06 21:09 ` Jim Blandy 0 siblings, 2 replies; 7+ messages in thread From: Roul Oldenburger @ 2003-10-06 14:42 UTC (permalink / raw) To: Jim Blandy; +Cc: gdb Thanks for your effort giving me your explanation! Looking at the stabs information from our executables which are linked from several o-files I find FILENUM being 0 for all typedescriptions. Probably I could distinguish between the duplicate descriptions if FILNUM would differ. Unfortunately I don't know why it is 0 all the way? Roul Jim Blandy wrote: > Roul Oldenburger <oldenburger.roul@rheinmetall-de.com> writes: > >>In fact the type is duration, but my problem is to distinguish between >>the different possibilities ... so looking for the typenumber alone is >>not enough. >> >>How does gdb does it?? >> >>What am I doing wrong? > > > First, have you looked at the stabs document? The manual source is in > gdb/doc/stabs.texi, and http://sources.redhat.com/gdb/documentation/ > has a link to it on-line. > > However, I don't think that's the clearest description of what's going > on. (Hmm, invest 15 minutes explaining it now, which I'll have to > repeat the next time someone asks, or days trying to improve > stabs.texi? My motto: "Fritter, fritter".) > > In general, type numbers are only going to be unique within a > compilation unit; the stabs for a given compilation unit are delimited > by N_SO stabs --- but note that there are also N_SO stabs that just > set the working directory. See the stabs document for more details. > > However, if you see an EXCL stab, then your work is harder. EXCL > stabs are produced by the linker when it factors out information > repeated in all the .o files it's linking together so it only appears > once in the executable. An EXCL stab points back to stabs earlier in > the list that also belong in this compilation unit, but have been > omitted to save space. > > The EXCL stuff depends on some trickiness with the type numbers. > Originally, stabs type numbers were just that --- numbers --- and they > were assigned sequentially. So you'd see something like: > > LSYM char:t2=r2;0;127; > ... > PSYM argv:p20=*21=*2 > > to declare argv's type as 'char **'. This meant that, if the same > header file were #included into several compilation units, its types > would be assigned whatever numbers came next in the sequence for that > compilation unit. This makes it hard to recognize whether the stabs > for two #inclusions of a file in different compilation units are > really the same or not. > > But now, type numbers are (FILENUM,TYPENUM) pairs: > > LSYM char:t(0,2)=r(0,2);0;127; > ... > PSYM argv:p(10,1)=*(10,2)=*(0,2) > > Each time we start a new source file for an #inclusion, we assign it a > new FILENUM, and start TYPENUM at one again. This means that, if the > same header file gets #included into several different compilation > units, the likelihood is that the type numbers introduced by that > header file will differ only in the file number, not the type > numbers, which makes it easier to determine whether the stabs produced > by two #inclusions of the same file in two different compilation units > are the same or not. > > The stabs introduced by a header file are bracketed by a BINCL / EINCL > pair. If the linker sees a BINCL / EINCL pair where the name of the > #included file is the same as some previous BINCL / EINCL pair, and > the stabs contained therein differ only in their file numbers, then it > replaces the second BINCL / EINCL pair and all the stabs between them > with a single EXCL stab, which points back to the first BINCL / EINCL > pair. > > Anyway, if you want to read stabs information in linked programs, not > .o files, you'll need to understand that. See dbxread.c and > stabsread.c for details. To say much more, I'd just have to refer to > them, too. -- Mit freundlichen Grüßen ^-----------------------------------------------------------+ | Rheinmetall Defence Electronics GmbH Brüggeweg 54 | | Postbox 44 84 44 | | Roul Oldenburger 28284 Bremen | | SPMU Germany | | Software Development | | | | Phone: +49 421 457 2410 | | Email: oldenburger.roul@rheinmetall-de.com | | Web: http://www.rheinmetall.com/ | | http://www.rheinmetall-de.com/ | *-----------------------------------------------------------/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gdb-internal: determining the type of a variable 2003-10-06 14:42 ` Roul Oldenburger @ 2003-10-06 14:54 ` Daniel Jacobowitz 2003-10-06 21:09 ` Jim Blandy 1 sibling, 0 replies; 7+ messages in thread From: Daniel Jacobowitz @ 2003-10-06 14:54 UTC (permalink / raw) To: Roul Oldenburger; +Cc: Jim Blandy, gdb On Mon, Oct 06, 2003 at 04:45:56PM +0200, Roul Oldenburger wrote: > Thanks for your effort giving me your explanation! > > Looking at the stabs information from our executables which are linked > from several o-files I find FILENUM being 0 for all typedescriptions. > Probably I could distinguish between the duplicate descriptions if > FILNUM would differ. Unfortunately I don't know why it is 0 all the way? > > Roul FILENUM is only different within a single compilation unit - N_SO. You have to parse it in chunks, from an N_SO with a value until the next N_SO generally. But if you are going to parse debug info, I really recommend DWARF instead... it's much easier. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gdb-internal: determining the type of a variable 2003-10-06 14:42 ` Roul Oldenburger 2003-10-06 14:54 ` Daniel Jacobowitz @ 2003-10-06 21:09 ` Jim Blandy 2003-10-07 7:16 ` Roul Oldenburger 1 sibling, 1 reply; 7+ messages in thread From: Jim Blandy @ 2003-10-06 21:09 UTC (permalink / raw) To: Roul Oldenburger; +Cc: gdb Roul Oldenburger <oldenburger.roul@rheinmetall-de.com> writes: > Thanks for your effort giving me your explanation! > > Looking at the stabs information from our executables which are linked > >From several o-files I find FILENUM being 0 for all typedescriptions. > Probably I could distinguish between the duplicate descriptions if > FILNUM would differ. Unfortunately I don't know why it is 0 all the > way? Are you sure? This is the kind of thing I see. The file numbers of the stabs for built-in types are all zero, but when you get to things like size_t, defined in stddef.h, the file numbers are larger. $ cat hello.c #include <stdio.h> char foo; int bar = 0x1729; main (int argc, char **argv) { puts ("Hello, world!"); } $ gcc -gstabs+ hello.c -o hello $ objdump --stabs hello hello: file format elf32-i386 Contents of .stab section: Symnum n_type n_othr n_desc n_value n_strx String -1 HdrSym 0 179 00001c91 1 0 SO 0 0 08048344 9 /home/jimb/play/ 1 SO 0 0 08048344 1 hello.c 2 OPT 0 0 00000000 26 gcc2_compiled. 3 LSYM 0 0 00000000 41 int:t(0,1)=r(0,1);-2147483648;2147483647; 4 LSYM 0 0 00000000 83 char:t(0,2)=r(0,2);0;127; 5 LSYM 0 0 00000000 109 long int:t(0,3)=r(0,3);-2147483648;2147483647; 6 LSYM 0 0 00000000 156 unsigned int:t(0,4)=r(0,4);0000000000000;0037777777777; 7 LSYM 0 0 00000000 212 long unsigned int:t(0,5)=r(0,5);0000000000000;0037777777777; 8 LSYM 0 0 00000000 273 long long int:t(0,6)=@s64;r(0,6);01000000000000000000000;0777777777777777777777; 9 LSYM 0 0 00000000 354 long long unsigned int:t(0,7)=@s64;r(0,7);0000000000000;01777777777777777777777; 10 LSYM 0 0 00000000 435 short int:t(0,8)=@s16;r(0,8);-32768;32767; 11 LSYM 0 0 00000000 478 short unsigned int:t(0,9)=@s16;r(0,9);0;65535; 12 LSYM 0 0 00000000 525 signed char:t(0,10)=@s8;r(0,10);-128;127; 13 LSYM 0 0 00000000 567 unsigned char:t(0,11)=@s8;r(0,11);0;255; 14 LSYM 0 0 00000000 608 float:t(0,12)=r(0,1);4;0; 15 LSYM 0 0 00000000 634 double:t(0,13)=r(0,1);8;0; 16 LSYM 0 0 00000000 661 long double:t(0,14)=r(0,1);12;0; 17 LSYM 0 0 00000000 694 complex int:t(0,15)=s8real:(0,1),0,32;imag:(0,1),32,32;; 18 LSYM 0 0 00000000 751 complex float:t(0,16)=R3;8;0; 19 LSYM 0 0 00000000 781 complex double:t(0,17)=R4;16;0; 20 LSYM 0 0 00000000 813 complex long double:t(0,18)=R5;24;0;21 LSYM 0 0 00000000 850 __builtin_va_list:t(0,19)=*(0,2) 22 LSYM 0 0 00000000 883 _Bool:t(0,20)=@s8;-16; 23 BINCL 0 0 00000ef5 1 hello.c 24 BINCL 0 0 0000103d 906 /home/jimb/trees/install/i686-pc-linux-gnu/gcc-3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/include/stdio.h 25 BINCL 0 0 00000000 1007 /usr/include/features.h 26 BINCL 0 0 00000000 1031 /usr/include/sys/cdefs.h 27 EINCL 0 0 00000000 0 28 BINCL 0 0 00000000 1056 /usr/include/gnu/stubs.h 29 EINCL 0 0 00000000 0 30 EINCL 0 0 00000000 0 31 BINCL 0 0 000004d8 1081 /home/jimb/trees/install/i686-pc-linux-gnu/gcc-3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/include/stddef.h 32 LSYM 0 213 00000000 1183 size_t:t(6,1)=(0,4) 33 EINCL 0 0 00000000 0 34 BINCL 0 0 00015bef 1203 /usr/include/bits/types.h 35 BINCL 0 0 00000000 1081 /home/jimb/trees/install/i686-pc-linux-gnu/gcc-3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/include/stddef.h 36 EINCL 0 0 00000000 0 37 LSYM 0 32 00000000 1229 __u_char:t(7,1)=(0,11) 38 LSYM 0 33 00000000 1252 __u_short:t(7,2)=(0,9) 39 LSYM 0 34 00000000 1275 __u_int:t(7,3)=(0,4) 40 LSYM 0 35 00000000 1296 __u_long:t(7,4)=(0,5) 41 LSYM 0 37 00000000 1318 __u_quad_t:t(7,5)=(0,7) 42 LSYM 0 38 00000000 1342 __quad_t:t(7,6)=(0,6) 43 LSYM 0 49 00000000 1364 __int8_t:t(7,7)=(0,10) 44 LSYM 0 50 00000000 1387 __uint8_t:t(7,8)=(0,11) 45 LSYM 0 51 00000000 1411 __int16_t:t(7,9)=(0,8) 46 LSYM 0 52 00000000 1434 __uint16_t:t(7,10)=(0,9) 47 LSYM 0 53 00000000 1459 __int32_t:t(7,11)=(0,1) 48 LSYM 0 54 00000000 1483 __uint32_t:t(7,12)=(0,4) 49 LSYM 0 56 00000000 1508 __int64_t:t(7,13)=(0,6) 50 LSYM 0 57 00000000 1532 __uint64_t:t(7,14)=(0,7) 51 LSYM 0 59 00000000 1557 __qaddr_t:t(7,15)=(7,16)=*(7,6) 52 LSYM 0 61 00000000 1589 __dev_t:t(7,17)=(7,5) 53 LSYM 0 62 00000000 1611 __uid_t:t(7,18)=(7,3) 54 LSYM 0 63 00000000 1633 __gid_t:t(7,19)=(7,3) 55 LSYM 0 64 00000000 1655 __ino_t:t(7,20)=(7,4) 56 LSYM 0 65 00000000 1677 __mode_t:t(7,21)=(7,3) 57 LSYM 0 66 00000000 1700 __nlink_t:t(7,22)=(7,3) 58 LSYM 0 67 00000000 1724 __off_t:t(7,23)=(0,3) 59 LSYM 0 68 00000000 1746 __loff_t:t(7,24)=(7,6) 60 LSYM 0 69 00000000 1769 __pid_t:t(7,25)=(0,1) 61 LSYM 0 70 00000000 1791 __ssize_t:t(7,26)=(0,1) 62 LSYM 0 71 00000000 1815 __rlim_t:t(7,27)=(7,4) 63 LSYM 0 72 00000000 1838 __rlim64_t:t(7,28)=(7,5) 64 LSYM 0 73 00000000 1863 __id_t:t(7,29)=(7,3) 65 LSYM 0 78 00000000 1884 __fsid_t:t(7,30)=(7,31)=s8__val:(7,32)=ar(7,33)=r(7,33);0000000000000;0037777777777;;0;1;(0,1),0,64;; 66 LSYM 0 81 00000000 1986 __daddr_t:t(7,34)=(0,1) 67 LSYM 0 82 00000000 2010 __caddr_t:t(7,35)=(7,36)=*(0,2) 68 LSYM 0 83 00000000 2042 __time_t:t(7,37)=(0,3) 69 LSYM 0 84 00000000 2065 __useconds_t:t(7,38)=(0,4) 70 LSYM 0 85 00000000 2092 __suseconds_t:t(7,39)=(0,3) 71 LSYM 0 86 00000000 2120 __swblk_t:t(7,40)=(0,3) 72 LSYM 0 88 00000000 2144 __clock_t:t(7,41)=(0,3) 73 LSYM 0 91 00000000 2168 __clockid_t:t(7,42)=(0,1) 74 LSYM 0 94 00000000 2194 __timer_t:t(7,43)=(0,1) 75 LSYM 0 101 00000000 2218 __key_t:t(7,44)=(0,1) 76 LSYM 0 104 00000000 2240 __ipc_pid_t:t(7,45)=(0,9) 77 LSYM 0 108 00000000 2266 __blksize_t:t(7,46)=(0,3) 78 LSYM 0 113 00000000 2292 __blkcnt_t:t(7,47)=(0,3) 79 LSYM 0 114 00000000 2317 __blkcnt64_t:t(7,48)=(7,6) 80 LSYM 0 117 00000000 2344 __fsblkcnt_t:t(7,49)=(7,4) 81 LSYM 0 118 00000000 2371 __fsblkcnt64_t:t(7,50)=(7,5) 82 LSYM 0 121 00000000 2400 __fsfilcnt_t:t(7,51)=(7,4) 83 LSYM 0 122 00000000 2427 __fsfilcnt64_t:t(7,52)=(7,5) 84 LSYM 0 125 00000000 2456 __ino64_t:t(7,53)=(7,5) 85 LSYM 0 128 00000000 2480 __off64_t:t(7,54)=(7,24) 86 LSYM 0 131 00000000 2505 __t_scalar_t:t(7,55)=(0,3) 87 LSYM 0 132 00000000 2532 __t_uscalar_t:t(7,56)=(0,5) 88 LSYM 0 135 00000000 2560 __intptr_t:t(7,57)=(0,1) 89 LSYM 0 138 00000000 2585 __socklen_t:t(7,58)=(0,4) 90 BINCL 0 0 0000f3d6 2611 /usr/include/bits/pthreadtypes.h 91 BINCL 0 0 00001046 2644 /usr/include/bits/sched.h 92 LSYM 0 0 00000000 2670 __sched_param:T(10,1)=s4__sched_priority:(0,1),0,32;; 93 EINCL 0 0 00000000 0 94 LSYM 0 0 00000000 2724 _pthread_fastlock:T(9,1)=s8__status:(0,3),0,32;__spinlock:(0,1),32,32;; 95 LSYM 0 35 00000000 2796 _pthread_descr:t(9,2)=(9,3)=*(9,4)=xs_pthread_descr_struct: 96 LSYM 0 0 00000000 2856 __pthread_attr_s:T(9,5)=s36__detachstate:(0,1),0,32;__schedpolicy:(0,1),32,32;__schedparam:(10,1),64,32;__inheritsched:(0,1),96,32;__scope:(0,1),128,32;__guardsize:(6,1),160,32;__stackaddr_set:(0,1),192,32;__stackaddr:(9,6)=*(9,7)=(9,7),224,32;__stacksize:(6,1),256,32;; 97 LSYM 0 52 00000000 3127 pthread_attr_t:t(9,8)=(9,5) 98 LSYM 0 60 00000000 3155 pthread_cond_t:t(9,9)=(9,10)=s12__c_lock:(9,1),0,64;__c_waiting:(9,2),64,32;; 99 LSYM 0 67 00000000 3233 pthread_condattr_t:t(9,11)=(9,12)=s4__dummy:(0,1),0,32;; 100 LSYM 0 70 00000000 3290 pthread_key_t:t(9,13)=(0,4) 101 LSYM 0 83 00000000 3318 pthread_mutex_t:t(9,14)=(9,15)=s24__m_reserved:(0,1),0,32;__m_count:(0,1),32,32;__m_owner:(9,2),64,32;__m_kind:(0,1),96,32;__m_lock:(9,1),128,64;; 102 LSYM 0 90 00000000 3465 pthread_mutexattr_t:t(9,16)=(9,17)=s4__mutexkind:(0,1),0,32;; 103 LSYM 0 94 00000000 3527 pthread_once_t:t(9,18)=(0,1) 104 LSYM 0 140 00000000 3556 pthread_t:t(9,19)=(0,5) 105 EINCL 0 0 00000000 0 106 EINCL 0 0 00000000 0 107 LSYM 0 55 00000000 3580 FILE:t(2,1)=(2,2)=xs_IO_FILE: 108 LSYM 0 71 00000000 3610 __FILE:t(2,3)=(2,2) 109 BINCL 0 0 00011d80 3630 /usr/include/libio.h 110 BINCL 0 0 00005666 3651 /usr/include/_G_config.h 111 BINCL 0 0 00000a11 1081 /home/jimb/trees/install/i686-pc-linux-gnu/gcc-3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/include/stddef.h 112 LSYM 0 325 00000000 3676 wchar_t:t(13,1)=(0,3) 113 LSYM 0 354 00000000 3698 wint_t:t(13,2)=(0,4) 114 EINCL 0 0 00000000 0 115 BINCL 0 0 00001f62 3719 /usr/include/wchar.h 116 EXCL 0 0 00000000 1081 /home/jimb/trees/install/i686-pc-linux-gnu/gcc-3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/include/stddef.h 117 BINCL 0 0 00000000 3740 /usr/include/bits/wchar.h 118 EINCL 0 0 00000000 0 119 LSYM 0 79 00000000 3766 __mbstate_t:t(14,1)=(14,2)=s8__count:(0,1),0,32;__value:(14,3)=u4__wch:(13,2),0,32;__wchb:(14,4)=ar(7,33);0;3;(0,2),0,32;;,32,32;; 120 EINCL 0 0 00000000 0 121 LSYM 0 30 00000000 3897 _G_fpos_t:t(12,1)=(12,2)=s12__pos:(7,23),0,32;__state:(14,1),32,64;; 122 LSYM 0 35 00000000 3966 _G_fpos64_t:t(12,3)=(12,4)=s16__pos:(7,54),0,64;__state:(14,1),64,64;; 123 BINCL 0 0 0001b94d 4037 /usr/include/gconv.h 124 BINCL 0 0 00000000 3719 /usr/include/wchar.h 125 EXCL 0 0 00000000 1081 /home/jimb/trees/install/i686-pc-linux-gnu/gcc-3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/include/stddef.h 126 EINCL 0 0 00000000 0 127 EXCL 0 0 00000000 1081 /home/jimb/trees/install/i686-pc-linux-gnu/gcc-3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/include/stddef.h 128 LSYM 0 0 00000000 4058 :T(17,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,; 129 LSYM 0 0 00000000 4281 :T(17,2)=e__GCONV_IS_LAST:1,__GCONV_IGNORE_ERRORS:2,; 130 LSYM 0 72 00000000 4336 __gconv_fct:t(17,3)=(17,4)=*(17,5)=f(0,1) 131 LSYM 0 75 00000000 4378 __gconv_init_fct:t(17,6)=(17,7)=*(17,8)=f(0,1) 132 LSYM 0 76 00000000 4425 __gconv_end_fct:t(17,9)=(17,10)=*(17,11)=f(9,7) 133 LSYM 0 85 00000000 4473 __gconv_trans_fct:t(17,12)=(17,13)=*(17,14)=f(0,1) 134 LSYM 0 90 00000000 4524 __gconv_trans_context_fct:t(17,15)=(17,16)=*(17,17)=f(0,1) 135 LSYM 0 94 00000000 4583 __gconv_trans_query_fct:t(17,18)=(17,19)=*(17,20)=f(0,1) 136 LSYM 0 97 00000000 4640 __gconv_trans_init_fct:t(17,21)=(17,22)=*(17,23)=f(0,1) 137 LSYM 0 98 00000000 4696 __gconv_trans_end_fct:t(17,24)=(17,25)=*(17,26)=f(9,7) 138 LSYM 0 0 00000000 4751 __gconv_trans_data:T(17,27)=s20__trans_fct:(17,12),0,32;__trans_context_fct:(17,15),32,32;__trans_end_fct:(17,24),64,32;__data:(9,6),96,32;__next:(17,28)=*(17,27),128,32;; 139 LSYM 0 0 00000000 4923 __gconv_step:T(17,29)=s56__shlib_handle:(17,30)=*(17,31)=xs__gconv_loaded_object:,0,32;__modname:(17,32)=*(17,33)=k(0,2),32,32;__counter:(0,1),64,32;__from_name:(7,36),96,32;__to_name:(7,36),128,32;__fct:(17,3),160,32;__init_fct:(17,6),192,32;__end_fct:(17,9),224,32;__min_needed_from:(0,1),256,32;__max_needed_from:(0,1),288,32;__min_needed_to:(0,1),320,32;__max_needed_to:(0,1),352,32;__stateful:(0,1),384,32;__data:(9,6),416,32;; 140 LSYM 0 0 00000000 5356 __gconv_step_data:T(17,34)=s36__outbuf:(17,35)=*(0,11),0,32;__outbufend:(17,35),32,32;__flags:(0,1),64,32;__invocation_counter:(0,1),96,32;__internal_use:(0,1),128,32;__statep:(17,36)=*(14,1),160,32;__state:(14,1),192,64;__trans:(17,28),256,32;; 141 LSYM 0 0 00000000 5602 __gconv_info:T(17,37)=s8__nsteps:(6,1),0,32;__steps:(17,38)=*(17,29),32,32;; 142 LSYM 0 173 00000000 5679 __gconv_t:t(17,39)=(17,40)=*(17,37) 143 EINCL 0 0 00000000 0 144 LSYM 0 53 00000000 5715 _G_iconv_t:t(12,5)=(12,6)=u44__cd:(17,37),0,64;__combined:(12,7)=s44__cd:(17,37),0,64;__data:(17,34),64,288;;,0,352;; 145 LSYM 0 55 00000000 5833 _G_int16_t:t(12,8)=(0,8) 146 LSYM 0 56 00000000 5858 _G_int32_t:t(12,9)=(0,1) 147 LSYM 0 57 00000000 5883 _G_uint16_t:t(12,10)=(0,9) 148 LSYM 0 58 00000000 5910 _G_uint32_t:t(12,11)=(0,4) 149 EINCL 0 0 00000000 0 150 BINCL 0 0 0000083c 5937 /home/jimb/trees/install/i686-pc-linux-gnu/gcc-3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/include/stdarg.h 151 LSYM 0 43 00000000 6039 __gnuc_va_list:t(21,1)=(0,19) 152 EINCL 0 0 00000000 0 153 LSYM 0 172 00000000 6069 _IO_lock_t:t(11,1)=(9,7) 154 LSYM 0 0 00000000 6094 _IO_marker:T(11,2)=s12_next:(11,3)=*(11,2),0,32;_sbuf:(11,4)=*(2,2),32,32;_pos:(0,1),64,32;; 155 LSYM 0 0 00000000 6187 __codecvt_result:T(11,5)=e__codecvt_ok:0,__codecvt_partial:1,__codecvt_error:2,__codecvt_noconv:3,; 156 LSYM 0 0 00000000 6287 _IO_FILE:T(2,2)=s148_flags:(0,1),0,32;_IO_read_ptr:(7,36),32,32;_IO_read_end:(7,36),64,32;_IO_read_base:(7,36),96,32;_IO_write_base:(7,36),128,32;_IO_write_ptr:(7,36),160,32;_IO_write_end:(7,36),192,32;_IO_buf_base:(7,36),224,32;_IO_buf_end:(7,36),256,32;_IO_save_base:(7,36),288,32;_IO_backup_base:(7,36),320,32;_IO_save_end:(7,36),352,32;_markers:(11,3),384,32;_chain:(11,4),416,32;_fileno:(0,1),448,32;_flags2:(0,1),480,32;_old_offset:(7,23),512,32;_cur_column:(0,9),544,16;_vtable_offset:(0,10),560,8;_shortbuf:(11,6)=ar(7,33);0;0;(0,2),568,8;_lock:(11,7)=*(11,1),576,32;_offset:(7,54),608,64;__pad1:(9,6),672,32;__pad2:(9,6),704,32;_mode:(0,1),736,32;_unused2:(11,8)=ar(7,33);0;51;(0,2),768,416;; 157 LSYM 0 327 00000000 6989 _IO_FILE:t(11,9)=(2,2) 158 LSYM 0 350 00000000 7012 __io_read_fn:t(11,10)=(11,11)=f(7,26) 159 LSYM 0 359 00000000 7050 __io_write_fn:t(11,12)=(11,13)=f(7,26) 160 LSYM 0 367 00000000 7089 __io_seek_fn:t(11,14)=(11,15)=f(0,1)161 LSYM 0 370 00000000 7126 __io_close_fn:t(11,16)=(11,17)=f(0,1) 162 EINCL 0 0 00000000 0 163 LSYM 0 97 00000000 7164 fpos_t:t(2,4)=(12,1) 164 BINCL 0 0 00000000 7185 /usr/include/bits/stdio_lim.h 165 EINCL 0 0 00000000 0 166 BINCL 0 0 00000000 7215 /usr/include/bits/sys_errlist.h 167 EINCL 0 0 00000000 0 168 EINCL 0 0 00000000 0 169 FUN 0 7 08048344 7247 main:F(0,1) 170 PSYM 0 6 00000008 7259 argc:p(0,1) 171 PSYM 0 6 0000000c 7271 argv:p(1,1)=*(7,36) 172 SLINE 0 7 00000000 0 173 SLINE 0 8 00000010 0 174 SLINE 0 9 0000001c 0 175 FUN 0 0 0000001e 0 176 GSYM 0 3 00000000 7291 foo:G(0,2) 177 GSYM 0 4 00000000 7302 bar:G(0,1) 178 SO 0 0 08048362 0 $ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gdb-internal: determining the type of a variable 2003-10-06 21:09 ` Jim Blandy @ 2003-10-07 7:16 ` Roul Oldenburger 0 siblings, 0 replies; 7+ messages in thread From: Roul Oldenburger @ 2003-10-07 7:16 UTC (permalink / raw) To: Jim Blandy; +Cc: gdb Hi Jim, you are right, thanks. Probably I didn't look at all type descriptions and only greped for the structure desriptions. Roul Jim Blandy wrote: > Roul Oldenburger <oldenburger.roul@rheinmetall-de.com> writes: > > >>Thanks for your effort giving me your explanation! >> >>Looking at the stabs information from our executables which are linked >>>From several o-files I find FILENUM being 0 for all typedescriptions. >>Probably I could distinguish between the duplicate descriptions if >>FILNUM would differ. Unfortunately I don't know why it is 0 all the >>way? > > > Are you sure? This is the kind of thing I see. The file numbers of > the stabs for built-in types are all zero, but when you get to things > like size_t, defined in stddef.h, the file numbers are larger. > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2003-10-07 7:16 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-10-02 12:48 gdb-internal: determining the type of a variable Roul Oldenburger 2003-10-02 15:35 ` Elena Zannoni 2003-10-02 15:40 ` Jim Blandy 2003-10-06 14:42 ` Roul Oldenburger 2003-10-06 14:54 ` Daniel Jacobowitz 2003-10-06 21:09 ` Jim Blandy 2003-10-07 7:16 ` Roul Oldenburger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox