> From: Ian Lance Taylor
> Date: Mon, 29 Jul 2024 09:46:46 -0700
> Cc: Eli Zaretskii , gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
>
> On Fri, Mar 15, 2024 at 1:41 PM Björn Schäpers wrote:
> >
> > Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:
> > >> Date: T
> Date: Tue, 9 Jan 2024 21:02:44 +0100
> Cc: i...@google.com, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> From: Björn Schäpers
>
> Am 07.01.2024 um 18:03 schrieb Eli Zaretskii:
> > In that case, you an call either GetModuleHandeExA or
> > GetModuleHandeExW, the differ
> Date: Sun, 7 Jan 2024 17:07:06 +0100
> Cc: i...@google.com, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> From: Björn Schäpers
>
> > That was about GetModuleHandle, not about GetModuleHandleEx. For the
> > latter, all Windows versions that support it also support "wide" APIs.
> > So my suggestio
[I re-added the other addressees, as I don' think you meant to make
this discussion private between the two of us.]
> Date: Sun, 7 Jan 2024 12:58:29 +0100
> From: Björn Schäpers
>
> Am 07.01.2024 um 07:50 schrieb Eli Zaretskii:
> >> Date: Sat, 6 Jan 2024 23:15:24 +0100
> Date: Sat, 6 Jan 2024 23:15:24 +0100
> From: Björn Schäpers
> Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
>
> This patch adds libraries which are loaded after backtrace_initialize, like
> plugins or similar.
>
> I don't know what style is preferred for the Win32 typedefs, should the code
>
> Date: Thu, 30 Nov 2023 11:53:54 -0800
> Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> From: Ian Lance Taylor via Gcc
>
> Also starting with a module count of 1000 seems like a lot. Do
> typical Windows programs load that many modules?
Unlikely. I'd start with 100.
> Date: Mon, 20 Nov 2023 20:57:38 +0100
> Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> From: Björn Schäpers
>
> +#ifndef NOMINMAX
> +#define NOMINMAX
> +#endif
Why is this part needed?
Otherwise, LGTM, thanks. (But I'm don't have the approval rights, so
please wait for Ian to chime in.)
> Date: Tue, 29 Aug 2023 17:45:20 +0200
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org,
> binut...@sourceware.org
> From: Jakub Jelinek via Gdb-patches
>
> On Tue, Aug 29, 2023 at 04:21:44PM +0100, Nick Clifton via Gcc-patches wrote:
> > Currently the top level configure.ac file set
> From: Ian Lance Taylor
> Date: Tue, 24 Jan 2023 09:58:10 -0800
> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
>
> I'd rather that the patch look like the appended. Can someone with a
> Windows system test to see what that builds and passes the tests?
ENOPATCH
> From: Ian Lance Taylor
> Date: Tue, 24 Jan 2023 06:35:21 -0800
> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
>
> > > On Windows it seems that MAX_PATH is not
> > > a true limit, as an extended length path may be up to 32767 bytes.
> >
> > The limit of 32767 characters (not by
> Date: Mon, 23 Jan 2023 15:00:56 -0800
> Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> From: Ian Lance Taylor via Gcc
>
> > +#ifdef HAVE_WINDOWS_H
> > +
> > +static char *
> > +windows_get_executable_path (char *buf, backtrace_error_callback
> > error_callback,
> > +
> Date: Sat, 21 Jan 2023 11:47:42 +0100
> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> From: Gabriel Ravier
>
>
> On 1/21/23 05:05, Eli Zaretskii wrote:
> >> Date: Fri, 20 Jan 2023 21:39:56 +0100
> >> Cc: g...@hazardy.de, gcc-patches@gcc
> Date: Sat, 21 Jan 2023 17:18:14 +0800
> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> From: LIU Hao
>
> 在 2023-01-21 12:05, Eli Zaretskii via Gcc 写道:
> > I'm not sure I follow the logic. A program that calls
> > GetModuleHandleW will refuse
> Date: Fri, 20 Jan 2023 21:39:56 +0100
> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> From: Gabriel Ravier
>
> >> - using wide APIs with Windows is generally considered to be a best
> >> practice, even when not strictly needed (and in this case I can't see
> >> any problem wi
> Date: Fri, 20 Jan 2023 17:46:59 +0100
> Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> From: Gabriel Ravier
>
> On 1/20/23 14:39, Eli Zaretskii via Gcc wrote:
> >> From: Björn Schäpers
> >> Date: Fri, 20 Jan 2023 11:54:08 +0100
> >>
> >> @@
> From: Björn Schäpers
> Date: Fri, 20 Jan 2023 11:54:08 +0100
>
> @@ -856,7 +870,12 @@ coff_add (struct backtrace_state *state, int descriptor,
> + (sections[i].offset - min_offset));
> }
>
> - if (!backtrace_dwarf_add (state, /* base_address */ 0, &dwarf_
> From: Jonathan Wakely
> Date: Mon, 12 Jul 2021 15:54:49 +0100
> Cc: Martin Liška ,
> "g...@gcc.gnu.org" , gcc-patches
> ,
> "Joseph S. Myers"
>
> You like texinfo. We get it.
Would you please drop the attitude?
> Cc: h...@bitrange.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org,
> jos...@codesourcery.com
> From: Martin Liška
> Date: Mon, 12 Jul 2021 16:37:00 +0200
>
> > 4) The need to learn yet another markup language.
> > While this is not a problem for simple text, it does require a
> > se
> Cc: g...@gcc.gnu.org, gcc-patches@gcc.gnu.org, jos...@codesourcery.com
> From: Martin Liška
> Date: Mon, 12 Jul 2021 16:34:11 +0200
>
> > "Texinfo must go" is one possible conclusion from your description.
> > But it isn't the only one. An alternative is "the Texinfo source of
> > the GCC manu
> From: Jonathan Wakely
> Date: Mon, 12 Jul 2021 15:05:11 +0100
> Cc: Martin Liška ,
> "g...@gcc.gnu.org" , gcc-patches
> ,
> "Joseph S. Myers"
>
> To be clear, I give links to users frequently (several times a week,
> every week, for decades) and prefer to give them a link to spe
> From: Jonathan Wakely
> Date: Mon, 12 Jul 2021 14:53:44 +0100
> Cc: Martin Liška ,
> "g...@gcc.gnu.org" , gcc-patches
> ,
> "Joseph S. Myers"
>
> For me, these items are enough justification to switch away from
> texinfo, which produces crap HTML pages with crap anchors.
If we
> Cc: g...@gcc.gnu.org, gcc-patches@gcc.gnu.org, jos...@codesourcery.com
> From: Martin Liška
> Date: Mon, 12 Jul 2021 15:25:47 +0200
>
> Let's make it a separate sub-thread where we can discuss motivation why
> do I want moving to Sphinx format.
Thanks for starting this discussion.
> Benefits:
> From: Richard Sandiford
> Cc: Eli Zaretskii , g...@gcc.gnu.org,
> gcc-patches@gcc.gnu.org, jos...@codesourcery.com
> Date: Mon, 05 Jul 2021 10:17:38 +0100
>
> Hans-Peter Nilsson writes:
> > I've read the discussion downthread, but I seem to miss (a recap
>
> Cc: Eli Zaretskii , g...@gcc.gnu.org, gcc-patches@gcc.gnu.org,
> jos...@codesourcery.com
> From: Martin Liška
> Date: Fri, 2 Jul 2021 11:40:06 +0200
>
> > It must
> > look sensible without that. In this case it seems that already the
> > generated .texinf
> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> From: Martin Liška
> Date: Fri, 2 Jul 2021 11:30:02 +0200
>
> > So the purpose of having the comma there is to avoid having a period
> > in the middle of a sentence, which is added by makeinfo (because the
> > Info readers
> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> From: Martin Liška
> Date: Thu, 1 Jul 2021 18:04:24 +0200
>
> > Emacs doesn't hide the period. But there shouldn't be a period to
> > begin with, since it's the middle of a sentence. The correct way of
> > writing this i
> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> From: Martin Liška
> Date: Thu, 1 Jul 2021 16:14:30 +0200
>
> >> If I understand the notes correct, the '.' should be also hidden by e.g.
> >> Emacs.
> >
> > No, it doesn't. The actual text in the Info file is:
> >
> >
> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> From: Martin Liška
> Date: Thu, 1 Jul 2021 14:44:10 +0200
>
> > It helps some, but not all of the issues disappear. For example,
> > stuff like this is still hard to read:
> >
> >To select this standard in GCC, use o
> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> From: Martin Liška
> Date: Wed, 30 Jun 2021 16:04:32 +0200
>
> > Thanks, but does that mean @var will no longer stand out in the
> > produced Info format? That'd be sub-optimal, I think, because a clear
> > reference to a
> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> From: Martin Liška
> Date: Wed, 30 Jun 2021 15:28:40 +0200
>
> >‘@`file'’
> >
> > Read command-line options from ‘`file'’. The options read are
> > inserted in place of the original ‘@`file'’ option.
> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> From: Martin Liška
> Date: Wed, 30 Jun 2021 12:11:03 +0200
>
> > (Admittedly, Emacs by default hides some of the text of a
> > cross-reference, but not hiding them in this case produces an even
> > less legible text.)
>
>
> Date: Tue, 29 Jun 2021 19:57:11 +0300
> From: Eli Zaretskii via Gcc
> Cc: g...@gcc.gnu.org, gcc-patches@gcc.gnu.org, jos...@codesourcery.com
>
> Or how about this:
>
> `Overall Options'
>
>See Options Controlling the Kind of Output.
>
>
> From: Martin Liška
> Date: Tue, 29 Jun 2021 12:09:23 +0200
> Cc: GCC Development , gcc-patches@gcc.gnu.org
>
> On 6/28/21 5:33 PM, Joseph Myers wrote:
> > Are formatted manuals (HTML, PDF, man, info) corresponding to this patch
> > version also available for review?
>
> I've just uploaded them
> Cc: d...@redhat.com, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> From: Pedro Alves
> Date: Thu, 19 Jul 2018 14:41:13 +0100
>
> On 07/19/2018 02:06 PM, Eli Zaretskii wrote:
> >> From: Richard Biener
> >> Date: Thu, 19 Jul 2018 10:46:01 +0200
> From: Richard Biener
> Date: Thu, 19 Jul 2018 10:46:01 +0200
> Cc: DJ Delorie , GCC Patches ,
> gdb-patc...@sourceware.org
>
> > *err = ENOTSUP;
> >^~~
> > ./simple-object-elf.c:1284:14: note: each undeclared identifier is
> > reported only once for ea
le-object-elf.c:1284:14: note: each undeclared identifier is
reported only once for each function it appears in
Suggested fix:
2018-07-18 Eli Zaretskii
* libiberty/simple-object-elf.c (ENOTSUP): If not defined by
errno.h, redirect to ENOSYS.
--- libiberty/simple-object-elf.c~0
> From: Ian Lance Taylor
> Date: Sat, 20 Jan 2018 21:01:09 -0800
> Cc: DJ Delorie , gcc-patches ,
> gdb-patches
>
> On Sat, Jan 20, 2018 at 4:47 AM, Eli Zaretskii wrote:
> >> Date: Thu, 18 Jan 2018 05:25:20 +0200
> >> From: Eli Zaretskii
> &g
> Date: Thu, 18 Jan 2018 05:25:20 +0200
> From: Eli Zaretskii
> CC: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org,
> gdb-patc...@sourceware.org
>
> > From: DJ Delorie
> > Cc: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org,
> > gdb-patc...@sourceware.org
&g
> From: DJ Delorie
> Cc: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Wed, 17 Jan 2018 15:47:49 -0500
>
> Eli Zaretskii writes:
>
> > DJ, would the following semi-kludgey workaround be acceptable?
>
> It would be no worse
> From: Andreas Schwab
> Cc: Eli Zaretskii , gcc-patches@gcc.gnu.org,
> gdb-patc...@sourceware.org
> Date: Tue, 16 Jan 2018 23:00:55 +0100
>
> On Jan 16 2018, DJ Delorie wrote:
>
> > And it's not the host's bit size that counts; there are usually ways to
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Tue, 16 Jan 2018 13:00:48 -0500
>
>
> I think that warning is valid - the host has a 32-bit limit to file
> sizes (off_t) but it's trying to read a 64-bit offset (in that clause).
> It's warning you that you won
Compiling GDB 8.0.91 with mingw.org's MinGW GCC 6.0.3 produces this
warning in libiberty:
gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -I.
-I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes
-pedantic -D_GNU_SOURCE ./simple-object-xcoff.c -o simple-
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Wed, 31 May 2017 00:17:14 -0400
>
>
> Eli Zaretskii writes:
> > Seems to work fine, thanks.
>
> Checked into gcc trunk then :-)
Thanks!
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Fri, 26 May 2017 17:34:12 -0400
>
>
> Please try this patch:
Seems to work fine, thanks.
> Date: Fri, 26 May 2017 09:30:53 -0700
> From: Joel Brobecker
> Cc: DJ Delorie , gcc-patches@gcc.gnu.org,
> gdb-patc...@sourceware.org
>
> Normally, I'd expect someone pushing to GCC's libibert to also
> update our repo accordingly. However, it's easy to forget so,
> if you notice a change
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Wed, 24 May 2017 17:36:16 -0400
>
> Thanks. Committed!
Thanks. Is the environ thing also fixed?
Joel/Pedro, how should I go about making sure these changes are in the
GDB copy of libiberty?
, so I don't have to write one ;-)
Sure:
2017-05-24 Eli Zaretskii
* libiberty/waitpid.c (wait) [__MINGW32__]: Define as a macro
that calls _cwait, so that this function works on MinGW.
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Tue, 23 May 2017 15:37:32 -0400
>
>
> Eli Zaretskii writes:
> > Instead of making waitpid an always-failing stub on MinGW, wouldn't it
> > be better to make it work on MinGW
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Mon, 22 May 2017 15:38:40 -0400
>
> Since (or "if") nobody will (should) use waitpid() on mingw anyway, and
> since libiberty really wants to include waitpid.o, how difficult would
> it be to use some #ifdefs to
dex: libiberty/ChangeLog
> ===
> --- libiberty/ChangeLog (revision 248307)
> +++ libiberty/ChangeLog (working copy)
> @@ -1,3 +1,7 @@
> +2017-05-19 Eli Zaretskii
> +
> + * configure.ac (*-*-mingw*): Don't build waitpid.c.
> +
> 2017-05-02 Iain Buclaw
>
> * d
> From: DJ Delorie
> Cc: pal...@redhat.com, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Sat, 20 May 2017 02:16:14 -0400
>
> Eli Zaretskii writes:
> > My problem is, I don't have a GCC repository, so doing the above means
>
> In this case, a gdb r
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Fri, 19 May 2017 21:25:56 -0400
>
> Fix committed.
Thanks!
Pedro, how do we make this propagated to the GDB repository?
> As Pedro noted, the correct way to request a change is
> to make the change in your loc
> Cc: gdb-patc...@sourceware.org
> From: Pedro Alves
> Date: Fri, 19 May 2017 16:51:30 +0100
>
> So again there's a system header that defines the symbol
> but for some reason libiberty still wants to declare/define
> it is if it weren't?
Yes. AFAICS, libiberty's configure script doesn't check
> Cc: gdb-patc...@sourceware.org
> From: Pedro Alves
> Date: Fri, 19 May 2017 16:36:46 +0100
>
> So I wonder whether we could just unconditionally remove the waitpid
> replacement instead.
That's probably the best path forward.
> Cc: gdb-patc...@sourceware.org, Thomas Schwinge
> From: Pedro Alves
> Date: Fri, 19 May 2017 16:22:55 +0100
>
> But then, xstrndup.c has at the top:
>
> #ifdef HAVE_STRING_H
> #include
> #else
> # ifdef HAVE_STRINGS_H
> # include
> # endif
> #endif
>
> So I would expect your build to pick
When compiling libiberty (as part of GDB) with MinGW on MS-Windows, I
see the following warning:
gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -I.
-I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes
-pedantic -D_GNU_SOURCE ./xstrndup.c -o xstrndup.o
When compiling libiberty (as part of GDB) with MinGW on MS-Windows, I
see the following warning:
gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -I.
-I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes
-pedantic -D_GNU_SOURCE ./waitpid.c -o waitpid.o
When compiling libiberty (as part of GDB) with MinGW on MS-Windows, I
see the following warning:
gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -I.
-I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes
-pedantic -D_GNU_SOURCE ./setenv.c -o setenv.o
> From: Ozkan Sezer
> Date: Thu, 29 Sep 2016 00:09:19 +0300
> Cc: Alexandre Oliva , gcc-patches@gcc.gnu.org
>
> On 9/28/16, Eli Zaretskii wrote:
> >> From: Alexandre Oliva
> >> Cc: gcc-patches@gcc.gnu.org
> >> Date: Wed, 28 Sep 2016 16:03:02 -0300
>
> From: Alexandre Oliva
> Cc: gcc-patches@gcc.gnu.org
> Date: Wed, 28 Sep 2016 16:03:02 -0300
>
> Does that work for everyone involved?
Except that no one will reimburse me for the time I wasted talking to
several people, with eventually null result...
> From: Florian Weimer
> Cc: DJ Delorie , gcc-patches@gcc.gnu.org, seze...@gmail.com
> Date: Wed, 28 Sep 2016 16:43:53 +0200
>
> * Eli Zaretskii:
>
> > If my arithmetics is correct, about 70% of its files is LGPL, the
> > rest GPL. Which doesn't keep man
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, e...@gnu.org, f...@deneb.enyo.de
> Date: Tue, 27 Sep 2016 15:45:28 -0400
>
>
> I wonder if us relicensing our modified copy would apply to your old
> copy. I mean, are we sure RMS knows you're also relicensing an old
> copy, and that the current
> From: DJ Delorie
> Cc: f...@deneb.enyo.de, gcc-patches@gcc.gnu.org, seze...@gmail.com
> Date: Tue, 27 Sep 2016 15:23:46 -0400
>
> > Why would it need to
> > change? It's perfectly okay to link GPL code with LGPL code, we do
> > this all the time with libgcc, no? Or am I missing something?
>
> From: DJ Delorie
> Cc: f...@deneb.enyo.de, gcc-patches@gcc.gnu.org, seze...@gmail.com
> Date: Tue, 27 Sep 2016 15:23:46 -0400
>
> Eli Zaretskii writes:
> >> But then the implementation would need relicensing as well, wouldn't
> >> it?
> >
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, seze...@gmail.com
> Date: Tue, 27 Sep 2016 15:00:46 -0400
>
>
> Eli Zaretskii writes:
> > Because Ozkan wants to use it in an otherwise LGPL package.
>
> Ok, but that doesn't say why it's different. Th
> From: Florian Weimer
> Cc: DJ Delorie , gcc-patches@gcc.gnu.org, seze...@gmail.com
> Date: Tue, 27 Sep 2016 20:54:59 +0200
>
> >> Most of the files in include/ are GPL, not LGPL. Why is this one
> >> different?
> >
> > Because Ozkan wants to use it in an otherwise LGPL package.
>
> But then
> Cc: gcc-patches@gcc.gnu.org, seze...@gmail.com
> From: Jeff Law
> Date: Tue, 27 Sep 2016 12:36:11 -0600
>
> On 09/27/2016 11:52 AM, DJ Delorie wrote:
> >
> > Most of the files in include/ are GPL, not LGPL. Why is this one
> > different?
> Right. ANd it's not like this file inserts anything o
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, seze...@gmail.com
> Date: Tue, 27 Sep 2016 13:52:10 -0400
>
>
> Most of the files in include/ are GPL, not LGPL. Why is this one
> different?
Because Ozkan wants to use it in an otherwise LGPL package.
se CC me on any responses, as I'm not subscribed to this
list.
==
Relicense include/filenames.h as LGPL2+.
include/ChangeLog:
2016-09-24 Eli Zaretskii
* filenames.h: Relicense as LGPL 2.1 or later.
diff --git a/i
"make TAGS" in the GDB source tree fails because libdecnumber doesn't
have a TAGS target. This patch fixes that:
commit 53bef1c10759f1fd7faf675459871b2f4cc12e53
Author: Eli Zaretskii
Date: Thu Jan 22 21:07:31 2015 +0200
Another part of fixing "make TAGS".
> Date: Fri, 16 Jan 2015 16:39:20 -0500
> From: DJ Delorie
> CC: ktiet...@googlemail.com, gcc-patches@gcc.gnu.org,
> gdb-patc...@sourceware.org
>
>
> > Thanks. Do I need to hear from someone else approving this, or can I
> > go ahead and commit?
>
> Go ahead and commit.
Thanks.
Last-
> Date: Fri, 16 Jan 2015 12:34:25 +0100
> From: Kai Tietz
> Cc: GCC Patches ,
> "gdb-patc...@sourceware.org"
>
> Hi Eli,
>
> patch is reasonable and ok for me.
Thanks. Do I need to hear from someone else approving this, or can I
go ahead and commit?
Ping!
> Date: Fri, 02 Jan 2015 12:54:47 +0200
> From: Eli Zaretskii
>
> When compiling GDB 7.8.1, I get this warning in libiberty:
>
> gcc -c -DHAVE_CONFIG_H -O0 -g3 -D__USE_MINGW_ACCESS -I. -I./../include
> -W -Wall -Wwrite-strings -Wc++-compat -Wstrict
When compiling GDB 7.8.1, I get this warning in libiberty:
gcc -c -DHAVE_CONFIG_H -O0 -g3 -D__USE_MINGW_ACCESS -I. -I./../include
-W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic
./strerror.c -o strerror.o
./strerror.c:472:12: warning: '_sys_nerr' redeclared witho
> Date: Sat, 19 Apr 2014 16:23:33 -0400 (EDT)
> From: Kai Tietz
> Cc: gcc-patches@gcc.gnu.org, ktiet...@gmail.com,
> "binut...@sourceware.org Development" ,
> gdb-patc...@sourceware.org
>
> > + /* We only quote arguments that contain spaces, \n \t \v or "
> > characters
> >
> Date: Wed, 13 Mar 2013 11:52:48 -0700
> From: Ian Lance Taylor
> Cc: gdb-patc...@sourceware.org, d...@redhat.com, gcc-patches@gcc.gnu.org
>
> On 3/13/13, Eli Zaretskii wrote:
> >
> > #ifdef __MSVCRT__
> >extern _CRTIMP char *** __cdecl
I get this compiling the latest pretest of GDB 7.6 with MinGW:
gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-2 -g3 -D__USE_MINGW_ACCESS -I.
-I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes
-pedantic ./setenv.c -o setenv.o
./setenv.c:66:1: warning: function declaration i
> Date: Fri, 13 Jul 2012 14:26:15 -0700
> From: Doug Evans
> Cc: d...@redhat.com, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
>
> > Sorry if I'm missing something, but why do we need to advertise such a
> > function at all? Given that libiberty already provides filename_cmp,
> > isn't it
> Date: Fri, 13 Jul 2012 12:36:44 -0700
> From: Doug Evans
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
>
> On Fri, Jul 13, 2012 at 12:21 PM, DJ Delorie wrote:
> >
> > I think it's confusing to have filename_cmp and filename_eq that do
> > basically the same thing. Perhaps filename
> Date: Wed, 15 Jun 2011 06:59:11 -0400
> From: Robert Dewar
> CC: vinsc...@redhat.com, d...@redhat.com, pins...@gmail.com,
> brobec...@adacore.com, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
>
> > or some piece of code in the toolchain arbitrarily changed the
> > case of a filename.
> Date: Wed, 15 Jun 2011 10:22:36 +0200
> From: Corinna Vinschen
> Cc: Andrew Pinski , brobec...@adacore.com,
> gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
>
> Talking about case-insensitive comparison, the filename_cmp and
> filename_ncmp functions don't work for multibyte codesets, onl
> Date: Tue, 22 Mar 2011 19:31:58 +0100
> From: Kai Tietz
> Cc: gdb-patc...@sourceware.org, Dave Korn ,
> GCC Patches , Binutils
>
> > IS_ABSOLUTE_PATH already allows that when HAVE_DOS_BASED_FILE_SYSTEM is
> > true.
>
> Hmm, interesting. I look in more detail. As for DOSish file-syste
> From: Pedro Alves
> Date: Wed, 9 Mar 2011 12:58:38 +
> Cc: gdb-patc...@sourceware.org,
> d...@redhat.com,
> ktiet...@googlemail.com,
> binut...@sourceware.org,
> gcc-patches@gcc.gnu.org
>
> > > The one's left are: 1 in a linux-native only file (never cares
> > > for other filesystem sem
> From: Pedro Alves
> Date: Wed, 9 Mar 2011 11:46:36 +
> Cc: gdb-patc...@sourceware.org,
> d...@redhat.com,
> ktiet...@googlemail.com,
> binut...@sourceware.org,
> gcc-patches@gcc.gnu.org
>
> On Wednesday 09 March 2011 05:29:09, Eli Zaretskii wrote:
> &
> From: Pedro Alves
> Date: Tue, 8 Mar 2011 22:37:59 +
> Cc: DJ Delorie ,
> Eli Zaretskii ,
> ktiet...@googlemail.com,
> binut...@sourceware.org,
> gcc-patches@gcc.gnu.org
>
> Actually, is there any case where lbasename wouldn't
> work instead of f
> Date: Tue, 8 Mar 2011 14:41:00 -0500
> From: DJ Delorie
> CC: ktiet...@googlemail.com, binut...@sourceware.org,
> gdb-patc...@sourceware.org, gcc-patches@gcc.gnu.org
>
>
> I see no harm in having both, for completeness, though.
I don't see any need for completeness in this case. But
> Date: Tue, 8 Mar 2011 19:51:14 +0100
> From: Kai Tietz
> Cc: Pedro Alves , gdb-patc...@sourceware.org,
> gcc-patches@gcc.gnu.org, binut...@sourceware.org
>
> > In my experience, the strchr analog is not needed, only the strrchr
> > one (which could be used quite a lot). The few places t
> From: Pedro Alves
> Date: Tue, 8 Mar 2011 13:33:02 +
> Cc: Kai Tietz ,
> gcc-patches@gcc.gnu.org,
> Eli Zaretskii ,
> binut...@sourceware.org
>
> On Tuesday 08 March 2011 12:48:11, Kai Tietz wrote:
>
> > Well, a better example is elfstab_offset_secti
> Date: Tue, 8 Mar 2011 16:29:51 +0100
> From: Kai Tietz
>
> Umm, sorry. I found a wrong copy & paste. So I re-sent the corrected
> patch. Additionally I adjuste the changes in Makefile.in so, that
> alphabetic order remains.
I think we don't need filename_dirchr, only filename_dirrchr.
And you
> Date: Tue, 8 Mar 2011 12:25:37 +0100
> From: Kai Tietz
> Cc: binut...@sourceware.org, gdb-patc...@sourceware.org,
> gcc-patches@gcc.gnu.org
>
> > Btw, why do we need filename_dirchr? The use case for
> > filename_dirrchr is clear, but in what situations will we need the
> > other one?
>
> Date: Tue, 8 Mar 2011 11:56:45 +0100
> From: Kai Tietz
>
> +@deftypefn Extension int filename_dirchr (const char *@var{p})
> +
> +The returned value is similar to what @code{strchr} would return for
> +searching for a directory separator.
> +
> +This function does not normalize file name. Howe
91 matches
Mail list logo
