From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Evans To: Ben Elliston Cc: Andrew Cagney , , Subject: Re: [Sim] Patch to sim/common/cgen-ops.h Date: Mon, 04 Dec 2000 10:53:00 -0000 Message-id: <14891.59391.397233.55439@casey.transmeta.com> References: <14891.9921.841994.631587@casey.transmeta.com> X-SW-Source: 2000-12/msg00077.html 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 , 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 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 To: Ben Elliston Cc: Doug Evans , , 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: 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 Cc: muller@cerbere.u-strasbg.fr, Fernando Nasser , 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 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 Cc: GDB Patches 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 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 To: Ben Elliston Cc: , 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> 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" 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: 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 To: Doug Evans Cc: , Subject: Re: [Sim] New sim/common/cgen.sh Date: Mon, 04 Dec 2000 13:11:00 -0000 Message-id: 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