Re: [Sim] Patch to sim/common/cgen-ops.h

Re: [Sim] Patch to sim/common/cgen-ops.h

[Ben Elliston]

    > Why is CGEN follow the GCC convention of SI, UI, BI, ZI, NFI, rather
    > than the sim-common convention of signed8, unsigned64, ...

   'cus cgen rtl is based on gcc rtl and I like having the types be the
   same in the emitted code as in the rtl.

I think Andrew was asking why the rtl uses these names.  Using other names
for the modes would not preclude the use of an rtl, it just wouldn't look
like GCC's.  Is that a bad thing, given that it would allow the programmer
to be more explicit about data representation on the target side?

Ben

Re: [Sim] Patch to sim/common/cgen-ops.h

[Doug Evans]

Ben Elliston writes:
 >     > Why is CGEN follow the GCC convention of SI, UI, BI, ZI, NFI, rather
 >     > than the sim-common convention of signed8, unsigned64, ...
 > 
 >    'cus cgen rtl is based on gcc rtl and I like having the types be the
 >    same in the emitted code as in the rtl.
 > 
 > I think Andrew was asking why the rtl uses these names.  Using other names
 > for the modes would not preclude the use of an rtl, it just wouldn't look
 > like GCC's.  Is that a bad thing, given that it would allow the programmer
 > to be more explicit about data representation on the target side?

Andrew may have just been refering to the name choice used in the
generated code.  Either way, this is just a naming choice issue.
I like the current scheme.
From jtc@redback.com Mon Dec 04 10:53:00 2000
From: jtc@redback.com (J.T. Conklin)
To: muller@cerbere.u-strasbg.fr
Cc: Fernando Nasser <fnasser@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: Build failure on Linux - strnicmp undefined
Date: Mon, 04 Dec 2000 10:53:00 -0000
Message-id: <5mbsusdnn5.fsf@jtc.redback.com>
References: <3A27DBEA.D403D88A@cygnus.com> <5mlmu0m21z.fsf@jtc.redback.com> <3.0.6.32.20001202145640.008ffca0@ics.u-strasbg.fr>
X-SW-Source: 2000-12/msg00076.html
Content-length: 1564

>>>>> "muller" == muller  <muller@cerbere.u-strasbg.fr> writes:
muller> Thanks for checking it in. I only realized this after
muller> committing it when I tried to compile it also on a Linux
muller> machine.
muller>
muller> However, I also found strnicmp in src/gdb/nlm/gdserve.c so I
muller> wasn't sure that I should do the change.

That's something of a special case.  nlm/* is a gdbserver for NetWare
systems.  With a bit of work and restructuring, I think it could be
restructured and folded into the "real" gdbserver.  I don't know if
anyone cares anymore.

muller> On the other side you can find in src/gdb/ser-e7kpc.c that
muller> strncasecmp is replaced by strnicmp by a macro for MSVC but
muller> several other files using strncasecmp do not have this macro
muller> defined. Unless this is automatically created by the configure
muller> execution, in which case the defines inside the c source files
muller> would be unnecessary.

When different idioms that accomplish the same thing are used in the
same program it is difficult to understand which one is prefered.  As
code is often used as an example, it's best to have good examples for
people to follow.

In this case, I think we can simply use str{n,}casecmp() throughout
the code, because an implementation is provided in libiberty.  If for
some reason it's important to use str{n,}icmp() on those systems that
provide that API instead, I think the proper place to do this is in
gdb_string.h instead of scattered throughout half a dozen *.c files.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From dje@transmeta.com Mon Dec 04 10:55:00 2000
From: Doug Evans <dje@transmeta.com>
To: Ben Elliston <bje@redhat.com>
Cc: Doug Evans <dje@transmeta.com>, <gdb-patches@sources.redhat.com>, <cgen@sources.redhat.com>
Subject: Re: [Sim] New sim/common/cgen.sh
Date: Mon, 04 Dec 2000 10:55:00 -0000
Message-id: <14891.59510.53616.923378@casey.transmeta.com>
References: <Pine.LNX.4.30.0012042046450.4659-100000@moshpit.cygnus.com> <Pine.LNX.4.30.0012042057050.4684-100000@moshpit.cygnus.com>
X-SW-Source: 2000-12/msg00078.html
Content-length: 421

