linking with python
Hi, maybe you know, just in case not... You allow use of bespoke python build for the most part. There is an issue in the linking though - I had to make the following change so that gdb was linked with my python rather than the system one. I suppose that you should set some sort of PYTHONLIBS variable that contains the path to the relevant libs (somewhat like you do for INTERNAL_CPP_FLAGS). CLIBS = $(SIM) $(READLINE) $(OPCODES) $(BFD) $(INTL) $(LIBIBERTY) $(LIBDECNUMBER) \ $(XM_CLIBS) $(NAT_CLIBS) $(GDBTKLIBS) -ldl -lncurses -lz -lm -lpthread -ldl -lutil -lm -lpython2.7 -Xlinker -export-dynamic \ $(LIBEXPAT) \ $(LIBIBERTY) $(WIN32LIBS) $(LIBGNU) CLIBS = $(SIM) $(READLINE) $(OPCODES) $(BFD) $(INTL) $(LIBIBERTY) $(LIBDECNUMBER) \ $(XM_CLIBS) $(NAT_CLIBS) $(GDBTKLIBS) -ldl -lncurses -lz -lm -lpthread -ldl -lutil -lm -L$(MY_PYTHON)/lib -lpython2.7 -Xlinker -export-dynamic \ $(LIBEXPAT) \ $(LIBIBERTY) $(WIN32LIBS) $(LIBGNU) Incidentally, the reason why I was compiling was this: $ gdb `which python` core.23394 gdb: symbol lookup error: gdb: undefined symbol: PyUnicodeUCS4_FromEncodedObject confusion with unicode... Regards, Paul. ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
bug in msp430-gdb
In the windows version it tries to read .gdbinit on start up, but that's in illegal file name in windows. Why not make it gdb.ini? Regards, Paul ___ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Problem with ptype $user register
For the simple hello world program appended, the command sequence
b main
run
ptype $pc
causes an internal GDB error:
.../gdb/regcache.c:163: internal-error: register_type: Assertion `regnum =
0 regnum descr-nr_cooked_registers' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
when run on i686 GNU/Linux with recent sources:
GNU gdb 6.6.50.20070307-cvs
Program compiled with GCC 4.1.2 derivate.
Paul Hilfinger
-foo.c---
#include stdio.h
main ()
{
printf (Hello, world!\n);
}
___
bug-gdb mailing list
bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb
gdb segfault, for x86_64 smp arch, and gcc 4.0.1.
/*
Hello all,
Here is a gdb bug verified for x86_64 smp arch with gcc 4.0.1.
I understand this is somewhat exotic hardware.
I will just use gcc32 for the time being,
I have no time for further chasing of this.
for the program fragment below:
$(CC) gdb_bug.c-o poo \
$(CC) gdb_bug.c -ggdb -o poo \ executibles in class
$(CC) gdb_bug.c -ggdb1 -o poo / `works'
$(CC) gdb_bug.c -ggdb2 -o poo /
$(CC) gdb_bug.c -ggdb3 -o foo }undebugable for gcc v4.0.1
$(CC) is either gcc or gcc32
version info
gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5)
gcc32 (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-47.fc4)
GNU gdb Red Hat Linux (6.3.0.0-1.84rh)
uname -a:
Linux 2.6.13-1.1532_FC4smp #1 SMP Thu Oct 20 01:42:06 EDT 2005 x86_64 x86_64
x86_64 GNU/Linux on x86_64
invoke gdb: file poo, p g, p bob[2] - works as expected
if foo compiled with gcc version 4.0.1, with -ggdb3,
file foo, p g - gdb segfaults
in fact, p anything causes segfault.
Also tested gcc 3.2.2 and 4.0.0 on i686 with gdb Red Hat Linux
(6.1post-1.20040607.43.0.1rh): no problems.
*/
#include stdio.h
static void * p1=NULL;
int g=7;
struct boo{
int a;
int *b;
}bob[20]={
{0,NULL},
{5,NULL},
{23,g},
};
int main(void)
{
return 0;
}
___
Bug-gdb mailing list
Bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb
GDB 5.1.1 porting patches for POSIX 1003.1-2001 hosts
The new POSIX standard is now official (IEEE Std 1003.1-2001), and it
has removed support for some obsolete utility options that the GDB
build procedure uses in a few places. Here is a proposed patch,
relative to GDB 5.1.1, to help ensure that GDB still will build on
POSIX 1003.1-2001 hosts. The patch shouldn't break GDB builds on
older hosts, as it avoids POSIX features that are not available in
pre-POSIX platforms.
I've done this patch by code inspection; I don't actually have a fully
conforming POSIX 1003.1-2001 host yet, though I do have some
experimental commands that insist on the -2001 behavior if you set the
right environment variables.
2002-02-19 Paul Eggert [EMAIL PROTECTED]
* Makefile.in (VER): Change head -1 to sed q, since POSIX
1003.1-2001 no longer allows head -1.
* gdb/Makefile.in (version.c): Likewise.
* gdb/doc/Makefile.in (GDBvn.texi): Likewise.
* gdb/CONTRIBUTE: Change diff -c3 to diff -c, which is
equivalent. POSIX 1003.1-2001 no longer allows diff -c3.
===
RCS file: Makefile.in,v
retrieving revision 5.1.1.0
retrieving revision 5.1.1.1
diff -pu -r5.1.1.0 -r5.1.1.1
--- Makefile.in 2002/01/24 03:52:59 5.1.1.0
+++ Makefile.in 2002/02/20 04:28:34 5.1.1.1
@@ -1762,7 +1762,7 @@ VER = ` if grep 'AM_INIT_AUTOMAKE.*BFD_V
elif grep AM_INIT_AUTOMAKE $(TOOL)/configure.in /dev/null 21; then \
sed $(TOOL)/configure.in -n 's/AM_INIT_AUTOMAKE[^,]*, *\([^)]*\))/\1/p'; \
elif test -f $(TOOL)/version.in; then \
- head -1 $(TOOL)/version.in; \
+ sed q $(TOOL)/version.in; \
elif grep VERSION $(TOOL)/Makefile.in /dev/null 21; then \
sed $(TOOL)/Makefile.in -n 's/^VERSION *= *//p'; \
else \
===
RCS file: gdb/Makefile.in,v
retrieving revision 5.1.1.0
retrieving revision 5.1.1.1
diff -pu -r5.1.1.0 -r5.1.1.1
--- gdb/Makefile.in 2001/11/18 05:08:36 5.1.1.0
+++ gdb/Makefile.in 2002/02/20 04:28:34 5.1.1.1
@@ -1024,7 +1024,7 @@ $(srcdir)/copying.c: @MAINTAINER_MODE_TR
version.c: Makefile version.in
rm -f version.c-tmp version.c
echo '#include version.h' version.c-tmp
- echo 'const char version[] = '`head -1 ${srcdir}/version.in`';'
version.c-tmp
+ echo 'const char version[] = '`sed q ${srcdir}/version.in`';'
+version.c-tmp
echo 'const char host_name[] = $(host_alias);' version.c-tmp
echo 'const char target_name[] = $(target_alias);' version.c-tmp
mv version.c-tmp version.c
===
RCS file: gdb/doc/Makefile.in,v
retrieving revision 5.1.1.0
retrieving revision 5.1.1.1
diff -pu -r5.1.1.0 -r5.1.1.1
--- gdb/doc/Makefile.in 2002/01/21 03:54:43 5.1.1.0
+++ gdb/doc/Makefile.in 2002/02/20 04:28:34 5.1.1.1
@@ -215,7 +215,7 @@ refcard.ps : refcard.dvi
# File to record current GDB version number (copied from main dir version.in)
GDBvn.texi : ${gdbdir}/version.in
- echo @set GDBVN `head -1 $(srcdir)/../version.in` ./GDBvn.new
+ echo @set GDBVN `sed q $(srcdir)/../version.in` ./GDBvn.new
mv GDBvn.new GDBvn.texi
# Updated atomically
===
RCS file: gdb/CONTRIBUTE,v
retrieving revision 5.1.1.0
retrieving revision 5.1.1.1
diff -pu -r5.1.1.0 -r5.1.1.1
--- gdb/CONTRIBUTE 2001/09/26 20:53:27 5.1.1.0
+++ gdb/CONTRIBUTE 2002/02/20 04:28:34 5.1.1.1
@@ -70,7 +70,7 @@ o Submitting Patches
documentation (i.e., .texi files).
The patch itself. If you are accessing the CVS repository use
- cvs update; cvs diff -c3p; else, use diff -c3p OLD NEW or
+ cvs update; cvs diff -cp; else, use diff -cp OLD NEW or
diff -up OLD NEW. If your version of diff does not support
these options, then get the latest version of GNU diff.
___
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb
AMEX and Chase Visa Card, Verisign Certificate, Rapid Traffic and Eif Services for all the readers.At 20% better conditions
Get the American Express(R). Gold Corporate Card Blue for StudentsSM Need extra cash? Get a Line of Credit as low as Prime + 2.99% APR from American Express Centurion Bank. Click here for details. Click Here to apply for your Continental Airlines credit card Apply Now for the Chase i-Card Chase Visa Card, Verisign Certificate, Rapid Traffic and Eif Services for all the readers. At 20% better conditions: follow the links email your requests, fill your forms And enjoy. http://www.angelfire.com/film/chasecard/chase.html Rapid Internet Marketing Newsletter = IN THIS ISSUE 1. Search Engine News Flash 2. Reach 75% of the Internet with one buy 3. SPONSOR # 1 Maximize your keyword bids for "Pay-Per-Clicks" 4. Three Steps To Overture(former Goto.com) Success 5. SPONSOR # 2 DRIVE MORE TRAFFIC TO YOUR WEBSITE FOR FREE 6. How to Subscribe or Unsubscribe == 1. Search Engine News Flash 1). Both Yahoo and LookSmart have recently increased the price of their Express submission service to $299 last month. AltaVista followed Inktomi's lead in offering a paid inclusion program. FAST is expected to bring out its own program shortly. (More details: http://www.altavista.com/sites/search/express_incl) 2)Eif.net and Rapid-Traffic.com are the best search engine ranking Specialist: an NTA report says they have increased the traffic of 25%. 3). LookSmart Adds Paid Listings Option For Small Businesses. A new program called "Site Promote" from LookSmart has made it possible for small businesses and others with low publicity budgets to get listed within the paid placement area of its search results. The new program allows site owners pay a monthly fee of $20 or $30 to appear within the "Featured Listings" area of the LookSmart search results page. These are paid listings that appear above LookSmart's editorial results. (More details at http://listings.looksmart.com) 4). Overture(the former Goto.com) has signed an agreement to provide search results to Yahoo!'s millions of users last month. Users who conduct searches at www.yahoo.com will see search results that include Overture's top three search listings in a section called "Sponsor Matches." Two additional Overture listings will be featured at the bottom of the page in a section called "More Sponsor Matches." When users click on the "Next 20" link, they will also see five additional Overture listings in the same configuration. All listings displayed in the Yahoo! implementation will feature a one line description and URL with full title mouse-over as a part of the search results. = 2. Reach 75% of the Internet with one buy Overture is the one online advertising buy that will drive more targeted customers to your site. With Overture, you only pay when someone clicks on your search listing. And because their search results reach 75% of all Internet users, you can be sure to get tons of high-quality, targeted customer traffic! Advertising with Overture gives you: TREMENDOUS REACH- Expand your customer reach to 75% of all Internet users with just one advertising buy. Overture can put you in the search listings on Yahoo!, America Online, Lycos, AltaVista, Hotbot, Netscape, CNET and many others. TARGETED LEADS- Get your site in front of users right when they are searching for your products, services and information. COST EFFECTIVE- Pay only when targeted leads click through to your site. !!! $10 BONUS CREDIT !!! Earn a special $10 bonus credit if you become a new active Overture advertiser* between now and March 31, 2002. This offer is only valid for new Overture advertisers, and if you've received this message, that's you! Click on http://www.overture.com/d/advertisers/p/bjump/?o=RR-13590b=10 learn more and list your site with Overture. = 3. Sponsor # 1 Maximize your keyword bids for "Pay-Per-Clicks" Dynamic KeywordBid Maximizer is an ultimate search engine promotion tool helps you manage your keywords and bids at ALL major pay-per-click search engines. You can use it to build your keyword list, manage your keywords, monitor your keyword bids and URL positions at all major "Pay-per-click" search engines such as Overure, Overture(UK), FintWhat, 7Search, and Sprinks. It will update your keyword bids, analyze your ranking positions, closing bid gaps and bit to the TOP 3 piosition AUTOMATICALLY: - Save you hundreds of hours per day to maintains and monitors your keyword bids if checking manually. - Saves up to 85% of bid cost by eliminate bid gaps and maintain your current position automatically.(don't over pay for clicks where is not necessary) - Stay on top of your competitors 24 hours a day, 365 days a year by improve your position to the TOP 3 positions automatically. - Automatically monitors your keyword bids once per day or every
Cant fetch registers from this type of core file
Hi, I am having problem when running gdb 4.18 under netbsd 1.4.1 When I tried to debug the core file I got this problem. What caused this? Is this a gdb bug? Any pointer will be really appreciated. Thanks, Paul autumn# ./gdb ribd ribd.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-netbsd1.4.1... Core was generated by `ribd'. Program terminated with signal 4, Illegal instruction. Can't fetch registers from this type of core file Can't fetch registers from this type of core file Can't fetch registers from this type of core file #0 0x0 in ?? () ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: GDB and 64-bit solaris
Cheers, There have been a couple of questions recently (one from me) regarding GDB on 64-bit SPARC Solaris executables. I have a little information. 1. An error such as (gdb) b main Cannot access memory at address 0x0 on an executable with debugging information may be due to the use of stabs debugging info, which I gather does not support 64-bit addresses. For example, you won't see this error in the absence of debugging info (where the minimal symbols are used). 2. An error such as (gdb) run Starting program: /export/home/users/hilfingr/gdb/test64 procfs:3887 -- process not stopped. ? procfs: ...giving up... results from attempting to debug a 64-bit executable process from a 32- bit-compiled GDB. What happens specifically is that all attempts to read from /proc/x/status result in an EOVERFLOW error, with no data read. The process actually IS stopped, but since at the moment GDB 5 does not check that its procinfo calls succeed, you get the message in this form instead, when later parts of procfs_wait read the flags and find 0's for what should be the flags indicating that the process is stopped. Mind you, various annoyances have prevented me from getting a version that actually DOES work yet on Solaris, and I can't vouch for all releases of Solaris (this info is from a 2.7 version of the OS). However, this at least indicates one problem one might face. Paul Hilfinger UC Berkeley ACT Corp. ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: gdb 5.0 cannot print contents of 'string'
Interesting - I found a different problem (but maybe
related) with local string variables.
I didn't try printing, but gdb 5.0 would crash when
single-stepping over that instruction (but it looks like that
worked for you). The program ran full-speed OK.
Maybe it's a software-momentum problem. ;-)
I was using remote debugging (x86 host and arm target)
and it looks like you're using host=target=x86.
I posted the details several weeks ago to this elist but
got no response (maybe people have stopped following
it due to the spam).
I got pulled off onto something else before I could stumble
around in the source code.
One thing I did try that worked for debugging in the past was to
use gdb to debug and single step gdb. You might try that
and maybe you can track down what the problem is.
I'd sure like to know if you get anywhere in case I can get
back to gdb from what I'm doing sometime.
-PaulK
Pierre Sarrazin wrote:
On my Pentium-based RedHat 6.2 machine, gdb 5.0 cannot print
the contents of a C++ string variable. It displays this:
$1 = {static npos = Cannot access memory at address 0x0
This bug was reported for gdb 4.18 in this message:
http://www.bg.debian.org/Bugs/db/47/47482-b.html
I compiled and installed g++ 2.95.2 and gdb 5.0 from the sources.
Here are the details.
$ uname -a
Linux dev.machina.com 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown
$ ls /lib/libc-*
/lib/libc-2.1.3.so
$ g++ -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
gcc version 2.95.2 19991024 (release)
$ ls -l /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/libstdc++.so
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/libstdc++.so
- ../../../libstdc++-libc6.1-2.so.3
$ cat test.cc
#include string
int main()
{
string s;
s = "a"; // line 7
}
$ g++ -g -o test test.cc
$ ldd test
libstdc++-libc6.1-2.so.3 = /usr/local/lib/libstdc++-libc6.1-2.so.3
(0x4001a000)
libm.so.6 = /lib/libm.so.6 (0x40061000)
libc.so.6 = /lib/libc.so.6 (0x4007e000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
$ gdb test
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) b 7
Breakpoint 1 at 0x8049975: file test.cc, line 7.
(gdb) r
Starting program: /home/sarrazip/pgm/bug-gdb-string/test
Breakpoint 1, main () at test.cc:7
7 s = "a";
(gdb) p s
$1 = {static npos = Cannot access memory at address 0x0
(gdb) n
8 }
(gdb) p s
$2 = {static npos = Cannot access memory at address 0x0
(gdb) c
Continuing.
Program exited normally.
(gdb) q
--
Pierre Sarrazin sarrazip at machinasapiens dot com
gdb/insight help
Hello? Could somebody please answer the following...
While awaiting answers for the previously-posted message
(see below), I actually got gbd5 and gdbserver5 talking
to each other, however, there were 2 places that I had to
fix and I don't see how it's possible for them to have
talked otherwise.
I manually applied the patch file (by reading the patch
file and manually finding the right place in the patched
file, and then editing it) to what I downloaded from
cvs yesterday.
The two places that were still broken are:
1) the DECR_PC_AFTER_BREAK is still wrong (should
be 4) for arm (at least my version of chip), and
2) the REGISTER_U_ADDR macro definition in the patch
file you sent is incorrect - the definition needs 'addr ='
to be able to return the calculated address.
Furthermore, gdbserver ought to set some speed rather
than just taking whatever speed the driver is set to.
I got V5 Insight to start up now (it couldn't find the init.tcl file
for some reason so I added a soft-link to where it was),
but I still can't debug. When I start it with:
./insight-gdb nop [nop is the name of the test program]
the source displays on the screen. But when I connect to
the target board, the source on the screen vanishes. I have
found no way to get it back, nor to start the program.
Is this the forum for Insight too?
Paul Kinzelman wrote:
Host machine: RH 6.2 i386
Target Machine: Cirrus EDB7211 arm evaluation board running Linux.
Ok. Is that an ARM 7500FE based board?
I don't recognize that number. The Cirrus manual says EP7211 chip, is
that
what you're asking?
arm-linux-gcc v2.95.2 is preferable.
Hopefully my arm-linux-gcc v2.91.66 will work? I'd rather tackle that
some
other day.
The gdb and insight 5.0 I have is different (in the areas patched
by
your patch file). Please send me a pointer to your 5.0 (gdb and
insight) so
I can start from there with gdb then insight (which will hopefully
match
your patch file). It sounds like redhat may have
their own different V5.0 floating around. That's very confusing.
I get my source from the mainline CVS tree at sources.redhat.com for
both gdb
and insight. I update frequently. The patches I sent were against
source
updated on July 31 I believe.
I just grabbed the CVS tree now and the patch you sent still does not
work.
It fails immediately (Hunk #1 FAILED at 1014.) I tried it in various
place with
various -pN numbers just in case. I think if I'm in the gdb50/gdb area
and use
-p0 it should work, right? I used "patch -p0 ../gdbserv.patch"
But if I look at the patch file, if I'm interpreting it right, it's
saying that at
line 1014 in gdb/configure.in, it should
find "if test "${target}" = ...", but in my copy of gdb/configure.in
(including what
I just downloaded), line 1014 of gdb/configure.in is blank. The line
it seems to
want to refer to is 952 in both what I just downloaded from CVS as
well
as in the tar.gz file I downloaded before. Isn't that why the patch is
failing?
You shouldn't have to. What kernel and libc are on the Linux
system? Is it ELF
or a.out?
The server I'm using to build is 2.2.12-20smp.
The host debug i386 box is 2.2.14-5.0
The target arm board is 2.2.1
I'm using elf for everything.
How do I find the libc version?
-PaulK
insight 5.0/gdbserver problem
I was having a problem trying to build and get running gdbserver 4.18 on i386 host and arm target, so the redhat folks said try 5.0 and gave me a pointer. I downloaded it and insight builds fine, but gdbserver does not. Then I tried following the gdbserver/README to build a vanilla i386/i386 version which also didn't work (see below). I thought I posted something about a week ago and received no response. Anyway, I'm trying to build for the arm. I'm very disappointed to hear that not only have you discontinued support for it, but you've actually ripped some stuff out that used to support it. Somebody probably put a good bit of time in to get it working, it seems a shame to undo that effort (as well as it removes support for an important architecture). Can this decision be reversed? I did get it compiling and am about to try it on the arm (kludging the gdbserver/i386 code to possibly work) which is how I got the 4.18 running on the target/arm before (as well as I had to fix some incorrect arm definitions, for instance DECR_PC_AFTER_BREAK). I was able to source-line debug with emacs over a serial line, but I couldn't make it work with Insight nor over tcpip, which is why the redhat/cygnus folks suggested V5. I finally got V5 compiling and am about to try running it on the arm. Ah, I *finally* got it to work with a vanilla compile also. The gdbserver/README is incorrect, please fix it for next release. It says to do '../../configure i386-none-lynx' and when I do that, I get lots of header files missing. But if I do just '../../configure' it works! It also talks about 'Lynx', should that be Linux (which was my assumption and why I got into problems before)? PaulK
Re: insight 5.0/gdbserver problem
Host machine: RH 6.2 i386 Target Machine: Cirrus EDB7211 arm evaluation board running Linux. I'm trying to get gdbserver to run on Linux on the eval board in user mode to debug user applications using the serial port (and maybe someday tcpip) talking to an i386 linux host machine. On the i386 host machine, I have arm-elf-gcc V2.95.2 and arm-linux-gcc egcs-2.91.66 available to build gdbserver. Is one preferable? For i386, I have egcs-2.91.66 on the server The gdb and insight 5.0 I have is different (in the areas patched by your patch file). Please send me a pointer to your 5.0 (gdb and insight) so I can start from there with gdb then insight (which will hopefully match your patch file). It sounds like redhat may have their own different V5.0 floating around. That's very confusing. Incidently, I had gdb 4.18 running OK (gdb under emacs on the host for source-line debug, gdbserver on the arm/linux board and the serial port) but it didn't work with Insight so the cygnus/redhat folks suggested trying 5.0 to see if that helped. I had to kludge 4.18 to get it to compile and work too. This is incorrect. ARM is supported in version 5.0. Linux support was added in version 5.0. Support for RiscOS was obsoleted as no one is maintaining the code. This is what people referred to as being removed. Glad to hear it! But so far, I've had to make lots of edits to get it to work The gdbserver/README is incorrect, please fix it for next release. This is true. I'll see what can be done. This would be a major help for people, especially if you explain a bit about how to do cross-architecture stuff. What's there is very misleading. Any improvement would be greatly appreciated. -PaulK
Re: insight 5.0 gdbserver on ARM build problems
Thanks! I'm missing a number of things (including now most of my marbles :-)... I was trying to build using ../../configure arm-linux-elf which as I understand it, should configure the arm target to talk with Linux, right? Then I used 'make CC=arm-elf-gcc' I did pull down the latest 5.0 sources already. I had already gotten v2314 to compile and more-or-less work (I could source-line single step under emacs on Linux/x86 targeting the arm, but I couldn't get the gui to work), and somebody suggested I go to the latest, maybe that would fix problems I saw with the gui. When you say arm-*-* is obsolete as host, it should still be OK for target, right? I'm pretty sure the DECR_PC... is wrong for ARM and so if nobody changes that, I don't see any way that what's there would work for ARM. Where I'm at now is stuck in the morass of spagetti header files, unable to get a good build with V5. Many header files are missing from the gdb tree, but are required by remote-utils.c . So I add in the normal Linux include paths manually to the Makefile (yes, I know if I do another configure they'll get stepped on) but that doesn't work either, lots of missing symbols and then multiply-defined symbols (thereby balancing each other out :-). I tried copying and editing the few header files that are called, but each one of those points to 5 other ones so it's a complete mess. There's got to be a better way to do this. I somehow stumbled into making insight-2314 work, but evidently I'm doing something different, or else more stuff has been changed and broken things since that release. I'll go back to see what the difference is between that build that worked and what I'm going for V5. But getting 2314 to build right was no cake-walk either for similar reasons. I remember having to copy header files and make edits in them. Any help would be appreciated. -PaulK Andrew Cagney wrote: Paul Kinzelman wrote: I found that somebody inserted the string "# OBSOLETE" in the .../gdb/config/arm/arm.mt and .mh files, thereby breaking the build for ARM. Also, there are lots of header files missing when I do a standard config and build, the -I path probably needs fixing: stdio.h, errno.h, unistd.h, stdlib.h, setjmp.h, string.h, endian.h And lastly (at least as far as I've gotten), the DECR_PC_AFTER_BREAK definition needs to be 4 in tm-arm.h -PaulK Which OS? I believe ARM Linux works for instance. In the NEWS file is the information: * OBSOLETE configurations Altos 3068 m68*-altos-* Convex c1-*-*, c2-*-* Pyramid pyramid-*-* ARM RISCix arm-*-* (as host) Tahoe tahoe-*-* Configurations that have been declared obsolete will be commented out, but the code will be left in place. If there is no activity to revive these configurations before the next release of GDB, the sources will be permanently REMOVED. No one has been activly maintaining ARM on RISCix for some time and the code is known to have suffered serious bit rot. Could I strongly encourage you to pull in the latest GDB snapshot (see http://sources.redhat.com/gdb/) and look at reviving this target. Andrew
Re: insight 5.0 gdbserver on ARM build problems
Oh yes, and I tried configuring and building gdb first and it works fine: ./configure --target=arm-linux-elf make Then configure gdbserver: cd gdb/gdbserver ../../configure arm-linux make CC=arm-elf-gcc and I get the errors. -PaulK Philip Blundell wrote: I was trying to build using ../../configure arm-linux-elf which as The hostname for GNU/Linux is `arm-linux'. Putting the `-elf' on the end is confusing configure into doing the wrong thing, which is why you're running into these obsolete RISCiX files. p.
insight 5.0 gdbserver on ARM build problems
I found that somebody inserted the string "# OBSOLETE" in the .../gdb/config/arm/arm.mt and .mh files, thereby breaking the build for ARM. Also, there are lots of header files missing when I do a standard config and build, the -I path probably needs fixing: stdio.h, errno.h, unistd.h, stdlib.h, setjmp.h, string.h, endian.h And lastly (at least as far as I've gotten), the DECR_PC_AFTER_BREAK definition needs to be 4 in tm-arm.h -PaulK
gdb 5.0 installation problem with Solaris 8 gcc
When I build GDB 5.0 with the Solaris 8 sparc version of gcc (in /opt/sfw/bin/gcc, shipped on the Software Companion CD), I get a program that can't be executed. 'ldd gdb' reports: libncurses.so.4 = (file not found) The problem is that 'configure' first looks in -lncurses for tgetent, and /opt/sfw/bin/gcc compiles the program successfully because it links to /opt/sfw/lib/libncurses.so, but the program doesn't run because Sun configured gcc to use -L/opt/sfw/lib without using -R/opt/sfw/lib when linking. Arguably this is a misfeature of Sun gcc, but I noticed that gdb/configure.in uses a different search order for tgetent that readline/aclocal.m4 does, and this inconsistency should be removed anyway. Here's a patch. 2000-06-28 Paul Eggert [EMAIL PROTECTED] * configure.in (TERM_LIB): When searching for libraries containing tgetent, prefer termcap, curses, then ncurses. This is the same order as ../readline/aclocal.m4, and it works around a bug in the GCC 2.95.2 installation that is shipped with Solaris 8. === RCS file: configure.in,v retrieving revision 5.0 retrieving revision 5.0.0.1 diff -pu -r5.0 -r5.0.0.1 --- configure.in2000/05/11 00:32:18 5.0 +++ configure.in2000/06/28 20:13:52 5.0.0.1 @@ -588,11 +588,11 @@ if test x$gdb_cv_os_cygwin = xyes; then TERM_LIB='`if test -r ../libtermcap/libtermcap.a; then echo ../libtermcap/libtermcap.a; else echo -ltermcap; fi`' else TERM_LIB= - AC_CHECK_LIB(ncurses, tgetent, TERM_LIB=-lncurses, -AC_CHECK_LIB(Hcurses, tgetent, TERM_LIB=-lHcurses, - AC_CHECK_LIB(termlib, tgetent, TERM_LIB=-ltermlib, -AC_CHECK_LIB(termcap, tgetent, TERM_LIB=-ltermcap, - AC_CHECK_LIB(curses, tgetent, TERM_LIB=-lcurses, + AC_CHECK_LIB(termcap, tgetent, TERM_LIB=-ltermcap, +AC_CHECK_LIB(curses, tgetent, TERM_LIB=-lcurses, + AC_CHECK_LIB(ncurses, tgetent, TERM_LIB=-lncurses, + AC_CHECK_LIB(Hcurses, tgetent, TERM_LIB=-lHcurses, + AC_CHECK_LIB(termlib, tgetent, TERM_LIB=-ltermlib, AC_CHECK_LIB(terminfo, tgetent, TERM_LIB=-lterminfo)) if test "x$TERM_LIB" = x
Re: Closest symbol to a byte location
P Costello wrote: What I need is: I want to be able to identify what data structure, function, or code segment where a given byte difference is located. That is: What is the closest symbol associated with the byte location with an ELF format file. GDB does not seem to be enough. How can you relate the byte offset within a binary to the actual code location? The inforation you are after is definitely there, the trick is getting it. The "objdump" command is your friend. First execute objdump -h exe The output should resemble: a.out: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .interp 0013 080480f4 080480f4 00f4 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .note.ABI-tag 0020 08048108 08048108 0108 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .hash 00b8 08048128 08048128 0128 2**2 ... Pay close attention to "File off" and "Size" fields. Now you should be able to tell in which section the difference occures. Unfortunately, what to do next very much depends on what section is affected. The .note and .comment sections could be ignored. OTOH, they also might provide a clue about the differences: objdump -sj.comment a.out a.out: file format elf32-i386 Contents of section .comment: 00474343 3a202847 4e552920 65676373 .GCC: (GNU) egcs 0010 2d322e39 312e3636 20313939 39303331 -2.91.66 1999031 0020 342f4c69 6e757820 28656763 732d312e 4/Linux (egcs-1. 0030 312e3220 72656c65 61736529 4743 1.2 release)..GC ... If the difference is in .text, .init, .fini, .ctors or some other "code" section, you can disassemble it with "objdump -d" If it is in .data, .rodata, or some other "data" section (better not be in .bss), you'll need to decode debug stabs with "objdump --stabs". Cheers, -- Paul Pluzhnikov[EMAIL PROTECTED]
Re: C++ debug problem -- is that a bug???
I agree, your print statement should work.
I get the same mesage and unfortanately have no idea how to get around it.
The documentation indicates to me that the print statement should work.
"Chih-Wei(Jim) Chang" wrote:
Hi,
Sorry if this is not a bug. But this is something bothers me a lot
these days.
I recently switched my OS from Solaris to Mandrake Linux 7.0.
It seems I have some problem debugging my c++ code using gdb. Here is a
sample code:
#include iostream.h
class MyClass
{
private:
int a;
public:
MyClass() {a = 1;}
int Get_a() {return a;}
};
main()
{
MyClass inst;
cout inst.Get_a() endl;
}
After compiling the code using "g++ -g main.cxx", I launch gdb by
"gdb a.out". And start tracing the code:
[cwchang@localhost ~/tmp]$ g++ -g main.cxx
[cwchang@localhost ~/tmp]$ a.out
1
[cwchang@localhost ~/tmp]$ gdb a.out
GNU gdb 19991116
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-mandrake-linux"...
(gdb) b main
Breakpoint 1 at 0x8048656: file main.cxx, line 16.
(gdb) r
Starting program: /home/cwchang/tmp/a.out
Breakpoint 1, main () at main.cxx:16
16 MyClass inst;
(gdb) n
18 cout inst.Get_a() endl;
(gdb) p inst.Get_a()
Cannot resolve method MyClass::Get_a to any overloaded instance
^^^
(gdb) ptype inst
type = class MyClass {
private:
int a;
public:
MyClass operator=(MyClass const );
MyClass(MyClass const );
MyClass(void);
int Get_a(void);
int Get_b(int);
}
(gdb) info source
Current source file is main.cxx
Compilation directory is /home/cwchang/tmp/
Located in /home/cwchang/tmp/main.cxx
Contains 22 lines.
Source language is c++.
Compiled with stabs debugging format.
(gdb)
--
"Cannot resolve method MyClass::Get_a to any overloaded instance"
What does this mean? It seems I cannot not execute the expression
because gdb cannot find the corresponding reference. I have no
problem debugging this piece of code on my Solaris machine (the
command "p inst.Get_a()" have no problem get executed) Is this
a machine-dependent issue?
Any idea? Thanks in advance.
Jim
--
Regards,
Paul Hardiman
InterMedia, Inc (Colorado)
Informations Systems Consulting
303-581-0606, Fax 581-0506, [EMAIL PROTECTED]
