* Re: ARM/linux gdb stops and gives no info
[not found] <200005302045.WAA16113@reisser.regent.e-technik.tu-muenchen.de>
@ 2000-05-30 15:44 ` Andrew Cagney
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Cagney @ 2000-05-30 15:44 UTC (permalink / raw)
To: Peter.Schauer; +Cc: Fernando Nasser, rearnsha, Nicolas.Thery, gdb
"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 <fnasser@cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE>
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 <ac131313@cygnus.com>
To: Leon Pollak <leonp@plris.com>
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 <ac131313@cygnus.com>
To: Fred Finster <fred_finster@el.nec.com>
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 <kettenis@wins.uva.nl>
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" <obrien@FreeBSD.org>
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 <fnasser@cygnus.com>
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" <obrien@FreeBSD.org>
To: Mark Kettenis <kettenis@wins.uva.nl>
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 <kettenis@wins.uva.nl>
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" <obrien@FreeBSD.org>
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" <obrien@FreeBSD.org>
To: Mark Kettenis <kettenis@wins.uva.nl>
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 <kettenis@wins.uva.nl>
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" <obrien@FreeBSD.org>
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 <cgf@cygnus.com>
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 <somervil@cadvision.com>
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 <ac131313@cygnus.com>
To: robert somerville <somervil@cadvision.com>
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 <somervil@cadvision.com>
To: Andrew Cagney <ac131313@cygnus.com>
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 serie\x13\x13\x13\x13s 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 <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
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 <ac131313@cygnus.com>
To: Chris Faylor <cgf@cygnus.com>
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 <libgen.h>
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 <string.h> 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 <eliz@delorie.com>
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 <cgf@cygnus.com>
> 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 <cgf@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
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 <cgf@cygnus.com>
>> 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 <eliz@delorie.com>
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 <cgf@cygnus.com>
>
> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread