headers
Gregor Riepl | 1 Jun 2004 02:49
Picon

Building a cross-gdb with host=i686-pc-linux-gnu and target=powerpc-apple-darwin

Hi, this is my first posting here.

How can I build a cross-gcc on my Linux box (host=i686-pc-linux-gnu) for 
kernel debugging on my iBook G4 running Mac OS X 10.3.4? Apple doesn't cover 
this issue in their docs and I couldn't find any decent cross-gdb information 
on the net.
I tried to use gdb-5.3 with a more recent libbfd (the included one doesn't 
know about Darwin), but this gives me a gdb that doesn't understand Mach-O:
"I'm sorry, Dave, I can't do that.  Symbol format `mach-o-be' unknown."
gdb-6.3 builds, but I don't get a gdb, only a few support libs.
I also tried Apple's gdb-309, which seems to need Darwin headers.
Maybe I can get it to work if I just copy those over.

Has someone tried this?
gdb should easily do the job, but I had no luck yet.
Thanks for your help!

Gregor
Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 1 Jun 2004 03:43

Re: preprocessor support?

On Fri, May 28, 2004 at 03:35:52PM -0400, Paul Koning wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow <at> false.org> writes:
> 
>  Daniel> On Fri, May 28, 2004 at 03:24:19PM -0400, Paul Koning wrote:
>  >> These days GCC will output dwarf2 debug sections listing
>  >> preprocessor symbol definitions, but gdb 6.1 doesn't seem to look
>  >> at that (at least not for mips-netbsd).
>  >> 
>  >> Is that not implemented yet?  Is it in some targets but not this
>  >> one (and if so, any pointers to places I might look to teach this
>  >> target a new trick)?
> 
>  Daniel> It should work everywhere, so you'll have to dig at it
>  Daniel> harder.  I'm not sure that it's tested; there's at least one
>  Daniel> test in the testsuite but I don't see it going out of its way
>  Daniel> to pass -g3, so the binary won't have macro information.
> 
> To be more specific:
> 
> I looked at the .S file coming out of gcc, and saw the macro debug
> data.
> 
> I then linked the executable file, did an objdump on that, and again
> saw the macros in the debug data (.debug_macinfo section).
> 
> I then fed the executable to gdb, and asked it to print me the value
> of a couple of preprocessor symbols, like TEST which I defined and
> __GNUC__ which gcc put in.  Gdb said:
>   No symbol "__GNUC__" in current context.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 1 Jun 2004 03:44

Re: Building a cross-gdb with host=i686-pc-linux-gnu and target=powerpc-apple-darwin

On Tue, Jun 01, 2004 at 02:49:17AM +0200, Gregor Riepl wrote:
> Hi, this is my first posting here.
> 
> How can I build a cross-gcc on my Linux box (host=i686-pc-linux-gnu) for 
> kernel debugging on my iBook G4 running Mac OS X 10.3.4? Apple doesn't cover 
> this issue in their docs and I couldn't find any decent cross-gdb information 
> on the net.
> I tried to use gdb-5.3 with a more recent libbfd (the included one doesn't 
> know about Darwin), but this gives me a gdb that doesn't understand Mach-O:
> "I'm sorry, Dave, I can't do that.  Symbol format `mach-o-be' unknown."
> gdb-6.3 builds, but I don't get a gdb, only a few support libs.
> I also tried Apple's gdb-309, which seems to need Darwin headers.
> Maybe I can get it to work if I just copy those over.
> 
> Has someone tried this?
> gdb should easily do the job, but I had no luck yet.
> Thanks for your help!

There's no Darwin support in GDB outside of Apple's sources, so you're
out of luck asking here.  Might want to try an Apple list instead.

--

-- 
Daniel Jacobowitz
Permalink | Reply | 1 comment |
headers
Nick NoSpam | 1 Jun 2004 07:04
Favicon

Re: breakpoints and pthreads

I finally found the cause of this problem--a stripped libpthread.
Gentoo strips it when emerging glibc.  To avoid this in Gentoo, add
nostrip to FEATURES.  ie:
 $> FEATURES=nostrip emerge glibc

Regards,
Nick

On Mon, 2004-05-24 at 04:28, Nick NoSpam wrote:
> Any ideas on this issue?  Should I file a bug?
> 
> I fiddled w/ this a little more and found that setting a breakpoint in
> the thread callback ('wait_thread' in the example below) causes
> problems.
> This is the output I get when the thread gets created:
> 
> Program received signal SIG32, Real-time event 32.
> Cannot remove breakpoints because program is no longer writable.
> It might be running in another process.
> Further execution is probably impossible.
> 0x4002ba34 in pthread_getconcurrency () from /lib/libpthread.so.0
> 
> Regards,
> Nick
> 
> 
> On Wed, 2004-05-19 at 21:33, Nick NoSpam wrote:
> > Hi,
> > 
> > I started using gdb a few months ago on RedHat (originally installed as
(Continue reading)

Permalink | Reply | 1 comment |
headers
MuthuKumar-15 | 1 Jun 2004 13:46
Favicon

pthread type 1x1 or MxN


Hello All

    I have a need as How to check at run time, whether a running application uses 1X1 or MXN thread model on HP-UNIX platform?
     Is there any symbols to identify the type of threads ,the application uses ?

Regards,
Muthukumar.

---
===============  It is a "Virus Free Mail" ===============
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.692 / Virus Database: 453 - Release Date: 5/28/2004
Permalink | Reply | 0 comments |
headers
Andrew Cagney | 1 Jun 2004 16:03
Picon

Is this i18n?

Hello,

I'm wondering if something like this:

   xstrprintf ("Set %s\n%s", "debugging of remote protocol", "When 
enabled, each packet sent or received with the remote target is displayed");

is valid i18n.  I think it is, unlike something like:

   concat ("Set ", "debugging of remote protocol", "\n", "...", NULL);

Assuming it is (I think so), there's the possibility of a significant 
cleanup.

Andrew
Permalink | Reply | 3 comments |
headers
Daniel Jacobowitz | 1 Jun 2004 16:08

Re: Is this i18n?

On Tue, Jun 01, 2004 at 10:03:48AM -0400, Andrew Cagney wrote:
> Hello,
> 
> I'm wondering if something like this:
> 
>   xstrprintf ("Set %s\n%s", "debugging of remote protocol", "When 
> enabled, each packet sent or received with the remote target is displayed");
> 
> is valid i18n.  I think it is, unlike something like:
> 
>   concat ("Set ", "debugging of remote protocol", "\n", "...", NULL);
> 
> Assuming it is (I think so), there's the possibility of a significant 
> cleanup.

It does permit the translator to move the "Set" around, but it doesn't
permit it to wander into the "debugging of" clause, or to be on
different sides depending on the item.  I think the TP would prefer to
have "Set debugging of remote protocol" in the PO file.

But I'm a far, far cry from an i18n expert.  Is there a TP list for
this sort of question?

--

-- 
Daniel Jacobowitz
Permalink | Reply | 1 comment |
headers
Paul Koning | 1 Jun 2004 16:49

Re: preprocessor support?

>>>>> "Daniel" == Daniel Jacobowitz <drow <at> false.org> writes:

 Daniel> ...So the macro code is not handling creation of a default
 Daniel> source location right; this is a recurring problem, I
 Daniel> think...

Great, thanks!

That sounds exactly like the problem where you can't examine variables
whose names match that of a type, until you've touched some other
(unambiguous) variable in the same source file.

      paul
Permalink | Reply | 0 comments |
headers
Michael Elizabeth Chastain | 1 Jun 2004 16:53
Picon

gdb and binutils build broken -- Makefile.def gcc-no-bootstrap change

Hello Paolo,

This change to Makefile.tpl has broken the gdb build:

   <at>  <at>  -1203,19 +1203,17  <at>  <at> 
    <at> if gcc
   maybe-all-gcc: all-gcc
   all-gcc: configure-gcc
  + <at> endif gcc
  + <at> if gcc-no-bootstrap
	  r=`${PWD_COMMAND}`; export r; \
	  s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
  +	$(SET_LIB_PATH) \
	  $(GCC_HOST_EXPORTS) \
  -	if [ -f stage_last ] ; then \
  -	  true ; \
  -	elif [ -f gcc/stage_last ] ; then \
  -	  $(SET_LIB_PATH) \
  +	if [ -f gcc/stage_last ] ; then \
	    (cd gcc && $(MAKE) $(GCC_FLAGS_TO_PASS) quickstrap); \
	  else \
  -	  $(SET_LIB_PATH) \
	    (cd gcc && $(MAKE) $(GCC_FLAGS_TO_PASS) all); \
	  fi
  - <at> endif gcc

The problem is that 'gcc' is not defined when I build gdb.
In the old code, the whole maybe-all-gcc was wrapped in " <at> if gcc".
In your new code, the maybe-all-gcc is getting all the rules
that are supposed to be defined only for all-gcc.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Paolo Bonzini | 1 Jun 2004 18:11
Picon

Re: gdb and binutils build broken -- Makefile.def gcc-no-bootstrap change

I'm trying a patch.  I'll let you know in a few minutes.

Paolo
Permalink | Reply | 0 comments |

Gmane