This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Symbolic Interpretation in GNU world.



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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]