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)

3 views
Skip to first unread message

xugang

unread,
Nov 22, 2009, 1:05:06 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.

Bill Marcum

unread,
Nov 22, 2009, 2:12:00 PM11/22/09
to
On 2009-11-22, xugang <xugan...@gmail.com> wrote:
>
> 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.
>
I'm not sure I understand the question. Do you want the object file to
have the same output for a given input (it should), or do you want the
file itself to be identical when the source code is compiled by different
versions of gcc? Why would you need that?

xugang

unread,
Nov 23, 2009, 8:17:03 PM11/23/09
to
Hi:

----------------------------------------------------------------------------


Do you want the object file to
have the same output for a given input (it should),

----------------------------------------------------------------------------

I just need the object file has the same output for a given input,

we have an application which will get the message name and the
corresponding

message code through the object file (It is for a wireless system).
(the message

name and message code is matching) we will use this info to trace our
system

running.

thanks! any suggestions are welcome!

On 11月23日, 上午3时12分, Bill Marcum <marcumb...@bellsouth.net> wrote:

> versions of gcc? Why would you need that?- 隐藏被引用文字 -
>
> - 显示引用的文字 -

Jens Thoms Toerring

unread,
Nov 23, 2009, 9:01:55 PM11/23/09
to
xugang <xugan...@gmail.com> wrote:

> Bill Marcum <marcumb...@bellsouth.net> wrote:
> Do you want the object file to
> have the same output for a given input (it should),

> I just need the object file has the same output for a given input, we


> have an application which will get the message name and the corresponding
> message code through the object file (It is for a wireless system). (the
> message name and message code is matching) we will use this info to trace
> our system running.

If your C (or is it a C++ or maybe something completely diffe-
rent?) program (I guess that's what you mean with "object file
since I don't know how to interpret it otherwise because "object
files" don't have any output) doesn't have the same output for
a given input when using different compilers (or versions of a
compiler) then there are mostly two things to consider:

a) Your program is written in a way that it relies on undefined
behaviour, i.e. you're (mis-)using the way one compiler (or
a certain version of a compiler) creates object code out of
the source code but which isn't guaranteed to work that way.
b) You have found a bug in (one or both versions of) the compiler.

I would guess that a) is a lot more probable. And what you write
about "message names", "message codes", "message infos", "wireless
systems", "filters" are, at least without a lot more of context,
useless to anyone else but yourself since all these aren't words
that have a well-defined meaning. Perhaps you better start with
stating your observations (i.e. what data do you pass to the pro-
gram, what is its output and what do you expect) and post some
source code. That would make it a lot easier to come up with ideas
about what's going on and where there might be problems.

Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de

xugang

unread,
Nov 23, 2009, 10:55:45 PM11/23/09
to

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日, 上午10时01分, j...@toerring.de (Jens Thoms Toerring) wrote:

xugang

unread,
Nov 24, 2009, 3:44:12 AM11/24/09
to
I am not sure whether this problem is related to the precompile info
can't input to the object file?

On 11月24日, 上午11时55分, xugang <xugangs...@gmail.com> wrote:
> 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:

> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!­!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!­!!!!

> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!­!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!­!!!!


>
> 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

> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!­!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!­!!!!!!!!

> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!­!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!­!!!!!!!!


>
> the following info we will get:

> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!­!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!­!!!!!!!!

> ...
>
> 阅读更多 »

Jens Thoms Toerring

unread,
Nov 24, 2009, 7:59:05 AM11/24/09
to
xugang <xugan...@gmail.com> wrote:
> Thanks for your responding, here is the detail description of our
> problems

> 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

I'm not familiar with SUN, but as far as I have found 'dump -c'
will give you a listing of the string table(s). And that's what
the following look like.

> .....

> 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

In contrast to SUN's 'dump -c' this doesn't output a string table
but instead information about all headers in the object file. So
it does something rather different from SUN's 'dump -c'.

> there is no the message info we wanted.

> PartIII:

> Do we can adjust the command option to generate the info ?
> or other ways?

Assuming that my guess that what you're looking for is a certain
string in the object file I thing that you should run 'objdump -s'
on the object file. You then should find the strings from the
source file somewhere in there, probably in one of the .rodata
sections. If you already know in which section the string is
going to be then you can add the '-j' flag to restrict the out-
put to that section, e.g.

objdump -s -j .rodata file.o

if the string is always going to be in the '.rodata' section.
Keep in mind that the output of objdump will look a bit dif-
ferent from that of SUN's dump utility!

Your problem doesn't seem to be related to the GCC version but the
differences between the tools you use to analyze the generated ob-
ject file. If there's a certain string in the program then it must
appear in the object file, no matter if you use GCC version 2.95
or 3.4.5 (at least if the string is used in the code).

BTW, a better place to ask this kind of questions probably would
be comp.unix.programmer.

xugang

unread,
Nov 26, 2009, 12:11:16 AM11/26/09
to

Dear all:

I have gotten the answer from gnu.gcc.help group. please refer
the following part:


great thanks for all of you responding!

-----------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------

On 11月24日, 下午8时59分, j...@toerring.de (Jens Thoms Toerring) wrote:

>    \__________________________      http://toerring.de- 隐藏被引用文字 -
>
> - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -

0 new messages