This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Symbolic Interpretation in GNU world.
- To: Schlosser Lukas <lukas dot schlosser at siemens dot at>
- Subject: Re: Symbolic Interpretation in GNU world.
- From: Jim Blandy <jimb at cygnus dot com>
- Date: 28 Feb 2000 16:29:22 -0500
- Cc: gdb at sourceware dot cygnus dot com
- References: <200002251926.OAA20810@mescaline.gnu.org>
GDB could do what you want, but it seems like an awfully painful and
indirect way to do something pretty simple.
The painful way:
Assuming that the architecture of your VxWorks board is something GDB
supports, and has a simulator for (check the sim directory of the GDB
source tree), you could:
- build a full cross toolchain --- compiler, assembler, libraries,
debugger --- for your VxWorks board's architecture
- write your dummy program
- run your dummy program on the simulator
The easy way:
It seems to me it'd take twenty minutes to hack up a Perl script that
uses 'unpack' to print out your log.
>
> Hello,
>
> I posted the attached mail on February 2nd, 2000 to 'bug-gdb@gnu.org'
> - but I didn't get any response till now. I have to reach a decision, please
> help me!
> Due to the fact, that this was 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
> exactly 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: Lukas.Schlosser@siemens.at <mailto:Lukas.Schlosser@siemens.at>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Schlosser Lukas
> > Gesendet am: Mittwoch, 02. Februar 2000 16:49
> > An: bug-gdb@gnu.org <mailto:bug-gdb@gnu.org>
> > 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:
> > <file://----------------------->
> > class MyClass
> > {
> > private:
> > int m_i ; // Integer Data with size as 4Bytes
> > bool m_b ; // Boolean data with size as 1Byte
> > };
> > <file://--------------------->
> >
> > 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:
> >
> > <file://-------->
> > m_i = H\'000FFF
> > m_b = H\'00
> > <file://-------->
>
>