From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Scott Bambrough Cc: "fnasser@cygnus.com" , James Ingham , GDB Mailing List Subject: Re: bug in arm_push_arguments() Date: Mon, 28 Feb 2000 04:05:00 -0000 Message-id: <38BA642A.6F358273@cygnus.com> References: <38B6C4A1.7A1461C4@netwinder.org> X-SW-Source: 2000-02/msg00039.html Scott Bambrough wrote: > > Hi guys, > > /* Convert the double to TARGET byte order and swap things to > conform to the ARM floating point layout. */ > memcpy (bufd, bufo + len / 2, len / 2); > SWAP_TARGET_AND_HOST (bufd, len / 2); /* adjust endianess */ > memcpy (bufd + len / 2, bufo, len / 2); > SWAP_TARGET_AND_HOST (bufd + len / 2, len / 2); /* adjust endianess */ > val = (char *) &dbl_arg; > > This is ok, but the code for the last step is unnecessarily complex. I think > something similar to the following should suffice. > > int tmp; > int *buf = &d; > SWAP_TARGET_AND_HOST (&d, sizeof (double)); > tmp = buf[0]; > buf[0] = buf[1]; > buf[1] = tmp; > > I think this will result in better code from the compiler. There are a couple > of problems though with this code. First what happens if sizeof (TARGET_DOUBLE) > != sizeof (HOST_DOUBLE). Second, this breaks in the native case, because the > double is already in the right format. This is why I have regressions I believe > (I have yet to test my theory). Is there a clean way to solve these problems? FYI, my guess would be that the author didn't want to make any assumptions about sizeof(int), sizeof(double) and their ratios. Those things are just too changeable. (The cast/memory poke ``(f = *(float*)d)'' is also non-portable but I won't mention that :-) Kevin Buttner wrote: > It seems to me that you should be able to use store_floating() to do > what you want. It'll handle both the conversion and the byte swapping. Yes, that looks correct. I'm just not 100% sure on it working - would one of those if()'s before the TARGET_EXTRACT_FLOATING() get in the way? Andrew >From ac131313@cygnus.com Mon Feb 28 04:08:00 2000 From: Andrew Cagney To: P.Leggett@gre.ac.uk Cc: gdb@sourceware.cygnus.com Subject: Re: gdb functionality query Date: Mon, 28 Feb 2000 04:08:00 -0000 Message-id: <38BA6506.241FCCF4@cygnus.com> References: <20000228114844.A3717@gre.ac.uk> X-SW-Source: 2000-02/msg00040.html Content-length: 1664 Peter Leggett wrote: > > Hello, > > I hope that this list is the appropriate one to ask a general > gdb question. If not please excuse this mail. > > The research group I work in uses the Sun debugger/dbx which has some > these extremly useful features without which we would find debugging > our codes much harder. We are now also running on linux boxes > and are exploring the possibilites of gdb. > > I would very much appreciate it if anyone could tell me if gdb has > the following specific functionality:- > > a) Ability to pop program call frame stack and then continue. I know one > can browse up and down the frames in gdb but can one pop it and > continue from a calling frame up the stack. Yes: (gdb) help return Make selected stack frame return to its caller. Control remains in the debugger, but when you continue execution will resume in the frame above the one now selected. If an argument is given, it is an expression for the value to return. (gdb) help finish Execute until selected stack frame returns. Upon return, the value returned is printed and put in the value history. > b) make an arbitary call to user code (with possibly arguments and > expressions) from gdb and break point within that call etc.. > e.g. > > gdb-> break usersub > gdb-> call usersub(a,fred+2,jim*2+1) > ... > > where a, fred and kim are user variables. Yes: The commands are even identical. (gdb) help call Call a function in the program. The argument is the function name and arguments, in the notation of the current working language. The result is printed and saved in the value history, if it is not void. enjoy, Andrew >From xbestel@aplio.fr Mon Feb 28 06:44:00 2000 From: "Xavier Bestel" To: Subject: single-step Date: Mon, 28 Feb 2000 06:44:00 -0000 Message-id: <03a601bf81fa$3eed2800$30fd62c2@aplio.fr> X-SW-Source: 2000-02/msg00041.html Content-length: 453 Hi ! I have and ARM dev board hooked to a Jeeni, controlled via ethernet. It doesn't singl-step, it only stops at breakpoints. When I issue a "info target", gdb replies that "Target can't single-step". However I would greatly appreciate it to single step to debug my apps ... So do you know how to fix it ? Is it a hardware non-feature or a simple software misconfiguration ? Can gdb emulate singlestepping transparently using breakpoints ? Xav