From: kbhend <kbhend@business.wm.edu>
To: "Kevin Buettner" <kev@primenet.com>,
Franz Sirl <Franz.Sirl-kernel@lauterbach.com>,
linuxppc-dev@lists.linuxppc.org, gdt@linuxppc.org
Subject: Re: gdb broken under linuxppc r5 tools
Date: Mon, 2 Aug 1999 11:21:19 -0400 [thread overview]
Message-ID: <99080211313600.00413@localhost.localdomain> (raw)
In-Reply-To: 990801202455.ZM22552@redrock.lan
Hi Kevin,
> Kevin, Franz, et.al,
>
> Earlier this year, Metrowerks and I signed the copyright assignments
> required by the FSF. Beginning August 9, I will be starting work at
> Cygnus as a GDB engineer. One of the things that I'll work on is a
> merge of my patches into the current gdb mainline. It'll be my goal
> to get a solid, usable gdb up and running on Linux/PPC again.
Congrats! It is good to hear from you again! We still miss you on the LinuxPPC
JDK porting team! Care to rejoin?!? :-)
As for gdb, something changed seriously between Paul's 2.2.1 kernel running on
a R4.1 build (gdb was very very stable when debugging shared libs) and Paul's
2.2.10 kernel running LinuxPPC R5 or YDL.
I tried Gary's 4.18 src rpm and it rebuilt fine under R5 but shows exactly the
same error mode as the 4.17 builds. I will put a breakpoint at a function in a
shared lib (such as awt_allocate_colors in libawt.so) and the function address
returned by gdb when it says it places the breakpoint is typically not a valid
address (typically something in 0x00XXXXXX or 0x0XXXXXXX range).
Sometimes it ends up putting the breakpoint into another routine (often glibc)
which you can see if luckily your code uses that other shared lib.
This is so frustrating. If I can find (by chance) the actual location of the
shared lib routine (by disassmebling large pieces of memory) and use the exact
address to place the breakpoint, it will actually stop there.
Some change to the debugging symbols must have been made to cause this I think,
but I am not sure.
Anyway, I hope you can recreate these problems and can find a solution!!!!
Thanks,
Kevin H.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
next prev parent reply other threads:[~1999-08-02 15:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-08-01 13:01 current recommended versions of glibc/egcs/binutils for R5? R Shapiro
1999-08-01 13:58 ` Franz Sirl
1999-08-01 18:38 ` gdb broken under linuxppc r5 tools Kevin B. Hendricks
1999-08-01 19:03 ` Franz Sirl
1999-08-01 20:12 ` kbhend
1999-08-01 20:24 ` Kevin Buettner
1999-08-01 20:54 ` Franz Sirl
1999-08-02 11:20 ` Gary Thomas
1999-08-02 15:21 ` kbhend [this message]
1999-08-02 15:50 ` Daniel Jacobowitz
1999-08-02 16:01 ` kbhend
1999-08-22 15:09 ` bug in glibc 2.1.2 new semaphore functions in libpthread? Kevin Hendricks
1999-08-24 21:09 ` Franz Sirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=99080211313600.00413@localhost.localdomain \
--to=kbhend@business.wm.edu \
--cc=Franz.Sirl-kernel@lauterbach.com \
--cc=gdt@linuxppc.org \
--cc=kev@primenet.com \
--cc=linuxppc-dev@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).