Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Help! Using Different version GCC generate different object file (for same source file)

5 views
Skip to first unread message

xugang

unread,
Nov 22, 2009, 1:08:19 AM11/22/09
to
Dear all:

The title is confusing, i try to explain here clearly:

There are two server we using now: one is linux server with the GCC
version (3.4.5);

the other one is the Sun server with GCC version (2.95.3)

There is one application which we will filter some message infor
through the object file.

Now, we find that using higher version GCC compiled the same source
file, we can't filter

the message info we wanted. But using the other server with lower
version GCC, the appl

can be worked normally.

We checked the object file and found that the object file which
generated by higher ver

GCC has no info we wanted, but the object file generated by lower ver
GCC has the info

we wanted.

My question is that:

1> Can we modify the generated object file content through
adjusting some compile

option with higher version GCC to be same with the object file which
generated by lower

version GCC? If so, which compile option will be worked?

2> Is there other way we can try without downgrade the GCC
version?


Thanks all!

BR.

Andrew Haley

unread,
Nov 23, 2009, 5:40:03 PM11/23/09
to
xugang <xugan...@gmail.com> wrote:


> My question is that:

> 1> Can we modify the generated object file content through
> adjusting some compile
> option with higher version GCC to be same with the object file which
> generated by lower
> version GCC? If so, which compile option will be worked?

> 2> Is there other way we can try without downgrade the GCC
> version?


Without seeing your program, it's hard to say. If you cn send an
example that shows this behaviour to gcc-...@gcc.gnu.org, we'll have
a look.

Andrew.

xugang

unread,
Nov 23, 2009, 8:09:57 PM11/23/09
to

OK, I will send to you later, thanks!!

On 11月24日, 上午6时40分, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:


> xugang <xugangs...@gmail.com> wrote:
> > My question is that:
> > 1> Can we modify the generated object file content through
> > adjusting some compile
> > option with higher version GCC to be same with the object file which
> > generated by lower
> > version GCC? If so, which compile option will be worked?
> > 2> Is there other way we can try without downgrade the GCC
> > version?
>
> Without seeing your program, it's hard to say. If you cn send an

> example that shows this behaviour to gcc-h...@gcc.gnu.org, we'll have
> a look.
>
> Andrew.

xugang

unread,
Nov 23, 2009, 10:50:53 PM11/23/09
to Andrew Haley

Dears:

Thanks for your responding, here is the detail description of our
problems

please help to check, thanks!

We want to get the message name and its messsage code from the
generated

object file like the following format:

