From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: "Peter.Schauer" Cc: Fernando Nasser , rearnsha@arm.com, Nicolas.Thery@Symbian.com, gdb@sourceware.cygnus.com Subject: Re: ARM/linux gdb stops and gives no info Date: Tue, 30 May 2000 15:44:00 -0000 Message-id: <393443A5.8DBFC7FB@cygnus.com> References: <200005302045.WAA16113@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-05/msg00170.html "Peter.Schauer" wrote: > I'd prefer to keep the selected_frame != NULL check in registers_info > and rather make sure that selected_frame is not NULL in Richard's case, > although I do not know if this can be done for the ARM. > > On the other hand we could remove the check in registers_info and wait for > bug reports with GDB crashing in registers_info due to selected_frame == NULL > and fix their cause. > > Has to be decided by the maintainer of infcmd.c (Fernando ? :-). Rather than crash, a call to internal_error() would probably be more friendly :-) Andrew PS: Yes, I agree, ``(gdb) info registers'' shouldn't need a frame. It's ISA not ABI. Andrew >From fnasser@cygnus.com Tue May 30 15:55:00 2000 From: Fernando Nasser To: "Peter.Schauer" Cc: rearnsha@arm.com, Nicolas.Thery@Symbian.com, gdb@sourceware.cygnus.com Subject: Re: ARM/linux gdb stops and gives no info Date: Tue, 30 May 2000 15:55:00 -0000 Message-id: <3934460C.EEF371DF@cygnus.com> References: <200005302045.WAA16113@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-05/msg00171.html Content-length: 1619 "Peter.Schauer" wrote: > > It was a safety measure to avoid GDB core dumps if selected_frame == NULL. > If you really want to reproduce the original problem, get gdb-4.15.1, build > it on sparc Solaris and (mostly from the original bug report): > It did look like protection against a core dump. My hope was that the reason for that was cleared already. Unfortunately that does not seem to be the case. > > With CVS GDB, do_registers_info calls read_relative_register_raw_bytes > which in turn calls read_relative_register_raw_bytes_for_frame with > selected_frame. > > So even nowadays generic do_registers_info might need a valid selected_frame, > and your proposed patch would not help. > > I'd prefer to keep the selected_frame != NULL check in registers_info > and rather make sure that selected_frame is not NULL in Richard's case, > although I do not know if this can be done for the ARM. > This would be the right solution. > On the other hand we could remove the check in registers_info and wait for > bug reports with GDB crashing in registers_info due to selected_frame == NULL > and fix their cause. > I rather not having core dumps... We can leave the test and wait for people to complain about it. Or even make it an internal_error (where you have the option to dump core and it is more annoying). > Has to be decided by the maintainer of infcmd.c (Fernando ? :-). > Not me. -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From ac131313@cygnus.com Wed May 31 02:57:00 2000 From: Andrew Cagney To: Leon Pollak Cc: insight@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Virtual memory and gdb/Insight Date: Wed, 31 May 2000 02:57:00 -0000 Message-id: <3934E1AD.39F04777@cygnus.com> References: <4.3.0.20000531102122.00aa5c70@plris.com> X-SW-Source: 2000-05/msg00172.html Content-length: 2134 [FYI, reply-to set to gdb@sourceware.cygnus.com. This is a generic GDB problem and not specific to the insight interface] Leon Pollak wrote: > > Hello, all. > Please, excuse me, if the theme I arise is solved already, but I didn't > see any reminiscences about this. > > I am using Insight for remote debugging of my PowerPC (MPC860) target via > BDM interface. I don't think that this is important, but still - the scheme > is as following: > [Linux PC with Insight] <------->Ethernet<----------->[Windows PC with > rproxy]<--------->Wiggler BDM<---------->[Target Board]. > To clarify: rproxy is the program working as remote target for gdb and as > BDM controller for target (see http://www.std.com/qqi/ ). > > Now, everything worked fine up to the moment when I switched on the MMU, > which was supposed to translate some addresses in my application (I wanted > to unite to banks of RAM with the space between them). > At that moment, the following occurs - when I stop the program via BDM, the > MMU is disabled (that is what Motorola states and this happens), so that > looking in to variables, memory and etc. shows nothing but 0xFFFF..., > because the virtual address isn't translated into real one. > > My question to Motorola staff was answered as following: your problem can > be solved only by the intelligent software debugger. > Consult this with vendor of your debug system. Fixing this problem involves adding functionality to GDB (or the remote server) so that it can emulate virtual->physical memory translations. GDB doesn't currently support this feature :-( This is part of a fairly generic problem. Another common example is with kernel debugging using that same interface. GDB can tell you what the raw CPU is doing. It can't display thread information or allow you to manipulate the more abstract kernel threads. I'd like to see this problem solved and getting a solution implemented is in the back of my mind. Unfortunatly, it does involve many significant changes. You can view multi-arch as one small step - there are many others. Have a read of the GDB TODO file. Andrew >From ac131313@cygnus.com Wed May 31 04:32:00 2000 From: Andrew Cagney To: Fred Finster Cc: gdb@sourceware.cygnus.com, Bob_Delp@el.nec.com Subject: Re: CYGMON source code CVS source tree availability for NEC Vr4300 or NEC Vr4121 CPUs? Date: Wed, 31 May 2000 04:32:00 -0000 Message-id: <3934F814.F1AE1FC3@cygnus.com> References: <001a01bfca84$cf14bd80$1c017ec0@ffinster-nt.el.nec.com> X-SW-Source: 2000-05/msg00173.html Content-length: 1090 Fred Finster wrote: > > Hello fellow open source supporters. Thank you for taking time to read this > and possible provide me a couple hints regarding the "fill in the blank" > questions below. > > I am new to this group. Yes, I should read the web page, __XXXX__, on how > to get > the, ??ECOS?? source, that has inside the files to build cygmon EPROM. > Just customize > the files, ___XXXX.h & ___XXXX.h & crt0.S and say "make cygmon". > > I did search for "cygmon" on the http://sourceware.cygnus.com/ecos > webpage > and came up with 83 hits. Lots of good technical explanations, but I > missed > the obvious pointer to the source code availability. Your short helpful > hints will be most appreciated. Thank you To download eCos see http://sourceware.cygnus.com/ecos/getstart.html . The mailing lists are listed on: http://sourceware.cygnus.com/ecos/intouch.html . It includes a gdb stub (I don't remember if it includes the full cygmon though). Several stubs are listed at: http://sourceware.cygnus.com/gdb/#see-also Cygmon isn't currently on sourceware. Andrew >From kettenis@wins.uva.nl Wed May 31 05:23:00 2000 From: Mark Kettenis To: obrien@FreeBSD.org Cc: mellon@pobox.com, gdb@sourceware.cygnus.com Subject: Re: GDB on FreeBSD/Alpha Date: Wed, 31 May 2000 05:23:00 -0000 Message-id: <200005311223.e4VCN0T00505@delius.kettenis.local> References: <200005292310.e4TNAoY05799@delius.kettenis.local> <20000529192510.A72082@sasami.jurai.net> <20000530115440.A47686@dragon.nuxi.com> X-SW-Source: 2000-05/msg00174.html Content-length: 1159 Date: Tue, 30 May 2000 11:54:41 -0700 From: "David O'Brien" On Mon, May 29, 2000 at 07:25:10PM -0400, Anatoly Vorobey wrote: > I understand that David is going to give us gcc 2.96 on FreeBSD soon. > Is the bug fixed there? 4.x will probably stay at 2.95.x (especially with no date on 3.0). Thus we must work around any bugs in 2.95.x. There's not much I can do on the GDB side. For FreeBSD 4.x there are basically two options: 1. Fix gcc 2.95.x such that function argument stabs are emitted after a function, instead of before (this would give them the right value). 2. Make DWARF 2 the default debugging format for gcc 2.95.x on FreeBSD (i.e. configure --with-dwarf2), and modify GDB to ignore the .mdebug section if DWARF 2 info is present. This is a one-line hack, but I don't think we can make this change to the official GDB version. It would have to be a FreeBSD only thing. Personally I'd prefer the first since it's obviously the right thing. Considering the limitations in gcc 2.95.x for the Alpha, it would be best if FreeBSD 5.x would use gcc 3.0 as its system compiler. Mark >From fnasser@cygnus.com Wed May 31 08:01:00 2000 From: Fernando Nasser To: gdb@sourceware.cygnus.com Subject: New mailing list? Date: Wed, 31 May 2000 08:01:00 -0000 Message-id: <39352941.7304281E@cygnus.com> X-SW-Source: 2000-05/msg00175.html Content-length: 1558 (I forgot to cc this to the gdb list. My appologies for the duplication to the ones that subscribe to both.) I would like to propose the creation of the insight-gui@sourceware.cygnus.com mailing list and the aliasing of "insight@sourceware.cygnus.com" to "gdb@sourceware.cygnus.com". It seems quite obvious right now that people who use gdb from the GUI call it Insight and send debugger (GUI or non-GUI) messages to the insight list. Of course we may get the reverse: people who have GUI related questions having their messages in the gdb list. But this is less inconvenient because: 1) There are less of such cases than the reverse situation. 2) Sometimes the problem is indeed related to the gdb core and not the GUI. 3) Everyone on the insight list is also in the gdb one (the reverse not being necessarily true. Based on 3 we have also the option of having a single list (although I don't personally like this option, as it will make my life more difficult and will scare off some people I would never want to see signing off the list because of the volume). We can also rename the "insight" list to "insight-gui" list without creating the redirection of "insight" to "gdb" (i.e., no more "insight" list). This may be the best option as it makes clear the distinction. Suggestions are welcome. Regards to all. -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From obrien@FreeBSD.org Wed May 31 09:00:00 2000 From: "David O'Brien" To: Mark Kettenis Cc: mellon@pobox.com, gdb@sourceware.cygnus.com Subject: Re: GDB on FreeBSD/Alpha Date: Wed, 31 May 2000 09:00:00 -0000 Message-id: <20000531090002.F47686@dragon.nuxi.com> References: <200005292310.e4TNAoY05799@delius.kettenis.local> <20000529192510.A72082@sasami.jurai.net> <20000530115440.A47686@dragon.nuxi.com> <200005311223.e4VCN0T00505@delius.kettenis.local> X-SW-Source: 2000-05/msg00176.html Content-length: 333 On Wed, May 31, 2000 at 02:23:00PM +0200, Mark Kettenis wrote: > Considering the limitations in gcc 2.95.x for the Alpha, it would be > best if FreeBSD 5.x would use gcc 3.0 as its system compiler. That will happen. But 5.0 is a year off. We just got out 4.0, and 4.1 should be out July 15th. -- -- David (obrien@FreeBSD.org) >From kettenis@wins.uva.nl Wed May 31 09:59:00 2000 From: Mark Kettenis To: obrien@FreeBSD.org Cc: gdb@sourceware.cygnus.com Subject: Re: GDB on FreeBSD/Alpha Date: Wed, 31 May 2000 09:59:00 -0000 Message-id: <200005311659.e4VGxb716553@delius.kettenis.local> References: <200005292310.e4TNAoY05799@delius.kettenis.local> <20000529192510.A72082@sasami.jurai.net> <20000530115440.A47686@dragon.nuxi.com> <200005311223.e4VCN0T00505@delius.kettenis.local> <20000531090002.F47686@dragon.nuxi.com> X-SW-Source: 2000-05/msg00177.html Content-length: 1879 Date: Wed, 31 May 2000 09:00:02 -0700 From: "David O'Brien" On Wed, May 31, 2000 at 02:23:00PM +0200, Mark Kettenis wrote: > Considering the limitations in gcc 2.95.x for the Alpha, it would be > best if FreeBSD 5.x would use gcc 3.0 as its system compiler. That will happen. But 5.0 is a year off. We just got out 4.0, and 4.1 should be out July 15th. OK. Fixing gcc 2.95.x before the 4.1 release should be doable. It's a configuration issue. Here's the configuration fragment for FreeBSD/Alpha: alpha*-*-freebsd*) tm_file="${tm_file} freebsd.h alpha/freebsd.h" xm_file="${xm_file} xm-freebsd.h" target_cpu_default="MASK_GAS" tmake_file="t-freebsd alpha/t-crtbe" xmake_file=none fixincludes=fixinc.wrap gas=yes gnu_ld=yes ;; The problem is that gcc/config/freebsd.h includes gcc/config/dbxelf.h, which defines a lot of things that are not right for stabs-in-ecoff: DBX_FUNCTION_FIRST: This is what causes the function argument stabs to be emitted at the beginning of the function, which means the right values for these stabs have not yet been calculated, which in turn makes it impossible for GDB to find the arguments. DBX_USE_BINCL: This causes N_BINCL entries to be used, which GDB cannot handle in .mdebug sections. DBX_OUTPUT_MAIN_SOURCE_FILE_END: This causes an blank trailing N_SO stab to be emitted, which GDB doesn't expect, and causes GDB to crash (I had hacked around this, but I now realise that it's GCC's fault). AFAICT none of the other defines in dbxelf.h are applicable to stabs-in-ecoff. So I think you should remove the dbxelf.h include from gcc/config/freebsd.h (and re-add it for the FreeBSD ELF targets that don't use stabs-in-ecoff). Mark >From obrien@FreeBSD.org Wed May 31 10:20:00 2000 From: "David O'Brien" To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Re: GDB on FreeBSD/Alpha Date: Wed, 31 May 2000 10:20:00 -0000 Message-id: <20000531101946.C54961@dragon.nuxi.com> References: <200005292310.e4TNAoY05799@delius.kettenis.local> X-SW-Source: 2000-05/msg00178.html Content-length: 339 On Tue, May 30, 2000 at 01:09:45AM +0200, Mark Kettenis wrote: > I've managed to add the necessary support for FreeBSD/Alpha to the > version of GDB in CVS (not checked in yet). Hi Mark, What version of GDB will have these bits? 5.0.1 or 5.1? What are the current release engineering plans for GDB? -- -- David (obrien@FreeBSD.org) >From kettenis@wins.uva.nl Wed May 31 12:04:00 2000 From: Mark Kettenis To: obrien@FreeBSD.org Cc: gdb@sourceware.cygnus.com Subject: Re: GDB on FreeBSD/Alpha Date: Wed, 31 May 2000 12:04:00 -0000 Message-id: <200005311903.e4VJ3ox16704@delius.kettenis.local> References: <200005292310.e4TNAoY05799@delius.kettenis.local> <20000531101946.C54961@dragon.nuxi.com> X-SW-Source: 2000-05/msg00179.html Content-length: 1131 Date: Wed, 31 May 2000 10:19:46 -0700 From: "David O'Brien" On Tue, May 30, 2000 at 01:09:45AM +0200, Mark Kettenis wrote: > I've managed to add the necessary support for FreeBSD/Alpha to the > version of GDB in CVS (not checked in yet). Hi Mark, What version of GDB will have these bits? 5.0.1 or 5.1? What are the current release engineering plans for GDB? I'm working from the main branch, which will mean that FreeBSD/Alpha support will be in GDB 5.1 (the same holds for the updated FreeBSD/i386 support). GDB 5.1 is scheduled for five months or so (no promises of course). There may be a 5.0.1 release to fix some important bugs on supported platforms. It wouldn't be hard to backport my work to the 5.0 branch, and I'm willing to do that if you really cannot wait for 5.1. However, I wouldn't be surprised if the GDB 4.18 that's in the FreeBSD CVS tree would simply work if you apply my suggested fixes to the compiler. In that case, I think it would be wise to stick with GDB 4.18 for FreeBSD 4.x and import GDB 5.1 into the FreeBSD 5.x tree when it's released. Mark >From cgf@cygnus.com Wed May 31 15:29:00 2000 From: Chris Faylor To: gdb@sourceware.cygnus.com Subject: libiberty strsignal changes cause windows compilation breakage Date: Wed, 31 May 2000 15:29:00 -0000 Message-id: <20000531182910.A29100@cygnus.com> X-SW-Source: 2000-05/msg00180.html Content-length: 1388 The strsignal file in libiberty was recently updated to include "string.h". This has an unpleasant side effect on cygwin in that the declaration for strsignal in newlib's string.h is essentially this: char *strsignal (int sig); while the definition in strsignal.c is: const char *strsignal (int sig) This is interesting since cygwin's version of strsignal comes from libiberty. To rectify this, I changed the declaration of strsignal in newlib to conform to the definition in strsignal.c. This now breaks gdb, which has its own declaration of strsignal in defs.h. It does not include the 'const', of course. I can easily work around this problem by adding an '#ifndef __CYGWIN__" around the defs.h declaration but I always hate adding system specific ifdefs if they can be avoided. Can anyone offer any other suggestions so that I can get gdb building again? The way that this was solved in 1997 was to remove the const from the declaration in newlib's string.h. I don't think that's the correct solution here. Possibly the correct solution is to remove the const in strsignal.c but that will take some effort to get approved. And, with the current implementation of strsignal, the const is actually correct. I really don't want to rewrite strsignal just to fix cygwin/gdb. This file seems to have been untouched for some time. Any suggestions would be appreciated. cgf >From somervil@cadvision.com Wed May 31 17:20:00 2000 From: robert somerville To: gdb@sourceware.cygnus.com Subject: does GDB support IRIX 64 bit executables? Date: Wed, 31 May 2000 17:20:00 -0000 Message-id: <3935AC4B.12F7F004@cadvision.com> X-SW-Source: 2000-05/msg00181.html Content-length: 153 especially executables produced by the MIPSpro compilers -- ---------------------- somervil@cadvision.com rsomerv@integrageo.com ---------------------- >From ac131313@cygnus.com Wed May 31 17:39:00 2000 From: Andrew Cagney To: robert somerville Cc: gdb@sourceware.cygnus.com Subject: Re: does GDB support IRIX 64 bit executables? Date: Wed, 31 May 2000 17:39:00 -0000 Message-id: <3935B098.EAB6C771@cygnus.com> References: <3935AC4B.12F7F004@cadvision.com> X-SW-Source: 2000-05/msg00182.html Content-length: 302 robert somerville wrote: > > especially executables produced by the MIPSpro compilers Um, can you be a little bit more specific? Which ABI and native or cross? GDB internaly supports a number of MIPS ABIs, some 32 bit, some 64 bit and some which are suffering an identity crisis. enjoy, Andrew >From somervil@cadvision.com Wed May 31 19:46:00 2000 From: robert somerville To: Andrew Cagney Cc: gdb@sourceware.cygnus.com Subject: Re: does GDB support IRIX 64 bit executables? Date: Wed, 31 May 2000 19:46:00 -0000 Message-id: <3935CE99.CA9CC3D4@cadvision.com> References: <3935AC4B.12F7F004@cadvision.com> <3935B098.EAB6C771@cygnus.com> X-SW-Source: 2000-05/msg00183.html Content-length: 821 Andrew Cagney wrote: > > robert somerville wrote: > > > > especially executables produced by the MIPSpro compilers > > Um, can you be a little bit more specific? Which ABI and native or > cross? GDB internaly supports a number of MIPS ABIs, some 32 bit, some > 64 bit and some which are suffering an identity crisis. > > enjoy, > Andrew the native MIPSpro 7.3 series of compilers (f77/cc) in 64 bit mode ( -64 flag ) on R10000/R12000 chips. I don't see a configuration option to build GDB for a 64bit enviroment, the default GDB build for IRIX6.5; 4.18/5.0 pukes, says wrong DWARF version on a 64bit executable. I suppose I could try gcc in 64 bit, but then f77 would be an issue for me. -- ---------------------- somervil@cadvision.com rsomerv@integrageo.com ---------------------- >From ac131313@cygnus.com Wed May 31 21:29:00 2000 From: Andrew Cagney To: GDB Discussion Subject: FYI, Nightly PDF snapshots! Date: Wed, 31 May 2000 21:29:00 -0000 Message-id: <3935E672.4CA916ED@cygnus.com> X-SW-Source: 2000-05/msg00184.html Content-length: 266 FYI, The daily snapshot process is now creating downloadable PFD documentation. See: http://sourceware.cygnus.com/gdb/onlinedocs/ I'll add a few extra links to the main GDB home page. Andrew PS: Thanks for all the pointers / help on getting this one working. >From ac131313@cygnus.com Wed May 31 22:57:00 2000 From: Andrew Cagney To: Chris Faylor Cc: gdb@sourceware.cygnus.com Subject: Re: libiberty strsignal changes cause windows compilation breakage Date: Wed, 31 May 2000 22:57:00 -0000 Message-id: <3935FB36.DB834E7A@cygnus.com> References: <20000531182910.A29100@cygnus.com> X-SW-Source: 2000-05/msg00185.html Content-length: 1444 Chris Faylor wrote: > > The strsignal file in libiberty was recently updated to include > "string.h". This has an unpleasant side effect on cygwin in that the > declaration for strsignal in newlib's string.h is essentially this: POSIX doesn't appear to list strsignal(). Would you know its history? First thing is to figure out what the definition should be according to a standard rather than someones passing whim. As an example of this, check ``basename()'' - POSIX specifies: http://www.opengroup.org/onlinepubs/007908799/xsh/basename.html #include char *basename(char *path); yet include/libiberty.h defines: extern char *basename PARAMS ((const char *)); I've a things-to-do-today to fix it :-) > while the definition in strsignal.c is: > > const char *strsignal (int sig) > This now breaks gdb, which has its own declaration of strsignal in > defs.h. It does not include the 'const', of course. This can be tested using some configury. If define it then don't bother providing a definition (perhaphs in "gdb_string.h". Hmm, find | grep strsignal convex-tdep.c:/* OBSOLETE */strsignal() corelow.c: safe_strsignal() sun386-nat.c:safe_strsignal() umax-xdep.c:safe_strsignal() and utils.c defines save_strsignal(). Shouldn't corelow.c be calling target_signal_to_string()? I'll ignore sun386-nat.c and umax-xdep.c as we could probably slip in a ``OBSOLETE'' while no one was looking :-) Andrew >From eliz@delorie.com Wed May 31 23:04:00 2000 From: Eli Zaretskii To: cgf@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: libiberty strsignal changes cause windows compilation breakage Date: Wed, 31 May 2000 23:04:00 -0000 Message-id: <200006010604.CAA09992@indy.delorie.com> References: <20000531182910.A29100@cygnus.com> X-SW-Source: 2000-05/msg00186.html Content-length: 652 > From: Chris Faylor > Date: Wed, 31 May 2000 18:29:10 -0400 > > The strsignal file in libiberty was recently updated to include > "string.h". This has an unpleasant side effect on cygwin in that the > declaration for strsignal in newlib's string.h is essentially this: > > char *strsignal (int sig); > > while the definition in strsignal.c is: > > const char *strsignal (int sig) If the Cygwin library has strsignal (which, as I understand, is the reason for the prototype in string.h), then why is libiberty's strsignal being linked in? Shouldn't the configure script detect that and refrain from using libiberty's strsignal? >From cgf@cygnus.com Wed May 31 23:12:00 2000 From: Chris Faylor To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: libiberty strsignal changes cause windows compilation breakage Date: Wed, 31 May 2000 23:12:00 -0000 Message-id: <20000601021247.A13381@cygnus.com> References: <20000531182910.A29100@cygnus.com> <200006010604.CAA09992@indy.delorie.com> X-SW-Source: 2000-05/msg00187.html Content-length: 950 On Thu, Jun 01, 2000 at 02:04:31AM -0400, Eli Zaretskii wrote: >> From: Chris Faylor >> Date: Wed, 31 May 2000 18:29:10 -0400 >> >> The strsignal file in libiberty was recently updated to include >> "string.h". This has an unpleasant side effect on cygwin in that the >> declaration for strsignal in newlib's string.h is essentially this: >> >> char *strsignal (int sig); >> >> while the definition in strsignal.c is: >> >> const char *strsignal (int sig) > >If the Cygwin library has strsignal (which, as I understand, is the >reason for the prototype in string.h), then why is libiberty's >strsignal being linked in? Shouldn't the configure script detect that >and refrain from using libiberty's strsignal? I think you missed this part of my email: >This is interesting since cygwin's version of strsignal comes from >libiberty. "comes from" == "linked from" The cygwin DLL exports libiberty's version of strsignal. cgf >From eliz@delorie.com Wed May 31 23:23:00 2000 From: Eli Zaretskii To: cgf@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: libiberty strsignal changes cause windows compilation breakage Date: Wed, 31 May 2000 23:23:00 -0000 Message-id: <200006010623.CAA10020@indy.delorie.com> References: <20000601021247.A13381@cygnus.com> X-SW-Source: 2000-05/msg00188.html Content-length: 685 > Date: Thu, 1 Jun 2000 02:12:48 -0400 > From: Chris Faylor > > I think you missed this part of my email: > > >This is interesting since cygwin's version of strsignal comes from > >libiberty. > > "comes from" == "linked from" Sorry, I thought you were talking about history (i.e., that Cygwin's version of strsignal originally came from libiberty). Now that you clarified this, it would seem that the prototype in string.h contradicted the actual function definition, and changing newlib's string.h was the Right Thing to do. If that breaks GDB, I think GDB should avoid declaring strsignal in defs.h if strsignal being linked in comes from the system library.