Ben Elliston writes:
 >       Also, while the existing script has problems with parallel makes, your
 >       version has even worse problems.  You might want to fix that.
 > 
 > I have also just fixed genmloop.sh so that it has an -outfile-suffix option.
 > This allows the generated files to form unique filenames -- so it, too, can
 > be run by a parallel make.

Can't this problem be solved without adding an option?
From jtc@redback.com Mon Dec 04 11:05:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: muller@cerbere.u-strasbg.fr, Fernando Nasser <fnasser@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: Build failure on Linux - strnicmp undefined
Date: Mon, 04 Dec 2000 11:05:00 -0000
Message-id: <5m7l5gdn1x.fsf@jtc.redback.com>
References: <3A27DBEA.D403D88A@cygnus.com> <5mlmu0m21z.fsf@jtc.redback.com> <3.0.6.32.20001202145640.008ffca0@ics.u-strasbg.fr> <3A2909B9.5EEF2DC2@cygnus.com>
X-SW-Source: 2000-12/msg00079.html
Content-length: 752

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> However, I also found strnicmp in src/gdb/nlm/gdserve.c so I wasn't
>> sure that I should do the change.

Andrew> I think this can go.

I think we better leave this be for now.  nlm/* builds gdbserve.exe, 
a gdbserver-like remote protocol debug agent for NetWare systems.  

The NetWare C library NLM has str{n,}icmp() but not str{n,}casecmp().
While we could probably link with libiberty, I wouldn't go down that
road unless it's considered a high priority and there's some means for
testing the results.  When I last worked with nlm/*, it was rather 
fragile.  I don't think the years of neglect since then have done it 
any favors.  

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Mon Dec 04 11:34:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfc] add __FILE__ and __LINE__ to internal_error()
Date: Mon, 04 Dec 2000 11:34:00 -0000
Message-id: <5mzoicc75w.fsf@jtc.redback.com>
References: <3A2789DD.ABA82A16@cygnus.com>
X-SW-Source: 2000-12/msg00080.html
Content-length: 943

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> This is part one of a two step process to completly eliminate all
Andrew> remaining abort() calls in GDB.
Andrew> Part two involves replacing abort() with ``internal_error (__FILE__,
Andrew> __LINE__, "legacy call to abort()");''.
Andrew>
Andrew> Look ok?

While I can appreciate the need to uniquely identify a specific call
to internal_error(), one thing I don't care for is how __FILE__ and
__LINE__ are added to each call.  I think it clutters things up more
than is necessary.

Unfortunately, without requiring gcc or C9X, we can't use macros with
variable argument lists.  Otherwise, I would recommend that internal-
error() and internal_verror() be macros that expand __FILE__ and __LINE__
before calling "real" functions under the hood.

So given that there aren't really any viable alternatives, I'm OK with
this.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From dje@transmeta.com Mon Dec 04 12:20:00 2000
From: Doug Evans <dje@transmeta.com>
To: Ben Elliston <bje@redhat.com>
Cc: <gdb-patches@sources.redhat.com>, <cgen@sources.redhat.com>
Subject: Re: [Sim] Large patch to sim/common/genmloop.sh
Date: Mon, 04 Dec 2000 12:20:00 -0000
Message-id: <14891.64601.891762.921898@casey.transmeta.com>
References: <14891.11249.377825.198559@casey.transmeta.com> <Pine.LNX.4.30.0012041715290.4012-100000@moshpit.cygnus.com>
X-SW-Source: 2000-12/msg00081.html
Content-length: 479

Ben Elliston writes:
 >    Except for minimizing the amount of changes, is there any reason to
 >    keep the cpu prefix?
 > 
 > Yes.  In some contexts (namely modelling), it makes sense to refer to @cpu@:
 > 
 > 	#define WANT_CPU_@CPU@
 > 	[...]
 > 	@cpu@_model_insn_before (current_cpu, first_p);
 > 	[etc].
 > 
 > But correct me if I am mistaken.

Ah.

You may or may not want different versions of these for each ISA.
I kinda hate to have both prefix and cpu if one will do.
From Peter.Schauer@regent.e-technik.tu-muenchen.de Mon Dec 04 12:54:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: dberlin@redhat.com (Daniel Berlin)
Cc: gdb@sources.redhat.com, gdb-patches@sources.redhat.com
Subject: Re: Removal of demangled names from partial symbols
Date: Mon, 04 Dec 2000 12:54:00 -0000
Message-id: <200012042053.VAA28364@reisser.regent.e-technik.tu-muenchen.de>
References: <m366l0avxe.fsf@dan2.cygnus.com>
X-SW-Source: 2000-12/msg00082.html
Content-length: 3886

: Why do we not do a lookup_minimal_symbol in
: a new function, add_psymbol_and_dem_name_to_list, on the mangled name,
: and if we get  back a symbol, use the demangled name from that,
: otherwise, demangle it.

For some symbol formats (e.g. a.out) the linkage and debugging symbols are
intermixed. By the time you want to record a partial symbol, the minimal
symbol might have not been seen yet. Or the minimal symbol has been seen,
but the minimal symbols are not yet installed, so lookup_minimal_symbol
will fail.

You might be able to work around this by going over all psymbols and fill
in the demangled name via lookup_minimal_symbol _after_ the minimal symbols
are installed, but I am not yet convinced that you don't have to pay your
price on slower systems. After all, 5 secs to 6 secs is a 20% slowdown.

> Demangled names were removed from partial symbols to speed start up
> times a few years ago.
> 
> However, with the minsym demangled hash table now around, we demangle
> all minimal symbols when we install minimal symbols (IE we init the
> demangled name on them,unconditionally).
> 
> Since the minimal symbol table ends up including a large subset of the
> mangled partial symbols (if not all of them), this means we already have a large
> subset of the partial symbol names demangled for us at start up
> anyway.
> 
> Why do we not do a lookup_minimal_symbol in
> a new function, add_psymbol_and_dem_name_to_list, on the mangled name,
> and if we get  back a symbol, use the demangled name from that,
> otherwise, demangle it.
> 
> Even tests on 100 meg of debug info show we barely add any startup
> time at all (5 seconds without, 6 seconds with) . 
> In fact, all added startup time is attributable to the
> fact that to save memory, I had it bcache the demangled name in
> SYMBOL_INIT_DEMANGLED_NAME.  If you don't bcache it (like right now),
> it's in memory  in at least the full symbol, and the minimal
> symbol (it's  actually in memory once for every time
> SYMBOL_INIT_DEMANGLED_NAME is called on a symbol, and the demangling succeeds).
> 
> I think 1 second on 100 meg of debug info is worth it to not have to
> linear search on every symbol lookup, which is amazingly 
> slow, and if you have gdb using swap at all because of the number of
> symbols, you are almost guaranteed to hit the swap 
> hard on *every* single lookup, since we have to go through every
> single symbol. 
> 
> This would solve the problem of not being able to lookup partial
> symbols by demangled name, and allow us to binary search them without
> fear of missing a symbol.
> 
> Would this be acceptable?
> 
> My next trick after that would be to add a mangled->demangled mapping
> structure, if it's necessary to improve speed, and just use that to
> lookup the names before demangling the 
> name over again, in cases where we do (ie SYMBOL_INIT_DEMANGLED) need
> to find a demangled name for a mangled one, and use that
> rather than the minimal symbol table to try to find the name.
> The reason for this is that a hash table (in this case, we are
> using the minimal symbol demangled hash table as a lookup table) is the wrong structure
> for this, since demangled names can be *very* large (average of 82
> chars on my large C++ programs), and we always have to hash the entire
> string, then do a whole bunch of string compares, because the chains are
> long. This is okay when we hit (except for the long chains), but on
> misses we waste the same amount of times as hits, if not more. The
> string compares on hits also cost a lot because of the length of the string.
> We really should use a ternary search tree or some structure like it,
> which on hits is actually faster (since we don't need multiple
> string compares), and on misses is a whole ton faster, since we abort
> much sooner.
> 
> --Dan
> 
> 
> 


-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From bje@redhat.com Mon Dec 04 13:11:00 2000
From: Ben Elliston <bje@redhat.com>
To: Doug Evans <dje@transmeta.com>
Cc: <gdb-patches@sources.redhat.com>, <cgen@sources.redhat.com>
Subject: Re: [Sim] New sim/common/cgen.sh
Date: Mon, 04 Dec 2000 13:11:00 -0000
Message-id: <Pine.LNX.4.30.0012050810410.5910-100000@moshpit.cygnus.com>
References: <14891.59510.53616.923378@casey.transmeta.com>
X-SW-Source: 2000-12/msg00083.html
Content-length: 285

    > I have also just fixed genmloop.sh so that it has an -outfile-suffix option.
    > This allows the generated files to form unique filenames -- so it, too, can
    > be run by a parallel make.

   Can't this problem be solved without adding an option?

Can you suggest how?

Ben