headers
Per Bothner | 1 Dec 2002 20:04

Re: bye-bye boolean

Alan Modra wrote:

> Here goes my biggest commit.  s/boolean/bfd_boolean/ s/true/TRUE/
> s/false/FALSE/ practically everywhere in binutils,

My strong recommendation:

s/true/1/
s/false/0/
s/boolean/int/

This is C.  Pretending C is Pascal does not make it so.
It makes for one more magic thing binutils-hackers have to learn,
and get wrong.
--

-- 
	--Per Bothner
per <at> bothner.com   http://www.bothner.com/per/
Permalink | Reply | 2 comments |
headers
Andrew Cagney | 1 Dec 2002 20:49
Picon
Favicon

Re: bye-bye boolean

> Alan Modra wrote:
> 
> Here goes my biggest commit.  s/boolean/bfd_boolean/ s/true/TRUE/
> s/false/FALSE/ practically everywhere in binutils,
> 
> My strong recommendation:
> 
> s/true/1/
> s/false/0/
> s/boolean/int/
> 
> This is C.  Pretending C is Pascal does not make it so.
> It makes for one more magic thing binutils-hackers have to learn,
> and get wrong.

BTW, that's what my follow up, to fix the GDB fallout, did.

Andrew
Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 1 Dec 2002 22:18

Re: Porting GDB - Where to start?