MOBI_SAP_SIM_CARD_OUT_IND : 7012371

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
t_sap_SimCardInInd:t(107,22)=(107,23)
<44059> :T(107,24)=eMOBI_SAP_SIM_CARD_OUT_IND:7012371,;
~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
<44108> t_sap_SimCardOutInd:t(107,25)=(107,26)=s20s_MsgHeader:
(48,\
<44273> :T(107,27)=eMOBI_SAP_SIM_CARD_UNPLUG_IND:7012787,;
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

In the Sun server with the lower version GCC, the above target can
achieve.

In the Linux server with higher version GCC, the above target we
can't.

Note:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

For security purpose, the following info has been modified partly, if
you

see:

<123> mmm37_05Gm------------Ind

the "------------" part means some info has been commented,

sorry for this!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Part I: GCC version

1. Sun server: 2.95.3
2. Linux server: 3.4.5

Part II: Object file info

1. Sun server

the command <dump> we use to check the object file, the usage is :
dump -c
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Usage: /usr/ccs/bin/dump [-agcd:fhn:oprstvCLT:V?] file(s) ...
[-a dump archive header of each member of archive]
[-g dump archive global symbol table]
[-c dump the string table]
[-d dump range of sections]
[-f dump each file header]
[-h dump section headers]
[-n dump named section]
[-o dump each program execution header]
[-p suppress printing of headings]
[-r dump relocation information]
[-s dump section contents]
[-t dump symbol table entries]
[-v print information in verbose form]
[-C dump decoded C++ symbol names]
[-L dump the .dynamic structure]
[-T dump symbol table range]
[-V dump version information]
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

the following info we will get:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
mmm99fsm.o:
**** STRING TABLE INFORMATION ****
.shstrtab:
<offset> Name
<0>
<1> .shstrtab
<11> .text
<17> .rodata
<25> .stab
<31> .stabstr
<40> .symtab
<48> .strtab
<56> .rela.rodata
<69> .rela.stab
<80> .comment
.stabstr:
<offset> Name
<0>
<1> mmm99fsm.c
<12> /vob/6718SW/target/l23mma/modules/l23mmm/srce/
<59> mmm99fsm.c
<70> gcc2_compiled.
<85> int:t(0,1)=r(0,1);0020000000000;0017777777777;
......
<687> long double:t(0,14)=r(0,1);16;0;
<720> complex int:t(0,15)=s8real:(0,1),0,32;imag:(0,1),32,32;;
<777> complex float:t(0,16)=r(0,16);4;0;
<812> complex double:t(0,17)=r(0,17);8;0;
......
<44059> :T(107,24)=eMOBI_SAP_SIM_CARD_OUT_IND:7012371,;
~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~
message name message code
<44108> t_sap_SimCardOutInd:t(107,25)=(107,26)=s20s_MsgHeader:
(....
<44273> :T(107,27)=eMOBI_SAP_SIM_CARD_UNPLUG_IND:7012787,;

.....

.strtab:
<offset> Name
<0>
<1> mmm99fsm.c
<12> Letext
<19> mmm88_13Acce-----------resh
<47> mmm21_13Capi-----------atChangeReq
<82> s_mmm_CsWorkingSig
<101> mmm36_01Rr-----------
<123> mmm37_05Gm------------Ind
<149> mmm48_05Rr------
<166> mmm21_03Cm----------
<187> mmm36_07Cm------------Ind
<213> mmm43_03Cm------------Ind
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

we can get the message name and message code info from the object file

2. Linux server

the command <objdump> we use to check the object file, the usage is:
objdump -x
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Usage: objdump <option(s)> <file(s)>
Display information from object <file(s)>.
At least one of the following switches must be given:
-a, --archive-headers Display archive header information
-f, --file-headers Display the contents of the overall file
header
-p, --private-headers Display object format specific file header
contents
-h, --[section-]headers Display the contents of the section headers
-x, --all-headers Display the contents of all headers
-d, --disassemble Display assembler contents of executable
sections
-D, --disassemble-all Display assembler contents of all sections
-S, --source Intermix source code with disassembly
-s, --full-contents Display the full contents of all sections
requested
-g, --debugging Display debug information in object file
-e, --debugging-tags Display debug information using ctags style
-G, --stabs Display (in raw form) any STABS info in the
file
-t, --syms Display the contents of the symbol table(s)
-T, --dynamic-syms Display the contents of the dynamic symbol
table
-r, --reloc Display the relocation entries in the file
-R, --dynamic-reloc Display the dynamic relocation entries in
the file
-v, --version Display this program's version number
-i, --info List object formats and architectures
supported
-H, --help Display this information
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

the following info we will get:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
mmm99fsm.o: file format elf32-i386
mmm99fsm.o
architecture: i386, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000000 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000000 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000034 2**2
ALLOC
3 .debug_abbrev 000000b4 00000000 00000000 00000034 2**0
CONTENTS, READONLY, DEBUGGING
4 .debug_info 0000165b 00000000 00000000 000000e8 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
5 .debug_line 000000a8 00000000 00000000 00001743 2**0
CONTENTS, READONLY, DEBUGGING
6 .rodata 00002f3c 00000000 00000000 00001800 2**5
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
7 .debug_pubnames 000009bb 00000000 00000000 0000473c 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
8 .debug_str 0000000d 00000000 00000000 000050f7 2**0
CONTENTS, READONLY, DEBUGGING
9 .note.GNU-stack 00000000 00000000 00000000 00005104 2**0
CONTENTS, READONLY
10 .comment 0000002d 00000000 00000000 00005104 2**0
CONTENTS, READONLY
SYMBOL TABLE:
00000000 l df *ABS* 00000000 mmm99fsm.c
00000000 l d .text 00000000
00000000 l d .data 00000000
00000000 l d .bss 00000000
00000000 l d .debug_abbrev 00000000
00000000 l d .debug_info 00000000
00000000 l d .debug_line 00000000
00000000 l d .rodata 00000000
00000000 l d .debug_pubnames 00000000
00000000 l d .debug_str 00000000
00000000 l d .note.GNU-stack 00000000
00000000 l d .comment 00000000
00000000 g O .rodata 00000024 s_mmm_SaveInputTable-------------
00000040 g O .rodata 00000038
s_mmm_SaveInputTable------------------
00000080 g O .rodata 00000048
s_mmm_SaveInputTable-----------------
000000c8 g O .rodata 00000014
s_mmm_SaveInputTable-----------------
000000e0 g O .rodata 00000058
s_mmm_SaveInputTable-------------------ted
00000138 g O .rodata 00000008
s_mmm_SaveInputTable-------------------LrPlmnSearch
00000140 g O .rodata 00000004 s_mmm_SaveInputTable--------------
00000160 g O .rodata 0000002c
s_mmm_SaveInputTable-------------------ted
000001a0 g O .rodata 00000028
s_mmm_SaveInputTable-------------------
000001c8 g O .rodata 0000001c s_mmm_SaveInputTable----------------
00000200 g O .rodata 00000024
s_mmm_SaveInputTable-------------------
00000224 g O .rodata 0000000c s_mmm_SaveInputTable---------------
00000240 g O .rodata 00000024
s_mmm_SaveInputTable------------------
00000264 g O .rodata 0000000c s_mmm_SaveInputTable------------
00000270 g O .rodata 00000008 s_mmm_SaveInputTable----------------
00000278 g O .rodata 0000000c s_mmm_SaveInputTable----------------
00000284 g O .rodata 0000000c
s_mmm_SaveInputTable-------------------rch
00000290 g O .rodata 00000008
s_mmm_SaveInputTable-------------------h
00000298 g O .rodata 00000008
s_mmm_SaveInputTable-------------------rking
000002a0 g O .rodata 00000008
s_mmm_SaveInputTable-------------------orking
000002c0 g O .rodata 00000028
s_mmm_SaveInputTable-------------------PsWorking
00000300 g O .rodata 00000028
s_mmm_SaveInputTable-------------------PsWorking
00000340 g O .rodata 00000020
s_mmm_SaveInputTable-------------------sWorking
00000360 g O .rodata 0000001c
s_mmm_SaveInputTable-------------------orking
00000380 g O .rodata 00000028
s_mmm_SaveInputTable-------------------
000003c0 g O .rodata 000001e0 s_mmm_CommonTable
00000000 *UND* 00000000 mmm98_23Lo---------------ctRej
00000000 *UND* 00000000 mmm98_21Do-------
00000000 *UND* 00000000 mmm01_05Pr---------------aryUpdateErr
00000000 *UND* 00000000 mmm98_32Cm---------------f
00000000 *UND* 00000000 mmm98_40Ac---------------sh
00000000 *UND* 00000000 mmm98_45Fo------------
00000000 *UND* 00000000 mmm98_48Pl---------------
00000000 *UND* 00000000 mmm94_17Se---------------denLaListReq
00000000 *UND* 00000000 mmm98_53Ca---------------Req
00000000 *UND* 00000000 mmm98_54Ca---------------eq
00000000 *UND* 00000000 mmm98_57Rr----------
00000000 *UND* 00000000 mmm98_58Rr----------
00000000 *UND* 00000000 mmm37_03Ca---------------eq
00000000 *UND* 00000000 mmm88_12Re---------------wedInd
00000000 *UND* 00000000 mmm98_59Gm----------
00000000 *UND* 00000000 mmm87_01Rr----------
00000000 *UND* 00000000 mmm87_09Gm-----------
00000000 *UND* 00000000 mmm07_07Ac---------------artial
00000000 *UND* 00000000 mmm95_11Se---------------redRatCnf
00000000 *UND* 00000000 mmm87_06Rr---------------tyInd
00000000 *UND* 00000000 mmm88_20Gm---------------ListInd
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

there is no the message info we wanted.

PartIII:

Do we can adjust the command option to generate the info ?

or other ways?

hope your suggestions!!


BR.


On 11月24日, 上午6时40分, Andrew Haley <andr...@littlepinkcloud.invalid>
wrote:

Jan Seiffert

unread,
Nov 24, 2009, 5:27:57 AM11/24/09
to
xugang schrieb:

>
> Dears:
>
> Thanks for your responding, here is the detail description of our
> problems
>
> please help to check, thanks!
>
> We want to get the message name and its messsage code from the
> generated
>
> object file like the following format:
>
> MOBI_SAP_SIM_CARD_OUT_IND : 7012371
[snip]

>
>
> Part I: GCC version
>
> 1. Sun server: 2.95.3
> 2. Linux server: 3.4.5
>
> Part II: Object file info
>
> 1. Sun server
>
> the command <dump> we use to check the object file, the usage is :
> dump -c
[snip]

> .stabstr:
> <offset> Name
> <0>
> <1> mmm99fsm.c
> <12> /vob/6718SW/target/l23mma/modules/l23mmm/srce/
> <59> mmm99fsm.c
> <70> gcc2_compiled.
> <85> int:t(0,1)=r(0,1);0020000000000;0017777777777;
> ......
> <687> long double:t(0,14)=r(0,1);16;0;
> <720> complex int:t(0,15)=s8real:(0,1),0,32;imag:(0,1),32,32;;
> <777> complex float:t(0,16)=r(0,16);4;0;
> <812> complex double:t(0,17)=r(0,17);8;0;
> ......
> <44059> :T(107,24)=eMOBI_SAP_SIM_CARD_OUT_IND:7012371,;
> ~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~
> message name message code
> <44108> t_sap_SimCardOutInd:t(107,25)=(107,26)=s20s_MsgHeader:
> (....
> <44273> :T(107,27)=eMOBI_SAP_SIM_CARD_UNPLUG_IND:7012787,;
>
> .....
>

Ahhhhhhhh. Now i know what you mean.

That are debug infos. In a certain Format. Called stabs.

Linux does not use stabs (any longer?), but dwarf as format for debug info.

[snip]


>
> there is no the message info we wanted.
>
> PartIII:
>
> Do we can adjust the command option to generate the info ?
>

Maybe it is possible to tell the toolchain to generate stabs output. The gcc
option for that is:
-gstabs

but it may not be supported on the Linux Plattform.

> or other ways?
>

Get the info you need from the dwarf debug info.

Compiling with -g and then using "objdump --debugging" or "objdump
--debugging-tags" or "readelf -w" can help you with this.
Have a look at the man pages of the tools.

> hope your suggestions!!
>
>
> BR.
>

Greetings
Jan

--
Shift happens.
-- Doppler

xugang

unread,
Nov 26, 2009, 12:03:02 AM11/26/09
to
Hi Jan:

with your great suggestion , we finally got what we need in the
object file.

great news for us and more thanks to you!

the second suggestion we just tried, but no successful, we will try
again.

BTW, could you please give us some useful resources or materials,
such as

book, website and so on related to this part? Before reaching your
suggestion,

we have tried two days on the web to search the valuable suggestion.

Hope your valuable suggestions again!!!


On 11月24日, 下午6时27分, Jan Seiffert <nomail@invalid> wrote:
> xugang schrieb:


>
>
> Ahhhhhhhh. Now i know what you mean.
>
> That are debug infos. In a certain Format. Called stabs.
>
> Linux does not use stabs (any longer?), but dwarf as format for debug info.
>
> [snip]
>
>
>
> > there is no the message info we wanted.
>
> > PartIII:
>
> >   Do we can adjust the command option to generate the info ?
>
> Maybe it is possible to tell the toolchain to generate stabs output. The gcc
> option for that is:
> -gstabs
>
> but it may not be supported on the Linux Plattform.
>
> >   or other ways?
>
> Get the info you need from the dwarf debug info.
>
> Compiling with -g and then using "objdump --debugging" or "objdump
> --debugging-tags" or "readelf -w" can help you with this.
> Have a look at the man pages of the tools.
>
> >   hope your suggestions!!
>
> > BR.
>
> Greetings
>         Jan
>
> --
> Shift happens.

>                         -- Doppler- 隐藏被引用文字 -
>
> - 显示引用的文字 -

Jan Seiffert

unread,
Nov 26, 2009, 2:00:10 AM11/26/09
to
xugang schrieb:

> Hi Jan:
>
> with your great suggestion , we finally got what we need in the
> object file.
>
> great news for us and more thanks to you!
>

Hey, thats cool. So -gstabs also works on Linux.

> the second suggestion we just tried, but no successful, we will try
> again.
>
> BTW, could you please give us some useful resources or materials,
> such as
>
> book, website and so on related to this part?

No, sorry i didn't looked at debug info till now.
All i know is the compiler puts it into the object file and a debugger or other
tools read it from there.

> Before reaching your suggestion,
> we have tried two days on the web to search the valuable suggestion.
>

I must confess, i still do not understand what data you are trying to gather
from the debug info.

I looked at how stabs debug info is defined
(http://www.math.utah.edu/docs/info/stabs_1.html) and from that it looks like
you are trying to extract an enum name and its value?

Lets see:
$ cat dwarf.c
enum foo
{
ONE,
TWO,
THREE,
};

enum foo a_var;
$ gcc -g -c dwarf.c
$ readelf --debug-dump=info dwarf.o
The section .debug_info contains:

Compilation Unit @ offset 0x0:
Length: 83
Version: 2
Abbrev Offset: 0
Pointer Size: 4
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
< c> DW_AT_producer : (indirect string, offset: 0x6): GNU C 4.3.4
<10> DW_AT_language : 1 (ANSI C)
<11> DW_AT_name : (indirect string, offset: 0x32): dwarf.c
<19> DW_AT_low_pc : 0
<1d> DW_AT_high_pc : 0
<21> DW_AT_stmt_list : 0
<1><25>: Abbrev Number: 2 (DW_TAG_enumeration_type)
<26> DW_AT_name : foo
<2a> DW_AT_byte_size : 4
<2b> DW_AT_decl_file : 1
<2c> DW_AT_decl_line : 2
<2d> DW_AT_sibling : <44>
<2><31>: Abbrev Number: 3 (DW_TAG_enumerator)
<32> DW_AT_name : ONE
<36> DW_AT_const_value : 0
<2><37>: Abbrev Number: 3 (DW_TAG_enumerator)
<38> DW_AT_name : TWO
<3c> DW_AT_const_value : 1
<2><3d>: Abbrev Number: 4 (DW_TAG_enumerator)
<3e> DW_AT_name : (indirect string, offset: 0x0): THREE
<42> DW_AT_const_value : 2
<1><44>: Abbrev Number: 5 (DW_TAG_variable)
<45> DW_AT_name : (indirect string, offset: 0x2c): a_var
<49> DW_AT_decl_file : 1
<4a> DW_AT_decl_line : 8
<4b> DW_AT_type : <25>
<4f> DW_AT_external : 1
<50> DW_AT_location : 5 byte block: 3 0 0 0 0 (DW_OP_addr: 0)

If i look long enough on this i see:
There is a enumeration type (DW_TAG_enumeration_type) named foo (DW_AT_name),
and it has several values (DW_TAG_enumerator), named ONE, TWO, THREE
(DW_AT_name) and values of 0, 1, 2 (DW_AT_const_value).
How you identify which DW_TAG_enumerator belong to which
DW_TAG_enumeration_type, hmmm, i guess they follow the DW_TAG_enumeration_type
and all belong to the same type till something else than a DW_TAG_enumerator comes.

> Hope your valuable suggestions again!!!
>

Greetings
Jan

--
Networking? That is for fishermen.

0 new messages