Hello again,
I posted the attached mail on February 2nd, 2000 - but I didn't get any
response
till now. I have to reach a decision, please help me!
Due to the fact, that this is the only gdb newsgoup I found, I hope that you
can
name me a correct contact person to find the answer onto the following
urgent questions:
(1)
Does GNU somehow provide the "offline symbolic interpretation" functionality
described below (incl. big endian / little endian problem - meanwhile solved
by disabling the appropriate #DEFINE)?
(2)
If it is not provided and we realize the described approach, what is the
further
proceeding? Do you centrally manage such enhancements?
Mit freundlichen Gr��en / Best regards,
Lukas Schlosser
--
Siemens AG �sterreich
Siemensstra�e 88-92 / Bau 16
A-1211 Wien
PSE TN SES15 (SIE)
Tel: +43 51707 / 25262, Fax: +43 51707 / 55241
Mail: [EMAIL PROTECTED]
> -----Urspr�ngliche Nachricht-----
> Von: Schlosser Lukas
> Gesendet am: Mittwoch, 02. Februar 2000 16:49
> An: [EMAIL PROTECTED]
> Betreff: gdb extension?
> Wichtigkeit: Hoch
>
> Hello,
>
> I have to find out (very urgently), whether I can extend the
> gdb for offline symbolic interpretation, but I have a big
> problem with "Big Endian" and "Little Endian" format:
>
> I collect trace data (more or less C-structs) on a "big
> endian" machine (running on VxWorks) and write it to a buffer.
> This buffer is transferred to an NT PC ("little endian"),
> where it should be symbolically interpreted.
> (Please see attached example for details).
>
> I thought of using the functionality of gdb in the following way:
> .) I start the gdb under WinNT and load a simple program "dummy.exe".
> .) Then I load the debug information, which was produced for
> the original machine ("big endian"). I tried already, and
> this is possible.
> .) Then I set a breakpoint at a certain place in "dummy.exe",
> whose functionality is to read the whole trace buffer into
> the memory.
> .) I run the program and it automatically stops after having
> read the whole buffer into memory.
> .) I can determine where this memory region starts, I know
> which datatype was traced at which position in my buffer ->
> by means of simple type casts giving a certain address
> (offset in buffer combined with start address of memory
> area), gdb automtically shows the detailed structure of the
> given data, just in the wrong format.
>
> ==> The only problem is: How is it possible to let gdb
> interpret the raw data as "Big Endian" although it is running
> on an "Little Endian" Machine. The command "set endian big"
> does not work, it gives error message: "Byte order is not selectable".
>
> Thanks for your help,
> Lukas Schlosser.
>
> Example:
> >> //-----------------------
> >> class MyClass
> >> {
> >> private:
> >> int m_i ; // Integer Data with size as 4Bytes
> >> bool m_b ; // Boolean data with size as 1Byte
> >> };
> >> //---------------------
>
> >> When this module is compiled by GNU C++, all the
> debugging information
> >> (like, the class name, names of each data member,
> their types,size etc)
> >> are stored in the \"stabs\".
>
> >> Now, I get the following string from a dump tool:
> >> H\'000FFF00
>
> >> Now I want to map these values to the corresponding
> data members in
> >> MyClass.
> >> i.e.. A tool should load the \"stabs\", read the
> information for class
> >> MyClass. It finds that there is a data member named
> \"m_i\" which is of
> >> type int. It means, its size will be 4Bytes. So from
> the hex dump, it
> >> extracts 4 Bytes and assign to the data member. So the
> output of this
> >> tool should be:
> >> //--------
> >> m_i = H\'000FFF
> >> m_b = H\'00
> >> //--------