On Tue, Nov 26, 2002 at 04:53:15PM +0100, James Sampson wrote:
> >> 1. Why is xstormy16 the best place to start?.
> >
> >Being fairly new, and for a relatively straightforward architecture, it
> >doesn't come with much baggage.  It's roughly 1000 lines long, while the
> >MIPS is a wopping 6000 lines!
> 
> Ok! - I had the impression it had more than 200Kb of source code. Is it 
> because a lot of the code is similar from target to target, and doesn't need 
> much change? (I assume you mean a 1000 lines of code which has to be more or 
> less produced)
> 
> 
> >> 2. Since I can't use GCC to make target specific code for a C55x I must use
> >> CCS (Code Composer Studio) from TI. What could a "got-ya" be?.
> >
> >There is a good chance that after you've kind of got the target `mostly'
> >working, you will spend time debugging problems in the symtab code.
> >This is because, when it comes to debug info, no two compilers are
> >alike.   Consequently, is a very good chance that GDB won't properly
> >handle the debug info being output by this compiler.
> >
> >Anyway, a first step is to find out what the debug info is and if GDB
> >has any support for it at all ....  One way is to compile a simple
> >program using `-g -S' and then look at the assembler that is created.
> >If it contains ``.stabn'' lines its stabs, if it contains ``.debug_...''
> >symbols it's dwarf2 (or dwarf1?).  Beyond that, you may want to post the
> >contents here.
> 
> In CCS you have the option to use COFF or DWARF. I was planning on using COFF,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Daniel Jacobowitz | 1 Dec 2002 22:20

Re: threads and the new NPTL thread library

On Tue, Nov 26, 2002 at 10:05:01PM -0500, Elena Zannoni wrote:
> 
> 
> I think people are aware of a new thread library that Uli Drepper
> are Roland McGrath are working on.
> Detailed information is on the phil-list <at> redhat.com mailing list.
> I see a few familiar names there.
> 
> 
> Gdb doesn't currently work with the new nptl_db. :-( 
> Has anybody played with this yet?

Not really...  I've been poking at the necessary kernel support for
some of the features and couldn't decide what to do.

For instance, trace what happens via ptrace/wait if a threaded program
exec's.  Threads can just disappear unexpectedly instead of exiting
cleanly.

--

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer
Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 1 Dec 2002 22:21

Re: [ADMINISTRIVIA] New RDA mailing list

On Wed, Nov 27, 2002 at 10:18:22AM -0500, Andrew Cagney wrote:
> 
> >Hi Christopher,
> >
> >does that mean that things like my RFC
> >[RFC] Correct gdbserver register packets
> >
> >http://sources.redhat.com/ml/gdb-patches/2002-11/msg00652.html
> >
> >about a modification to gdbserver should be discussed in that mailing list?
> 
> No.  GDBSERVER is part of GDB (which is part of the FSF's GNU project) 
> and it should continue to be discussed here.

I really wish we could come to some resolution about the overlap. 
Should we sacrifice the FSF-owned gdbserver project in favor of
extending RDA?  As it is, there's a substantial amount of duplicated
effort.  I hate seeing effort wasted.

--

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer
Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 1 Dec 2002 22:35

Re: Ctrl-c problem

On Fri, Nov 29, 2002 at 04:07:14PM -0500, Richard Brunelle wrote:
> Hi,
> 
> I'm doing kernel debugging through the use of gdb running on a 
> development machine and a gdb stub running on a target machine. The 
> latter is acheive with the kgdb patch applied to a kernel 2.4.18. This 
> patch allows me to connect a development PC to a target PC through a 
> serial line. It allows me to remotely debug a patched kernel. The 
> connection works fine, I'm able to connect gdb to the target machine at 
> boot time (target remote /dev/tyS0). The problem is not hardware. I am 
> able to step in the kernel code at this time. After a few step, I resume 
> the execution of the kernel with the continue command.
> 
> My problem comes when I want to stop the execution of the target kernel 
> with gdb. Usually Ctrl-c is used to stop the execution of the running 
> process. So I hit Ctrl-c but the kernel never stop.
> 
> Is there any configuration for gdb to enable Ctrl-c?
> 
> Does anyone ever experience this problem?

What's your target platform?  C-c works using the x86 KGDB stub.  I
don't know if it works on PowerPC, and it definitely doesn't work on
MIPS.  This is a stub question.

--

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer
(Continue reading)

Permalink | Reply | 5 comments |
headers
Andrew Cagney | 1 Dec 2002 23:48
Picon
Favicon

Re: [ADMINISTRIVIA] New RDA mailing list


>> No.  GDBSERVER is part of GDB (which is part of the FSF's GNU project) 
>> and it should continue to be discussed here.
> 
> 
> I really wish we could come to some resolution about the overlap. 
> Should we sacrifice the FSF-owned gdbserver project in favor of
> extending RDA?  As it is, there's a substantial amount of duplicated
> effort.  I hate seeing effort wasted.

gdb/gdbserver/ is the FSF's (and hence GDB's) remote debug agent.  There 
is no benefit to the FSF, and its objectives, in replacing something (C) 
FSF with something (C) Red Hat.

Andrew
Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 2 Dec 2002 00:19

Re: [ADMINISTRIVIA] New RDA mailing list

On Sun, Dec 01, 2002 at 05:48:09PM -0500, Andrew Cagney wrote:
> 
> >>No.  GDBSERVER is part of GDB (which is part of the FSF's GNU project) 
> >>and it should continue to be discussed here.
> >
> >
> >I really wish we could come to some resolution about the overlap. 
> >Should we sacrifice the FSF-owned gdbserver project in favor of
> >extending RDA?  As it is, there's a substantial amount of duplicated
> >effort.  I hate seeing effort wasted.
> 
> gdb/gdbserver/ is the FSF's (and hence GDB's) remote debug agent.  There 
> is no benefit to the FSF, and its objectives, in replacing something (C) 
> FSF with something (C) Red Hat.

There is no benefit to the community in having a publicly developed RDA
that I can see.  Right now I don't believe it has any features that
gdbserver doesn't, although I could be wrong - I only checked briefly -
I know that it used to have threads support when gdbserver didn't but
we implemented that before RDA was released.

And now Red Hat employees can contribute things like tracepoint support
to the community by adding them to the (c) Red Hat RDA, when the
community would benefit as much or more having them in gdbserver.  So
we get two stubs with mostly-overlapping but different feature sets.

Obviously Red Hat doesn't want to drop RDA in favor of gdbserver.  But
having gdbserver as a second-rate cousin until someone spends weeks
playing feature catchup with RDA (e.g. I or someone else finds the time
to implement the introspect stuff in gdbserver, if I can even do it...)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 2 Dec 2002 07:16
Picon

Re: Porting GDB - Where to start?


On Sun, 1 Dec 2002, Daniel Jacobowitz wrote:

> > In CCS you have the option to use COFF or DWARF. I was planning on using COFF, 
> > because I have noticed some C54x COFF file thingies in the BFD, which could be 
> > usable :-D. Do you know if they are?.
> 
> If those are the two switches that's pretty bizarre.  COFF is a file
> format, DWARF a debug info format.

Not 100% accurate, AFAIK: there's also COFF debug info format.

> You probably want DWARF (DWARF-2) which implies ELF format files.

DWARF-2 is also supported with COFF binary format.  DJGPP uses that 
combination.
Permalink | Reply | 2 comments |
headers
Shrinivas Atre | 2 Dec 2002 08:31

Unreviewed PATCH: SH Simulator - MAC.L implementation and MAC.W correction

Hi,

Could someone please review the following patch for SH-simulator ?

http://sources.redhat.com/ml/gdb/2002-11/msg00365.html

Regards,
Shrinivas
Permalink | Reply | 0 comments |

Gmane