Re: [RFA] src-release.sh: Fix gdb source tarball build failure due to libsframe

[Joel Brobecker via Gcc-patches]

> >>>>> "Joel" == Joel Brobecker via Gdb-patches  
> >>>>> writes:
> 
> Joel> ChangeLog:
> 
> Joel> * src-release.sh (GDB_SUPPORT_DIRS): Add libsframe.
> 
> Joel> Ok to apply to master?
> 
> Looks good to me.
> I think we recently agreed that gdb and binutils maintainers can approve
> patches like this... ?

Thanks Tom. Pushed to master.

FTR, I thought this script was also part of the GCC repository,
but discovered that this is not the case when I tried to apply
the same patch there.

-- 
Joel

[RFA] src-release.sh: Fix gdb source tarball build failure due to libsframe

[Joel Brobecker via Gcc-patches]

Hello,

This script was recently changed as follow:

| commit e619dddb3a45780ae66d762756882a3b896b617d
| Date:   Tue Nov 15 15:07:13 2022 -0800
| Subject: src-release.sh: Add libsframe
|
| Add libsframe to the list of top level directories that will be included
| in a release.

Since then, the gdb source tarball has been failing with the error
below during the "make configure-host configure-target" phase:

| make[3]: *** No rule to make target '../libsframe/libsframe.la',
| needed by 'libbfd.la'.  Stop.
| make[3]: Leaving directory '/tmp/gdb-public/bfd'

This patch fixes the issue by adding libsframe to the list of
GDB_SUPPORT_DIRS, similar to what was done for BINUTILS.

ChangeLog:

* src-release.sh (GDB_SUPPORT_DIRS): Add libsframe.

Ok to apply to master?

NB: Once approved, I will take care of applying the patch to both
binutils-gdb and gcc (hence the Cc: of gcc-patches).

Thank you,
---
 src-release.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src-release.sh b/src-release.sh
index 050a8eb958d..ec28f8691c7 100755
--- a/src-release.sh
+++ b/src-release.sh
@@ -322,7 +322,7 @@ gas_release()
 tar_compress $package $tool "$GAS_SUPPORT_DIRS" "$compressors"
 }
 
-GDB_SUPPORT_DIRS="bfd include libiberty libctf opcodes readline sim intl 
libdecnumber cpu zlib contrib gnulib gdbsupport gdbserver libbacktrace"
+GDB_SUPPORT_DIRS="libsframe bfd include libiberty libctf opcodes readline sim 
intl libdecnumber cpu zlib contrib gnulib gdbsupport gdbserver libbacktrace"
 gdb_release()
 {
 compressors=$1
-- 
2.34.1

Re: [ping] Re: [RFA] gcc.misc-tests/outputs.exp: Use link test to check for -gsplit-dwarf support

[Joel Brobecker via Gcc-patches]

> >> gcc/testsuite/ChangeLog:
> >> 
> >> * gcc.misc-tests/outputs.exp: Make the -gsplit-dwarf test
> >> a compile-and-link test rather than a compile-only test.
> 
> OK, thanks.

Thank you Richard. Pushed to master.

-- 
Joel

[ping] Re: [RFA] gcc.misc-tests/outputs.exp: Use link test to check for -gsplit-dwarf support

[Joel Brobecker via Gcc-patches]

Hello,

Gentle ping on this patch.

Thank you!

On Mon, Apr 25, 2022 at 09:04:51AM -0700, Joel Brobecker wrote:
> Hello,
> 
> We have noticed that, when running the GCC testsuite on AArch64
> RTEMS 6, we have about 150 tests failing due to a link failure.
> When investigating, we found that all the tests were failing
> due to the use of -gsplit-dwarf.
> 
> On this platform, using -gsplit-dwarf currently causes an error
> during the link:
> 
> | /[...]/ld: a.out section `.unexpected_sections' will not fit
> |in region `UNEXPECTED_SECTIONS'
> | /[...]/ld: region `UNEXPECTED_SECTIONS' overflowed by 56 bytes
> 
> The error is a bit cryptic, but the source of the issue is that
> the linker does not currently support the sections generated
> by -gsplit-dwarf (.debug_gnu_pubnames, .debug_gnu_pubtypes).
> This means that the -gsplit-dwarf feature itself really isn't
> supported on this platform, at least for the moment.
> 
> This commit enhances the -gsplit-dwarf support check to be
> a compile-and-link check, rather than just a compile check.
> This allows it to properly detect that this feature isn't
> supported on platforms such as AArch64 RTEMS where the compilation
> works, but not the link.
> 
> Tested on aarch64-rtems, where a little over 150 tests are now
> passing, instead of failing, as well as on x86_64-linux, where
> the results are identical, and where the .log file was also manually
> inspected to make sure that the use of the -gsplit-dwarf option
> was preserved.
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.misc-tests/outputs.exp: Make the -gsplit-dwarf test
> a compile-and-link test rather than a compile-only test.
> 
> OK to push on master?
> 
> Thank you,
> -- 
> Joel
> 
> ---
>  gcc/testsuite/gcc.misc-tests/outputs.exp | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp 
> b/gcc/testsuite/gcc.misc-tests/outputs.exp
> index bc1fbe4eb7f..afae735e92d 100644
> --- a/gcc/testsuite/gcc.misc-tests/outputs.exp
> +++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
> @@ -36,8 +36,8 @@ gcc_parallel_test_enable 0
>  # having to deal with .dSYM directories, as long as -gsplit-dwarf is
>  # not supported on platforms that use .dSYM directories.
>  set gsplit_dwarf "-g -gsplit-dwarf"
> -if ![check_no_compiler_messages gsplitdwarf object {
> -void foo (void) { }
> +if ![check_no_compiler_messages gsplitdwarf executable {
> +int main (void) { return 0; }
>  } "$gsplit_dwarf"] {
>  set gsplit_dwarf ""
>  }
> -- 
> 2.32.0
> 

-- 
Joel

[RFA] gcc.misc-tests/outputs.exp: Use link test to check for -gsplit-dwarf support

[Joel Brobecker via Gcc-patches]

Hello,

We have noticed that, when running the GCC testsuite on AArch64
RTEMS 6, we have about 150 tests failing due to a link failure.
When investigating, we found that all the tests were failing
due to the use of -gsplit-dwarf.

On this platform, using -gsplit-dwarf currently causes an error
during the link:

| /[...]/ld: a.out section `.unexpected_sections' will not fit
|in region `UNEXPECTED_SECTIONS'
| /[...]/ld: region `UNEXPECTED_SECTIONS' overflowed by 56 bytes

The error is a bit cryptic, but the source of the issue is that
the linker does not currently support the sections generated
by -gsplit-dwarf (.debug_gnu_pubnames, .debug_gnu_pubtypes).
This means that the -gsplit-dwarf feature itself really isn't
supported on this platform, at least for the moment.

This commit enhances the -gsplit-dwarf support check to be
a compile-and-link check, rather than just a compile check.
This allows it to properly detect that this feature isn't
supported on platforms such as AArch64 RTEMS where the compilation
works, but not the link.

Tested on aarch64-rtems, where a little over 150 tests are now
passing, instead of failing, as well as on x86_64-linux, where
the results are identical, and where the .log file was also manually
inspected to make sure that the use of the -gsplit-dwarf option
was preserved.

gcc/testsuite/ChangeLog:

* gcc.misc-tests/outputs.exp: Make the -gsplit-dwarf test
a compile-and-link test rather than a compile-only test.

OK to push on master?

Thank you,
-- 
Joel

---
 gcc/testsuite/gcc.misc-tests/outputs.exp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp 
b/gcc/testsuite/gcc.misc-tests/outputs.exp
index bc1fbe4eb7f..afae735e92d 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -36,8 +36,8 @@ gcc_parallel_test_enable 0
 # having to deal with .dSYM directories, as long as -gsplit-dwarf is
 # not supported on platforms that use .dSYM directories.
 set gsplit_dwarf "-g -gsplit-dwarf"
-if ![check_no_compiler_messages gsplitdwarf object {
-void foo (void) { }
+if ![check_no_compiler_messages gsplitdwarf executable {
+int main (void) { return 0; }
 } "$gsplit_dwarf"] {
 set gsplit_dwarf ""
 }
-- 
2.32.0

Re: Patch RFA: Support non-ASCII file names in git-changelog

[Joel Brobecker]

> > I have no idea who that is (if it is a single user at all,
> > if it isn't any user with git write permissions).
> 
> CCing Joel, he should help us how to set a git config
> that will be used by the server hooks.

I am not sure that requiring both the server and the user to agree
on a non-default configuration value would be a practical idea.

>From what I understand of the problem, I think the proper fix
is really to adapt the git-changelog script to avoid the need
for any assumption about the user's configuration. In particular,
how does the script get the list of files? Poking around, it looks like
you guys are using the GitPython module, which I'm not familiar with,
unfortunately.  But as a reference point, the git-hooks simply use
the -z option to get the information in raw format, and thus avoids
the problem of filename quoting entirely. Does GitPython support
something similar? For instance, browing the GitPython documentation,
I found attributes a_raw_path and b_raw_path. Could that be the
solution (instead of using a_path and b_path?

Either way, the solution will be independent of the git-hooks,
as I don't think they are actually involved, here.

-- 
Joel

Re: Ping: [RFA] Require powerpc_vsx_ok in gcc.target/powerpc/pr71763.c

[Joel Brobecker]

Hi Peter and Segher,

> > You should always CC the PPC maintainers on PPC patches.
> > I've CC'd both Segher and David.

Thanks a lot for doing that. And well understood for future patches.

> > >>> This commit adds a powerpc_vsx_ok dg-require-effective-target directive
> > >>> to that test, and thus making it UNSUPPORTED instead.
> 
> > >>> * gcc.target/powerpc/pr71763.c: Require powerpc_vsx_ok.
> > >>> OK for master?
> 
> Yes.  Also okay for backports (8, 9, 10).
> 
> Thanks!
> 
> (Don't forget the changelog?)

Thank you, Segher. Pushed to master, and for 8, 9 and 10.

I did include the ChangeLog indeed. I tend to avoid sending them
in the diff, because they usually don't apply out of the box. I know
there are some ways to resolve the conflicts automatically. I haven't
gotten around to setting that up, but if this is causing any confusion
here, I'll make sure to include the ChangeLog diff in the patch as well.

Thanks again!
-- 
Joel

Re: Ping: [RFA] Require powerpc_vsx_ok in gcc.target/powerpc/pr71763.c

[Joel Brobecker]

Hello,

Would someone mind reviewing this patch, please?

The test explicitly uses -mvsx in the compilation options, so it seems
reasonable to require powerpc_vsx_ok...

Thank you!

> Just a friendly ping on the following patch, hopefully sufficiently
> straightforward and tested to be allowed onto branch master.
> 
> 
> On Fri, Apr 17, 2020 at 04:49:47PM -0700, Joel Brobecker wrote:
> > From: Douglas Rupp 
> > 
> > Hello,
> > 
> > (submitting this on behalf of Doug Rupp, one of my colleagues)
> > 
> > We're getting an error when running this test on PowerPC VxWorks 7,
> > due to an unexpected warning:
> > 
> > | Excess errors:
> > | cc1: warning: '-mvsx' and '-mno-altivec' are incompatible
> > 
> > The warning comes from a combination of factors:
> >   - The test itself uses -mvsx explicitly via the following directive:
> >// { dg-options "-O1 -mvsx" }
> >   - Our toolchain was configured so as to make -mno-altivec
> > the default;
> >   - These two options are mutually exclusive.
> > 
> > This commit adds a powerpc_vsx_ok dg-require-effective-target directive
> > to that test, and thus making it UNSUPPORTED instead.
> > 
> > Tested on PowerPC VxWorks 7. Also tested on PowerPC ELF as well,
> > a platform where we do not make -mno-altivec the default, to verify
> > that the test continues to run as usual in that case.
> > 
> > gcc/testsuite/
> > 
> > * gcc.target/powerpc/pr71763.c: Require powerpc_vsx_ok.
> > 
> > OK for master?
> > 
> > Thanks!
> > -- 
> > Joel
> > 
> > ---
> >  gcc/testsuite/gcc.target/powerpc/pr71763.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/gcc/testsuite/gcc.target/powerpc/pr71763.c 
> > b/gcc/testsuite/gcc.target/powerpc/pr71763.c
> > index b36ddfa26b0..b394393 100644
> > --- a/gcc/testsuite/gcc.target/powerpc/pr71763.c
> > +++ b/gcc/testsuite/gcc.target/powerpc/pr71763.c
> > @@ -1,5 +1,6 @@
> >  // PR target/71763
> >  // { dg-do compile }
> > +// { dg-require-effective-target powerpc_vsx_ok }
> >  // { dg-options "-O1 -mvsx" }
> >  
> >  int a, b;
> > -- 
> > 2.17.1
> 
> -- 
> Joel

-- 
Joel

Ping: [RFA] Require powerpc_vsx_ok in gcc.target/powerpc/pr71763.c

[Joel Brobecker]

Hello,

Just a friendly ping on the following patch, hopefully sufficiently
straightforward and tested to be allowed onto branch master.

Thank you!


On Fri, Apr 17, 2020 at 04:49:47PM -0700, Joel Brobecker wrote:
> From: Douglas Rupp 
> 
> Hello,
> 
> (submitting this on behalf of Doug Rupp, one of my colleagues)
> 
> We're getting an error when running this test on PowerPC VxWorks 7,
> due to an unexpected warning:
> 
> | Excess errors:
> | cc1: warning: '-mvsx' and '-mno-altivec' are incompatible
> 
> The warning comes from a combination of factors:
>   - The test itself uses -mvsx explicitly via the following directive:
>// { dg-options "-O1 -mvsx" }
>   - Our toolchain was configured so as to make -mno-altivec
> the default;
>   - These two options are mutually exclusive.
> 
> This commit adds a powerpc_vsx_ok dg-require-effective-target directive
> to that test, and thus making it UNSUPPORTED instead.
> 
> Tested on PowerPC VxWorks 7. Also tested on PowerPC ELF as well,
> a platform where we do not make -mno-altivec the default, to verify
> that the test continues to run as usual in that case.
> 
> gcc/testsuite/
> 
> * gcc.target/powerpc/pr71763.c: Require powerpc_vsx_ok.
> 
> OK for master?
> 
> Thanks!
> -- 
> Joel
> 
> ---
>  gcc/testsuite/gcc.target/powerpc/pr71763.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr71763.c 
> b/gcc/testsuite/gcc.target/powerpc/pr71763.c
> index b36ddfa26b0..b394393 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr71763.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr71763.c
> @@ -1,5 +1,6 @@
>  // PR target/71763
>  // { dg-do compile }
> +// { dg-require-effective-target powerpc_vsx_ok }
>  // { dg-options "-O1 -mvsx" }
>  
>  int a, b;
> -- 
> 2.17.1

-- 
Joel

[RFA] Require powerpc_vsx_ok in gcc.target/powerpc/pr71763.c

[Joel Brobecker]

From: Douglas Rupp 

Hello,

(submitting this on behalf of Doug Rupp, one of my colleagues)

We're getting an error when running this test on PowerPC VxWorks 7,
due to an unexpected warning:

| Excess errors:
| cc1: warning: '-mvsx' and '-mno-altivec' are incompatible

The warning comes from a combination of factors:
  - The test itself uses -mvsx explicitly via the following directive:
   // { dg-options "-O1 -mvsx" }
  - Our toolchain was configured so as to make -mno-altivec
the default;
  - These two options are mutually exclusive.

This commit adds a powerpc_vsx_ok dg-require-effective-target directive
to that test, and thus making it UNSUPPORTED instead.

Tested on PowerPC VxWorks 7. Also tested on PowerPC ELF as well,
a platform where we do not make -mno-altivec the default, to verify
that the test continues to run as usual in that case.

gcc/testsuite/

* gcc.target/powerpc/pr71763.c: Require powerpc_vsx_ok.

OK for master?

Thanks!
-- 
Joel

---
 gcc/testsuite/gcc.target/powerpc/pr71763.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr71763.c 
b/gcc/testsuite/gcc.target/powerpc/pr71763.c
index b36ddfa26b0..b394393 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr71763.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr71763.c
@@ -1,5 +1,6 @@
 // PR target/71763
 // { dg-do compile }
+// { dg-require-effective-target powerpc_vsx_ok }
 // { dg-options "-O1 -mvsx" }
 
 int a, b;
-- 
2.17.1

Re: [RFA] skip gcc.target/arm/div64-unwinding.c on vxworks_kernel targets

[Joel Brobecker]

> > gcc/testsuite/
> > 
> > * gcc.target/arm/div64-unwinding.c: Skip on vxworks_kernel targets.

> OK.

Thank you, Richard. Pushed to master.

-- 
Joel

[RFA] skip gcc.target/arm/div64-unwinding.c on vxworks_kernel targets

[Joel Brobecker]

Hello,

This test verifies, by using a weak reference to _Unwind_RaiseException,
that performing division by zero does not cause that symbol to get
indirectly pulled into our closure.

The testing methodology unfortunately does not work on VxWorks targets
when building in kernel mode. This is inherent to how kernel mode
on VxWorks works: The link is only partial and the remaining symbols
which have not been resolved already get automatically resolved by
the VxWorks loader at the moment the module is loaded onto the target,
prior to execution. The resolution includes weak symbols too, which
defeats the purpose of this test.

gcc/testsuite/

* gcc.target/arm/div64-unwinding.c: Skip on vxworks_kernel targets.

Tested by running the test on ARM VxWorks 7 SR0640, both in kernel
mode as well as RTP mode (verifying it only gets disabled when in
kernel mode). Also run on ARM ELF to verify that this still runs on
non-VxWorks targets.

OK to push to master?

Thank you!
-- 
Joel

---
 gcc/testsuite/gcc.target/arm/div64-unwinding.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.target/arm/div64-unwinding.c 
b/gcc/testsuite/gcc.target/arm/div64-unwinding.c
index 09442811fb6..c10ac248354 100644
--- a/gcc/testsuite/gcc.target/arm/div64-unwinding.c
+++ b/gcc/testsuite/gcc.target/arm/div64-unwinding.c
@@ -1,6 +1,7 @@
 /* Performing a 64-bit division should not pull in the unwinder.  */
 
 /* { dg-do run { target { { ! *-*-linux* } && { ! *-*-uclinux* } } } } */
+/* { dg-skip-if "load causes weak symbol resolution" { vxworks_kernel } } */
 /* { dg-options "-O0" } */
 
 #include 
-- 
2.17.1

Re: limit on emails for merge commits.

[Joel Brobecker]

Hi Ian,

> As I noted, 100 commits to master is a small number, so I expect this problem
> to fire almost every time someone does a merge of master to a devel or user
> branch (unless they have the habit of doing that almost daily, which I doubt
> for
> most).

The main goal of the limit is really to avoid accidents where someone
pushes something he shouldn't or something he didn't realize would
push so many commits. If the GCC repository is such that merges of
100 commits or more is going to be, if not routine, at least to be
expected, then perhaps increasing the limit would make sense.

What I would do is wait a bit and see. This may become moot soon,
depending on the direction that we want to take for vendor/user branches
with respect to emails. I'm still trying to think this over...

-- 
Joel

Re: limit on emails for merge commits.

[Joel Brobecker]

Hello,

> You should include Joel on such questions as the expert on the hooks.
> 
> I don't know whether there's something to put in the commit message to say 
> "allow this merge of more than 100 commits".  I don't think a squashed 
> merge is the right workaround, supposing you do want the git ancestry 
> information to reflect what got merged.  The simple workaround is to do 
> three successive merges, each of under 100 commits and each pushed 
> separately.  Alternatively, you could check out refs/meta/config, push a 
> change that either increases hooks.max-commit-emails or sets 
> hooks.no-emails to prevent mails for this branch, then push the merge, 
> then push a reversion of the change to refs/meta/config.

Joseph pretty much nailed it in terms of options.

-- 
Joel

Re: [RFA] adjust src-release following the renaming of gdb/common/ to gdb/gdbsupport/

[Joel Brobecker]

> >ChangeLog:
> >
> >* src-release (getver): If $tool/gdbsupport/create-version.sh
> >exists, use that to determine the version number.
> >
> >Tested on x86_64-linux, by running the src-release script with "gdb"
> >as the argument, and verifying that the name of the tarball is now
> >correct.
> 
> Ok. 

Thanks Richard. Pushed to the master branch in binutils-gdb. I looked at
the GCC repository, and couldn't find it there, so synchronization to do
between the two, after all!

-- 
Joel

[RFA] adjust src-release following the renaming of gdb/common/ to gdb/gdbsupport/

[Joel Brobecker]

Hello,

A recent change renamed the common/ directory into gdbsupport/ in gdb.
This causes problems in the getver function in the src-release script
which doesn't find the create-version.sh script anymore. As a result,
it falls back on using the version.in file verbatim, meaning that
the "DATE" placeholder doesn't get replaced with the snapshot date,
and the "-git" suffix doesn't get stripped. More precisely, we get
snapshots called "gdb-8.3.50-DATE-git.tar" instead of (e.g.)
"gdb-8.3-20190712.tar".

For those who have been getting snapshots from sourceware, this is also
why recent snapshots are missing.

This commit fixes the issue by adding support for this situation.
I left the support for $tool/common/create-version.sh, because
the sim still uses that directory structure.

ChangeLog:

* src-release (getver): If $tool/gdbsupport/create-version.sh
exists, use that to determine the version number.

Tested on x86_64-linux, by running the src-release script with "gdb"
as the argument, and verifying that the name of the tarball is now
correct.

OK to push?

Thanks!
-- 
Joel

---
 src-release.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/src-release.sh b/src-release.sh
index 1654656146f..90d556896c9 100755
--- a/src-release.sh
+++ b/src-release.sh
@@ -61,6 +61,10 @@ getver()
$tool/common/create-version.sh $tool 'dummy-host' 'dummy-target' VER.tmp
cat VER.tmp | grep 'version\[\]' | sed 's/.*"\([^"]*\)".*/\1/' | sed 
's/-git$//'
 rm -f VER.tmp
+elif test -f $tool/gdbsupport/create-version.sh; then
+   $tool/gdbsupport/create-version.sh $tool 'dummy-host' 'dummy-target' 
VER.tmp
+   cat VER.tmp | grep 'version\[\]' | sed 's/.*"\([^"]*\)".*/\1/' | sed 
's/-git$//'
+rm -f VER.tmp
 elif test -f $tool/version.in; then
head -1 $tool/version.in
 else
-- 
2.17.1

Re: [RFA] fix copyright year range in libstdc++ test file (was: "Re: [v3 PATCH] Implement std::string_view and P0254r2, Integrating std::string_view and std::string.")

[Joel Brobecker]

> > In working on updating the copyright year notices for the GDB files,
> > I noticed something very minor regarding the patch which added the
> > file below (the same file was copied in gdb's testsuite); it looks
> > like the year range for one of the files is truncated:
> 
> > libstdc++-v3/ChangeLog:
> > 
> > * testsuite/21_strings/basic_string_view/element_access/char/empty.cc:
> >Fix year range in copyright header.
> 
> Ok.

Thank you, Mike. Pushed to trunk (rev 267504).

-- 
Joel

[RFA] fix copyright year range in libstdc++ test file (was: "Re: [v3 PATCH] Implement std::string_view and P0254r2, Integrating std::string_view and std::string.")

[Joel Brobecker]

Hello,

In working on updating the copyright year notices for the GDB files,
I noticed something very minor regarding the patch which added the
file below (the same file was copied in gdb's testsuite); it looks
like the year range for one of the files is truncated:

| diff --git 
a/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
 
b/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
| new file mode 100644
| index 000..c0f8206
| --- /dev/null
| +++ 
b/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
| @@ -0,0 +1,40 @@
| +// { dg-options "-std=gnu++17" }
| +
| +// Copyright (C) 3 Free Software Foundation, Inc.

The file was contributed around July 2016, so it should be at least
2016-2018 now, but, looking at all the other test files around,
all ranges start with 2013, so I suspect the intention was for
this file to be the same. This is what the attached patch proposes.

libstdc++-v3/ChangeLog:

* testsuite/21_strings/basic_string_view/element_access/char/empty.cc:
Fix year range in copyright header.

OK for trunk?

One a fix pushed to GCC, I will take care of the GDB side.

Thank you,
-- 
Joel
>From a29191e526c1aeed7da592af3e9bb51c7db8c297 Mon Sep 17 00:00:00 2001
From: Joel Brobecker 
Date: Tue, 1 Jan 2019 09:40:00 +0400
Subject: [PATCH] Fix year range in libstdc++v3/testsuite/.../empty.cc
 copyright header

libstdc++-v3/ChangeLog:

* testsuite/21_strings/basic_string_view/element_access/char/empty.cc:
Fix year range in copyright header.
---
 .../21_strings/basic_string_view/element_access/char/empty.cc   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc b/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
index fad5eb798ba..bf577882d6f 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
@@ -1,6 +1,6 @@
 // { dg-options "-std=gnu++17" }
 
-// Copyright (C) 3 Free Software Foundation, Inc.
+// Copyright (C) 2013-2019 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
-- 
2.17.1

Re: [RFA] require profiling support for gcc.dg/lto/20100430-1_0.c test

[Joel Brobecker]

> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/lto/20100430-1_0.c: Add dg-require-profiling requirement.
> >
> > OK to push?
> 
> OK.

Thank you Richard. Patch pushed to trunk (r267055).

-- 
Joel

[RFA] require profiling support for gcc.dg/lto/20100430-1_0.c test

[Joel Brobecker]

Hello,

This test currently fails unexpectedly if GCC is configured with
--disable-gcov, because it requires -fprofile-arcs. This patch
fixes the issue by requiring profiling support in order to run
this test.

Tested with two compilers, one built with --disable-gcov, resulting
in the test reporting an UNSUPPORTED result; and one built with gcov
support, resulting in 2 PASS tests.

gcc/testsuite/ChangeLog:

* gcc.dg/lto/20100430-1_0.c: Add dg-require-profiling requirement.

OK to push?

Thank you,
-- 
Joel

---
 gcc/testsuite/gcc.dg/lto/20100430-1_0.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.dg/lto/20100430-1_0.c 
b/gcc/testsuite/gcc.dg/lto/20100430-1_0.c
index 1ccfc9ac1ca..c7dafac31af 100644
--- a/gcc/testsuite/gcc.dg/lto/20100430-1_0.c
+++ b/gcc/testsuite/gcc.dg/lto/20100430-1_0.c
@@ -1,6 +1,7 @@
 /* { dg-lto-do link } */
 /* { dg-lto-options {{-O2 -fprofile-arcs -flto -r -nostdlib}} } */
 /* { dg-extra-ld-options "-flinker-output=nolto-rel" } */
+/* { dg-require-profiling "-fprofile-arcs" } */
 
 
 void
-- 
2.17.1

Re: [PATCH] [configure] Added "nfp" to the build for binutils.

[Joel Brobecker]

> +2018-04-30  Francois H. Theron 
> +
> + * config.sub: Added "nfp" to basic_machine list.
> + * configure.ac: Added "nfp" target.
> + * configure: Regenerate.

I am not a maintainer, but I noticed that config.sub is not being
modified by this commit -- a small discrepancy between the patch
and the propose ChangeLog entry.

>  2018-02-13  Maciej W. Rozycki  
>  
>   * configure.ac  (noconfigdirs): Add `ld'.
> diff --git a/configure b/configure
> index 0601395512..69c99e99cc 100755
> --- a/configure
> +++ b/configure
> @@ -3777,6 +3777,10 @@ case "${target}" in
>mt-*-*)
>  noconfigdirs="$noconfigdirs sim"
>  ;;
> +  nfp-*-*)
> +noconfigdirs="$noconfigdirs ld gas gdb gprof sim"
> +noconfigdirs="$noconfigdirs $target_libraries"
> +;;
>powerpc-*-aix*)
>  # copied from rs6000-*-* entry
>  noconfigdirs="$noconfigdirs gprof"
> diff --git a/configure.ac b/configure.ac
> index c34652..a1edc369a2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1108,6 +1108,10 @@ case "${target}" in
>mt-*-*)
>  noconfigdirs="$noconfigdirs sim"
>  ;;
> +  nfp-*-*)
> +noconfigdirs="$noconfigdirs ld gas gdb gprof sim"
> +noconfigdirs="$noconfigdirs $target_libraries"
> +;;
>powerpc-*-aix*)
>  # copied from rs6000-*-* entry
>  noconfigdirs="$noconfigdirs gprof"


-- 
Joel

Re: MinGW compilation warnings in libiberty's waitpid.c

[Joel Brobecker]

> I ended up not having time before going on holiday.  If the resync
> hasn't already been done, I'll do it now.

Thanks for doing that, Iain!

-- 
Joel

Re: MinGW compilation warnings in libiberty's waitpid.c

[Joel Brobecker]

> This has been on my todo-list for a little while, as re-syncing is
> something I normally do after pushing D language support updates into
> libiberty.  However I decided to give it a wait until I got all
> pending patches in, the last of which I'm just pushing in now.

That's very kind of you to help us with that :). Thank you!

-- 
Joel

Re: MinGW compilation warnings in libiberty's waitpid.c

[Joel Brobecker]

> What can I do to expedite the process?  This currently holds the 8.0
> release, and I'm uneasy to be the culprit.

The way I usually do it is grab the commit in GCC, and apply it
as is in the GDB repository. To make it easier, I use the git
mirror of the GCC repository, because I can then just add the
GCC repository as one of my remotes, fetch from there, and then
cherry-pick. If you prefer to work from GCC's SVN repository,
just use SVN to get the diff, and re-apply it by hand in GDB's
git repository. The advantage with the cherry-pick is that git
does nearly all of the work (revision log, etc).

-- 
Joel

Re: MinGW compilation warnings in libiberty's waitpid.c

[Joel Brobecker]

> 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?

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 that was not propagated to us, we just
cherry-pick those changes so as to make sure our copy is up
to date with GCC's. We also see the occasional "resync libiberty"
commits which act as a failsafe, but I don't think we should wait
for one of those.

Should those ones be pushed to the gdb-8.0-branch as well?

-- 
Joel

Re: [PATCH] For broken exception handling in GDB on AIX platform

[Joel Brobecker]

Hello,

> I got some review comment from Bernhard Reutner-Fischer, and I have
> updated the patch accordingly.
> This patch is for bug opened
> here:https://sourceware.org/bugzilla/show_bug.cgi?id=21187

This patch has been identified as one of the desirable patches
to have for the GDB 8.0 release, for which we are hoping to create
the branch ASAP. Without this patch, it would be difficult for
users on AIX to build a functional debugger.

Would it be possible to help Nitish through the review and approval
process?

Here is a ChangeLog entry:

* configure.ac: Add support for --disable-staticlib.
* configure: Regenerate.

Can someone review the patch, please?

Thank you!


> 
> Please find the attachment below.
> 
> Thanks and Regards,
> Nitish K Mishra.

> diff --git a/configure.ac b/configure.ac
> index 3ec86c1..c400251 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -471,6 +471,13 @@ ENABLE_LIBSTDCXX=default)
>noconfigdirs="$noconfigdirs target-libstdc++-v3"
>  fi]
>  
> +AC_ARG_ENABLE(staticlib,
> +AS_HELP_STRING([--disable-staticlib],
> +  [do not link libstdc++ and libgcc library statically, default is static 
> linking]),
> +ENABLE_STATICLIB=$enableval,
> +ENABLE_STATICLIB=yes)
> +
> +
>  # If this is accelerator compiler and its target is intelmic we enable
>  # target liboffloadmic by default.  If this is compiler with offloading
>  # for intelmic we enable host liboffloadmic by default.  Otherwise
> @@ -1406,9 +1413,10 @@ if test -z "$LD"; then
>fi
>  fi
>  
> -# Check whether -static-libstdc++ -static-libgcc is supported.
> +# If ENABLE_STATICLIB is set for configuration, check whether 
> -static-libstdc++ -static-libgcc is supported
>  have_static_libs=no
> -if test "$GCC" = yes; then
> +if test "$ENABLE_STATICLIB" = yes; then
> + if test "$GCC" = yes; then
>saved_LDFLAGS="$LDFLAGS"
>  
>LDFLAGS="$LDFLAGS -static-libstdc++ -static-libgcc"
> @@ -1424,6 +1432,7 @@ int main() {}],
>AC_LANG_POP(C++)
>  
>LDFLAGS="$saved_LDFLAGS"
> + fi
>  fi
>  
>  ACX_PROG_GNAT
> @@ -1741,6 +1750,9 @@ AC_ARG_WITH(stage1-ldflags,
>   # trust that they are doing what they want.
>   if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then
> stage1_ldflags="-static-libstdc++ -static-libgcc"
> +   else
> +  # If static lib is disabled.
> +   stage1_ldflags=""
>   fi])
>  AC_SUBST(stage1_ldflags)
>  
> @@ -1768,8 +1780,11 @@ AC_ARG_WITH(boot-ldflags,
>   # In stages 2 and 3, default to linking libstdc++ and libgcc
>   # statically.  But if the user explicitly specified the libraries to
>   # use, trust that they are doing what they want.
> - if test "$poststage1_libs" = ""; then
> + if test "$poststage1_libs" = "" -a "$have_static_libs" = yes; then
> poststage1_ldflags="-static-libstdc++ -static-libgcc"
> +   else
> +   # If static library linking is disabled.
> +   poststage1_ldflags=""
>   fi])
>  AC_SUBST(poststage1_ldflags)
>  


-- 
Joel

Re: update zlib to 1.2.8

[Joel Brobecker]

> No, just a packaging issue with somebody mentioning a static binutils build.
> That's when I saw the outdated version.
> 
> Now updated in the GCC VCS.

OK, if you have updated the GCC sources, would you mind updating
the binutils-gdb.git as well? We should really keep the two as much
in sync as we can.

Thanks!
-- 
Joel

Re: update zlib to 1.2.8

[Joel Brobecker]

> In GCC zlib is only used for libjava; for binutils and gdb it is used when
> building without --with-system-zlib.  This just updates zlib from 1.2.7 to
> 1.2.8 (released in 2013).  Applies cleanly, libjava still builds and doesn't
> show any regressions in the testsuite.  Ok to apply (even if we already are
> in stage3)?

> +2015-11-23  Matthias Klose  
> +
> +   * Imported zlib 1.2.8; merged local changes.

Should not be a problem for GDB, since we're not near branching time.

Out of curiosity, what prompted this update? Just to be in sync with
the latest? Or was there an actual bug that you hit which 1.2.8 fixes?

-- 
Joel

[RFA] Do not use libiberty's getpagesize on Android

[Joel Brobecker]

Hello,

Building libiberty on Android currently fails with the error message
shown below.  This was discovered by trying to build GDBserver
for Android, which stopped building after libiberty became
a GDBserver dependency.

Here is the error message:

[...]/getpagesize.c:64:1: error: redefinition of 'getpagesize'
In file included from /[...]/getpagesize.c:34:0:
/[...]/usr/include/unistd.h:171:23: note: previous definition of 'getpagesize' 
was here

And looking at the definition, one can see that it defined as
a static inline function...

   static __inline__ int getpagesize(void) {
 extern unsigned int __page_size;
 return __page_size;
   }

... which explains why the AC_CHECK_FUNCS test failed to detect
the function, since there is no associated symbol to be linked in.

This patch prevents getpagesize.c to be compiled in by hard-coding
the fact that getpagesize is available on android hosts.

libiberty/ChangeLog:

* configure.ac: Set AC_CV_FUNC_GETPAGESIZE to "yes" on
Android hosts.
* configure: Regenerate.

OK to apply?

Thank you!
-- 
Joel

---
 libiberty/configure| 6 ++
 libiberty/configure.ac | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/libiberty/configure b/libiberty/configure
index d8890a1..720dc5e 100755
--- a/libiberty/configure
+++ b/libiberty/configure
@@ -6248,6 +6248,12 @@ if test -z "${setobjs}"; then
 
   case "${host}" in
 
+  *-*-android*)
+# On android, getpagesize is defined in unistd.h as a static inline
+# function, which AC_CHECK_FUNCS does not handle properly.
+ac_cv_func_getpagesize=yes
+;;
+
   *-*-mingw32*)
 # Under mingw32, sys_nerr and sys_errlist exist, but they are
 # macros, so the test below won't find them.
diff --git a/libiberty/configure.ac b/libiberty/configure.ac
index 868be8e..e21e3aa 100644
--- a/libiberty/configure.ac
+++ b/libiberty/configure.ac
@@ -600,6 +600,12 @@ if test -z "${setobjs}"; then
 
   case "${host}" in
 
+  *-*-android*)
+# On android, getpagesize is defined in unistd.h as a static inline
+# function, which AC_CHECK_FUNCS does not handle properly.
+ac_cv_func_getpagesize=yes
+;;
+
   *-*-mingw32*)
 # Under mingw32, sys_nerr and sys_errlist exist, but they are
 # macros, so the test below won't find them.
-- 
2.1.4

Re: [RFA] Do not use libiberty's getpagesize on Android

[Joel Brobecker]

> > libiberty/ChangeLog:
> > 
> > * configure.ac: Set AC_CV_FUNC_GETPAGESIZE to "yes" on
> > Android hosts.
> > * configure: Regenerate.
> > 
> > OK to apply?
> 
> Ok.

Thank you, DJ. committed in gcc's SVN, and pushed to binutils-gdb.

-- 
Joel

[RFA] libiberty/mkstemps.c: Include time.h if sys/time.h not available.

[Joel Brobecker]

Hello,

Attempting to build libiberty on LynxOS-178 fails trying to compile
mkstemps.c with the following error:

mkstemps.c:84:18: error: storage size of 'tv' isn't known
   struct timeval tv;
  ^

This file would normally include sys/time.h to get the type's
definition, but unfortunately LynxOS-178 does not want us to use
sys/time.h, only time.h. The configure script correctly finds
this out and generates a config.h file where HAVE_SYS_TIME_H is
undefined:

/* Define to 1 if you have the sys/time.h header file. */
/* #undef HAVE_SYS_TIME_H */

This patch fixes the build issue by falling back on including time.h
if sys/time.h could not be included (and provided that HAVE_TIME_H
is defined, of course).

libiberty/ChangeLog:

* mkstemps.c: #include time.h if HAVE_TIME_H is defined
but not HAVE_SYS_TIME_H.

OK to commit?

Thank you,
-- 
Joel

---
 libiberty/mkstemps.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libiberty/mkstemps.c b/libiberty/mkstemps.c
index a0e68a7..0e06fe1 100644
--- a/libiberty/mkstemps.c
+++ b/libiberty/mkstemps.c
@@ -35,6 +35,8 @@
 #endif
 #ifdef HAVE_SYS_TIME_H
 #include sys/time.h
+#elif HAVE_TIME_H
+#include time.h
 #endif
 #include ansidecl.h
 
-- 
1.9.1

Re: [RFA] libiberty/mkstemps.c: Include time.h if sys/time.h not available.

[Joel Brobecker]

  * mkstemps.c: #include time.h if HAVE_TIME_H is defined
  but not HAVE_SYS_TIME_H.
 
 Ok.

Thank you, DJ. Pushed to both GCC and binutils-gdb.

-- 
Joel

Re: [PATCH] PR debug/61352 back port from mainline

[Joel Brobecker]

The attached patch is a back port of the change from
  https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=211067 for
  gcc-4_9-branch. Bootstrap and regression tested on
  x86_64-apple-darwin14 with Xcode 6.3. Okay for gcc-4_9-branch?
Jack
  PR61352_backport.diff
 
 Ok.
 
 Committed revision 222835.

FTR - for those who do not follow bugzilla PRs, we have found that
dsymutil is not working well at all: missing DWARF dies, SEGVs, not
working well with -gno-strict-dwarf.

As said in the PR, I don't think this is the right solution,
particularly since we don't have any control on dsymutil's quality
and features. I suggest we revert this patch, and try to understand
why GDB wasn't able to pull the debugging info from the executable
(assuming that's still an issue).

Thanks,
-- 
Joel

Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4

[Joel Brobecker]

 Why do you want to turn off zlib? On Linux/x86,  zlib is required
 for assembler.  At least, you should issue an error when --without-libz
 is used in binutils for Linux/x86 target.

I am trying to do the exact opposite, which is to provide an option
to compile WITH zlib, but using an install at a non-standard location.

 I guess someone has asked it before.  Why can't zlib be made the
 same as
 
   --with-mpc=PATH specify prefix directory for installed MPC package.
   Equivalent to --with-mpc-include=PATH/include plus
   --with-mpc-lib=PATH/lib
   --with-mpc-include=PATH specify directory for installed MPC include files
   --with-mpc-lib=PATH specify directory for the installed MPC library
 
 It is more flexible than your patch.  If you have some existing packages
 which use your scheme, you can translate the configure command line
 options to this one.

This is fustrating. I already answered that question.

-- 
Joel

Re: ping: [RFA] Add --with-libz-prefix option in config/zlib.m4

[Joel Brobecker]

 What is the rational for having --with-zlib but --with-libz-prefix
 (ie zlib vs libz) ?  Looks not very consistent.

I agree it's unfortunate, but it is unavoidable if I want to keep the
current option as it is (compatibility), and reuse AC_LIB_HAVE_LINKFLAGS
(which is a fairly complex function).

-- 
Joel

Re: [RFA] Add --with-libz-prefix option in config/zlib.m4

[Joel Brobecker]

  This patch enhances config/zlib.m4 to introduce an extra option
  --with-libz-prefix which allows us to provide the location of
  the zlib library we want to use during the build.
 
 I prefer the gcc way to provide external library:
 
 --with-zlib - system zlib used
 --with-zlib=pathname - zlib from pathname is used

Unfortunately, we took a different route with GDB (with-...-prefix).
For instance:

  --with-libiconv-prefix
  --with-liblzma-prefix
  --with-libbabeltrace-prefix

We already have a really nice macro that takes care of a lot of
configury for us with respect to lib depenencies, which I see
in gcc's root configure.ac that gmp/mpfr/mpc options is done
via specific code.

What I'm getting at is that, to achieve your prefered option
(which I agree is more elegant), it would take a significant
effort.

-- 
Joel

Re: [PATCH] Add D demangling support to libiberty

[Joel Brobecker]

Hello Ian,

 libiberty/ChangeLog
 2014-08-05  Iain Buclaw  ibuc...@gdcproject.org
 
 * Makefile.in (CFILES): Add d-demangle.c.
 (REQUIRED_OFILES): Add d-demangle.o.
 * cplus-dem.c (libiberty_demanglers): Add dlang_demangling case.
 (cplus_demangle): Likewise.
 * d-demangle.c: New file.
 * testsuite/Makefile.in (really-check): Add check-d-demangle.
 * testsuite/d-demangle-expected: New file.

As hinted on gdb-patches, this patch causes a GDB build failure
on Solaris 2.9, because it uses strtold which is not available.
According to gnulib's documentation, it should also break on
the following systems:

NetBSD 3.0, OpenBSD 3.8, Minix 3.1.8, IRIX 6.5, OSF/1 4.0,
Solaris 9, Cygwin, MSVC 9, Interix 3.5, BeOS.

This patch attempts to fix the issue by adding a configure check
for strtold and adjusts the code to use strtod if strtold does not
exist.

Does this look OK to you? If yes, can one of the GCC maintainers
please review?

libiberty/ChangeLog:

* configure.ac: Add check for strtold's availability.
* configure, config.in: Regenerate.
* d-demangle.c [!HAVE_STRTOLD]: #define strtold to strtod.

Thank you!

-- 
Joel
From 9e4d74607075ef857dfa4e118f43641494aaff90 Mon Sep 17 00:00:00 2001
From: Joel Brobecker brobec...@adacore.com
Date: Tue, 14 Oct 2014 09:54:05 -0400
Subject: [PATCH] libiberty: fallback on strtod if strtold is not available.

This patch fixes a build failurer on Solaris 2.9, and all other
systems that do not provide strtold.

libiberty/ChangeLog:

* configure.ac: Add check for strtold's availability.
* configure, config.in: Regenerate.
* d-demangle.c [!HAVE_STRTOLD]: #define strtold to strtod.
---
 libiberty/config.in| 3 +++
 libiberty/configure| 2 +-
 libiberty/configure.ac | 2 +-
 libiberty/d-demangle.c | 3 +++
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/libiberty/configure.ac b/libiberty/configure.ac
index 3380819..da20a5f 100644
--- a/libiberty/configure.ac
+++ b/libiberty/configure.ac
@@ -401,7 +401,7 @@ if test x = y; then
 sbrk setenv setproctitle setrlimit sigsetmask snprintf spawnve spawnvpe \
  stpcpy stpncpy strcasecmp strchr strdup \
  strerror strncasecmp strndup strnlen strrchr strsignal strstr strtod \
- strtol strtoul strverscmp sysconf sysctl sysmp \
+ strtol strtold strtoul strverscmp sysconf sysctl sysmp \
 table times tmpnam \
 vasprintf vfprintf vprintf vsprintf \
 wait3 wait4 waitpid)
diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index d31bf94..59de083 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -46,6 +46,9 @@ If not, see http://www.gnu.org/licenses/.  */
 extern long strtol (const char *nptr, char **endptr, int base);
 extern long double strtold (const char *nptr, char **endptr);
 #endif
+#if !defined(HAVE_STRTOLD)
+#define strtold strtod
+#endif
 
 #include demangle.h
 #include libiberty.h
diff --git a/libiberty/config.in b/libiberty/config.in
index 1cf9c11..8c5f0b6 100644
--- a/libiberty/config.in
+++ b/libiberty/config.in
@@ -280,6 +280,9 @@
 /* Define to 1 if you have the `strtol' function. */
 #undef HAVE_STRTOL
 
+/* Define to 1 if you have the `strtold' function. */
+#undef HAVE_STRTOLD
+
 /* Define to 1 if you have the `strtoul' function. */
 #undef HAVE_STRTOUL
 
diff --git a/libiberty/configure b/libiberty/configure
index 96feaed..072b03b 100755
--- a/libiberty/configure
+++ b/libiberty/configure
@@ -5423,7 +5423,7 @@ if test x = y; then
 sbrk setenv setproctitle setrlimit sigsetmask snprintf spawnve spawnvpe \
  stpcpy stpncpy strcasecmp strchr strdup \
  strerror strncasecmp strndup strnlen strrchr strsignal strstr strtod \
- strtol strtoul strverscmp sysconf sysctl sysmp \
+ strtol strtold strtoul strverscmp sysconf sysctl sysmp \
 table times tmpnam \
 vasprintf vfprintf vprintf vsprintf \
 wait3 wait4 waitpid
-- 
1.9.1

Re: [PATCH] Add D demangling support to libiberty

[Joel Brobecker]

 I've just seen this, so I'll repeat what I've said in gdb patches too.
 
 The call to strtold is only needed to decode templates which have a
 floating point value encoded inside. This value may or may not have a
 greater than double precision.
 
 Replacing long double with double will be fine with me.  I'll accept
 that I didn't consider legacy in hindsight, and in reality it would be
 rather rare to stumble upon the need for strtold.

Attached is a patch that switches it to strtod. Do you have any
test that could quickly verify it? That seems to be the best
approach, at least short-term. Later on, if we do want to use
higher precision, we can indeed add strtold in libiberty.

libiberty/ChangeLog:

* d-demangle.c: Replace strtold with strtod in global comment.
(strtold): Remove declaration.
(strtod): New declaration.
(dlang_parse_real): Declare value as double instead of long
double.  Replace call to strtold by call to strtod.
Update format in call to snprintf.

I verified that the patch allows GDB to build on both sparc-solaris
and x86_64-linux.

Thanks,
-- 
Joel
From 99f9794c6d2f4dabed0bbcf2cf362b1eb25ee2a7 Mon Sep 17 00:00:00 2001
From: Joel Brobecker brobec...@adacore.com
Date: Tue, 14 Oct 2014 12:47:43 -0400
Subject: [PATCH] Use strtod instead of strtold in libiberty/d-demangle.c

strtold is currently used to decode templates which have a floating-point
value encoded inside; but this routine is not available on some systems,
such as Solaris 2.9 for instance.

This patch fixes the issue by replace the use of strtold by strtod.
It reduces a bit the precision, but it should still remain acceptable
in most cases.

libiberty/ChangeLog:

* d-demangle.c: Replace strtold with strtod in global comment.
(strtold): Remove declaration.
(strtod): New declaration.
(dlang_parse_real): Declare value as double instead of long
double.  Replace call to strtold by call to strtod.
Update format in call to snprintf.
---
 libiberty/d-demangle.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index d31bf94..bb481c0 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -28,7 +28,7 @@ If not, see http://www.gnu.org/licenses/.  */
 
 /* This file exports one function; dlang_demangle.
 
-   This file imports strtol and strtold for decoding mangled literals.  */
+   This file imports strtol and strtod for decoding mangled literals.  */
 
 #ifdef HAVE_CONFIG_H
 #include config.h
@@ -44,7 +44,7 @@ If not, see http://www.gnu.org/licenses/.  */
 #include stdlib.h
 #else
 extern long strtol (const char *nptr, char **endptr, int base);
-extern long double strtold (const char *nptr, char **endptr);
+extern double strtod (const char *nptr, char **endptr);
 #endif
 
 #include demangle.h
@@ -810,7 +810,7 @@ dlang_parse_real (string *decl, const char *mangled)
 {
   char buffer[64];
   int len = 0;
-  long double value;
+  double value;
   char *endptr;
 
   /* Handle NAN and +-INF.  */
@@ -877,12 +877,12 @@ dlang_parse_real (string *decl, const char *mangled)
 
   /* Convert buffer from hexadecimal to floating-point.  */
   buffer[len] = '\0';
-  value = strtold (buffer, endptr);
+  value = strtod (buffer, endptr);
 
   if (endptr == NULL || endptr != (buffer + len))
 return NULL;
 
-  len = snprintf (buffer, sizeof(buffer), %#Lg, value);
+  len = snprintf (buffer, sizeof(buffer), %#g, value);
   string_appendn (decl, buffer, len);
   return mangled;
 }
-- 
1.7.9.5

Re: [PATCH] Add D demangling support to libiberty

[Joel Brobecker]

  libiberty/ChangeLog:
 
  * d-demangle.c: Replace strtold with strtod in global comment.
  (strtold): Remove declaration.
  (strtod): New declaration.
  (dlang_parse_real): Declare value as double instead of long
  double.  Replace call to strtold by call to strtod.
  Update format in call to snprintf.
 
 This is OK.

Thanks, Ian. As suggested by Iain, I re-ran the libiberty
testsuite on x86_64-linux before committing the patch.

Thank you both!
-- 
Joel

Re: [RFA/dwarf v2] Add DW_AT_GNAT_use_descriptive_type flag for Ada units.

[Joel Brobecker]

Ping? I understand there was a freeze period for a while, but the patch
has been out for a little over 3 months, now, and is fairly trivial.
Can someone review it for me?

Suggest also including it in 4.9.

Thank you!

 On Tue, Feb 19, 2013 at 10:50:46PM -0500, Jason Merrill wrote:
  On 02/19/2013 10:42 PM, Joel Brobecker wrote:
  This is useful when a DIE does not have a descriptive type attribute.
  In that case, the debugger needs to determine whether the unit
  was compiled with a compiler that normally provides that information,
  or not.
  
  Ah.  OK, then.  But I'd prefer to call it
  DW_AT_GNAT_use_descriptive_type, to follow the convention of keeping
  the vendor tag at the beginning of the name.
 
 Almost a year ago, you privately approved a small patch of mine,
 with the small request above. I'm sorry I let it drag so long!
 Here is the updated patch.
 
 include/ChangeLog:
 
 * dwarf2.def: Rename DW_AT_use_GNAT_descriptive_type into
 DW_AT_GNAT_use_descriptive_type.
 
 gcc/ChangeLog:
 
 * dwarf2out.c (gen_compile_unit_die): Add
 DW_AT_use_GNAT_descriptive_type attribute for Ada units.
 
 Tested on x86_64-linux.
 
 I should also adjust the Wiki page accordingly, but the login process
 keeps timing out. I know I have the right login and passwd since
 I succesfully reset them using the passwd recovery procedure, just
 in case the error was due to bad credentials. I'll try again later.
 
 If approved, I will also take care of coordinating the dwarf2.def
 change with binutils-gdb.git.
 
 Is this patch still OK to commit?
 
 Thank you,
 -- 
 Joel

 From 7aae3721addf6905113d9f0287a5cbb5301a462b Mon Sep 17 00:00:00 2001
 From: Joel Brobecker brobec...@adacore.com
 Date: Thu, 3 Jan 2013 09:25:12 -0500
 Subject: [PATCH] [dwarf] Add DW_AT_GNAT_use_descriptive_type flag for Ada 
 units.
 
 This patch first renames the DW_AT_use_GNAT_descriptive_type DWARF
 attribute into DW_AT_GNAT_use_descriptive_type to better follow
 the usual convention of keeping the vendor tag at the beginning
 of the name.
 
 It then modifies dwadrf2out to generate this attribute for Ada units.
 
 include/ChangeLog:
 
 * dwarf2.def: Rename DW_AT_use_GNAT_descriptive_type into
 DW_AT_GNAT_use_descriptive_type.
 
 gcc/ChangeLog:
 
 * dwarf2out.c (gen_compile_unit_die): Add
 DW_AT_use_GNAT_descriptive_type attribute for Ada units.
 ---
  gcc/dwarf2out.c|4 
  include/dwarf2.def |2 +-
  2 files changed, 5 insertions(+), 1 deletions(-)
 
 diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
 index d1ca4ba..057605c 100644
 --- a/gcc/dwarf2out.c
 +++ b/gcc/dwarf2out.c
 @@ -19318,6 +19318,10 @@ gen_compile_unit_die (const char *filename)
/* The default DW_ID_case_sensitive doesn't need to be specified.  */
break;
  }
 +
 +  if (language == DW_LANG_Ada95)
 +add_AT_flag (die, DW_AT_GNAT_use_descriptive_type, 1);
 +
return die;
  }
  
 diff --git a/include/dwarf2.def b/include/dwarf2.def
 index 71a37b3..4dd636e 100644
 --- a/include/dwarf2.def
 +++ b/include/dwarf2.def
 @@ -398,7 +398,7 @@ DW_AT (DW_AT_VMS_rtnbeg_pd_address, 0x2201)
  /* GNAT extensions.  */
  /* GNAT descriptive type.
 See http://gcc.gnu.org/wiki/DW_AT_GNAT_descriptive_type .  */
 -DW_AT (DW_AT_use_GNAT_descriptive_type, 0x2301)
 +DW_AT (DW_AT_GNAT_use_descriptive_type, 0x2301)
  DW_AT (DW_AT_GNAT_descriptive_type, 0x2302)
  /* UPC extension.  */
  DW_AT (DW_AT_upc_threads_scaled, 0x3210)
 -- 
 1.7.0.4
 


-- 
Joel

Re: [PATCH 1/2] Windows libibery: Don't quote args unnecessarily

[Joel Brobecker]

 Changelog libiberty/
   * pex-win32.c (argv_to_cmdline): Don't quote
   args unnecessarily

Some minor comments...

  diff --git a/libiberty/pex-win32.c b/libiberty/pex-win32.c
  index eae72c5..775b53c 100644
  --- a/libiberty/pex-win32.c
  +++ b/libiberty/pex-win32.c
  @@ -340,17 +340,26 @@ argv_to_cmdline (char *const *argv)
 char *p;
 size_t cmdline_len;
 int i, j, k;
  +  int needs_quotes;
   
 cmdline_len = 0;
 for (i = 0; argv[i]; i++)
   {
  -  /* We quote every last argument.  This simplifies the problem;
  -we need only escape embedded double-quotes and immediately
  +  /* We only quote arguments that contain spaces, \n \t \v or 
  characters
  +to prevent wasting 2 chars per argument of the CreateProcess 32k char
  +limit We need only escape embedded double-quotes and immediately

Period missing after limit.  JIC, remember that we ask that periods be
followed by 2 spaces.

   preceeding backslash characters.  A sequence of backslach characters
   that is not follwed by a double quote character will not be
   escaped.  */
  +  needs_quotes = 0;
 for (j = 0; argv[i][j]; j++)
  {
  + if (argv[i][j] == ' '  || argv[i][j] == '\n' ||
  + argv[i][j] == '\t' || argv[i][j] == '' )

GNU Coding Style requirement: Binary operators should be at the start
of the next line, not at the end. For instance:

  if (argv[i][j] == ' '  || argv[i][j] == '\n'
  || argv[i][j] == '\t' || argv[i][j] == '')

Also, watch out for the extra space before ')' - please remove it.


  +   {
 Here seems to be an intend issue.
  + needs_quotes = 1;
  +   }
  +
if (argv[i][j] == '')
  {
/* Escape preceeding backslashes.  */
  @@ -362,16 +371,34 @@ argv_to_cmdline (char *const *argv)
  }
 /* Trailing backslashes also need to be escaped because they will be
followed by the terminating quote.  */
  -  for (k = j - 1; k = 0  argv[i][k] == '\\'; k--)
  -   cmdline_len++;
  +  if (needs_quotes)
  +{
  +  for (k = j - 1; k = 0  argv[i][k] == '\\'; k--)
  +cmdline_len++;
  +}
 cmdline_len += j;
  -  cmdline_len += 3;  /* for leading and trailing quotes and space */
  +  /* for leading and trailing quotes and space */
  +  cmdline_len += needs_quotes * 2 + 1;
   }
 cmdline = XNEWVEC (char, cmdline_len);
 p = cmdline;
 for (i = 0; argv[i]; i++)
   {
  -  *p++ = '';
  +  needs_quotes = 0;
  +  for (j = 0; argv[i][j]; j++)
  +{
  +  if (argv[i][j] == ' '  || argv[i][j] == '\n' ||
  +  argv[i][j] == '\t' || argv[i][j] == '' )

Same as above.

  +{
  +  needs_quotes = 1;
  +  break;
  +}
  +}
  +
  +  if (needs_quotes)
  +{
  +  *p++ = '';
  +}
 for (j = 0; argv[i][j]; j++)
  {
if (argv[i][j] == '')
  @@ -382,9 +409,12 @@ argv_to_cmdline (char *const *argv)
  }
*p++ = argv[i][j];
  }
  -  for (k = j - 1; k = 0  argv[i][k] == '\\'; k--)
  -   *p++ = '\\';
  -  *p++ = '';
  +  if (needs_quotes)
  +{
  +  for (k = j - 1; k = 0  argv[i][k] == '\\'; k--)
  +*p++ = '\\';
  +  *p++ = '';
  +}
 *p++ = ' ';
   }
 p[-1] = '\0';
  --
  1.9.2
 
 Patch itself makes sense.  Let see if there are additional comments.
 
 Regards,
 Kai

-- 
Joel

Re: copyright dates in binutils (and includes/)

[Joel Brobecker]

 Joseph, do you know why implicitly adding years to the claimed
 copyright years is a problem?  I'm guessing the file needs to be
 published somewhere for each year claimed.

IANAL, but from 2 discussions with copyright-clerk:

  1. We start claiming copyright the year the file as committed
 to a medium (hard drive), not the year it was published.

  2. As long as we have evidence of a copyrightable change each year,
 we can include that year in the list of copyright years in
 all files' headers.

For (2), this is how I asked the FSF:

 My question is: As we have evidence of copyrightable changes to the
 GDB project every year since 1986, is it acceptable fix the copyright
 headers to add the missing holes? And if yes, is it acceptable to go
 straight to the next step, which is reducing the copyright years to
 a single range, even if the original list had holes in it? (we will
 make sure that the first year of the range is always 1986 or later,
 or else investigate to make sure that the range is correct).

 For example, we would reduce:

  Copyright (C) 1986, 1988-1989, 1991-1993, 1999-2000, 2007-2012 Free
  Software Foundation, Inc.

 into:

  1986-2012 Free Software Foundation, Inc.

 Naturally, if the initial year was 1995, then it would be the year
 used as the start of the range!

... to which they answered that it would be acceptable.

Does it mean that the sources needed to be made public that year for
us to be able to claim copyright that year? It did not seem so to me.
But you could ask the FSF (copyright DASH clerk AT fsf DOT org).

-- 
Joel

Re: copyright dates in binutils (and includes/)

[Joel Brobecker]

Hi Alan,

My two cents...

 --- a/bfd/elf32-sparc.c
 +++ b/bfd/elf32-sparc.c
 @@ -1,7 +1,5 @@
  /* SPARC-specific support for 32-bit ELF
 -   Copyright 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
 -   2003, 2004, 2005, 2006, 2007, 2010, 2011
 -   Free Software Foundation, Inc.
 +   Copyright (C) 1993-2014 Free Software Foundation, Inc.
  
 This file is part of BFD, the Binary File Descriptor library.
  
 Does anyone have a violent objection to committing updates in
 bfd, binutils, elfcpp, gas, gold, gprof, ld, and opcodes?

FWIW, I find that the new ouptut is a nice improvement.

I should mention, however, that for us to use ranges like this,
the FSF asked us to add a note explaining that the copyright years
could be abbreviated into a range. See gdb/README (at the end).
I suspect that you'll need the same note for binutils.

 How about includes/ too?  The choices there are
 a) apply to just binutils owned files, 
 b) apply to binutils+gdb files,
 c) apply to the lot, and update gcc/include/ too.
 
 I see Joel already updated include/gdb, but the script makes a further
 small change.  So choice (b) in include/gdb consists of patches like
 the following:

IIRC, the FSF does not require the (C), but I think they would
prefer it. Either way, it doesn't get in the way for future updates,
so I'd go with at least (b).

As for (c), I'll let the GCC folks answer.

-- 
Joel

Re: [RFA/dwarf v2] Add DW_AT_GNAT_use_descriptive_type flag for Ada units.

[Joel Brobecker]

Hello,

Would anyone be able to (re-)approve this patch, please?

It should be really really straightforward, and only adds a DWARF
flag to Ada Compilation Units, so I should think that the risk
is near zero. I've tested the patch as usual regardless.

Parallel to that, we have also started working on producing
standard DWARF in place of our encodings, and small progress has been
made. But this is even more of a huge task than we thought, and in
the meantime, this little flag will help non-AdaCore users...

Thank you!

On Fri, Jan 31, 2014 at 09:09:05AM +0400, Joel Brobecker wrote:
 On Tue, Feb 19, 2013 at 10:50:46PM -0500, Jason Merrill wrote:
  On 02/19/2013 10:42 PM, Joel Brobecker wrote:
  This is useful when a DIE does not have a descriptive type attribute.
  In that case, the debugger needs to determine whether the unit
  was compiled with a compiler that normally provides that information,
  or not.
  
  Ah.  OK, then.  But I'd prefer to call it
  DW_AT_GNAT_use_descriptive_type, to follow the convention of keeping
  the vendor tag at the beginning of the name.
 
 Almost a year ago, you privately approved a small patch of mine,
 with the small request above. I'm sorry I let it drag so long!
 Here is the updated patch.
 
 include/ChangeLog:
 
 * dwarf2.def: Rename DW_AT_use_GNAT_descriptive_type into
 DW_AT_GNAT_use_descriptive_type.
 
 gcc/ChangeLog:
 
 * dwarf2out.c (gen_compile_unit_die): Add
 DW_AT_use_GNAT_descriptive_type attribute for Ada units.
 
 Tested on x86_64-linux.
 
 I should also adjust the Wiki page accordingly, but the login process
 keeps timing out. I know I have the right login and passwd since
 I succesfully reset them using the passwd recovery procedure, just
 in case the error was due to bad credentials. I'll try again later.
 
 If approved, I will also take care of coordinating the dwarf2.def
 change with binutils-gdb.git.
 
 Is this patch still OK to commit?
 
 Thank you,
 -- 
 Joel

 From 7aae3721addf6905113d9f0287a5cbb5301a462b Mon Sep 17 00:00:00 2001
 From: Joel Brobecker brobec...@adacore.com
 Date: Thu, 3 Jan 2013 09:25:12 -0500
 Subject: [PATCH] [dwarf] Add DW_AT_GNAT_use_descriptive_type flag for Ada 
 units.
 
 This patch first renames the DW_AT_use_GNAT_descriptive_type DWARF
 attribute into DW_AT_GNAT_use_descriptive_type to better follow
 the usual convention of keeping the vendor tag at the beginning
 of the name.
 
 It then modifies dwadrf2out to generate this attribute for Ada units.
 
 include/ChangeLog:
 
 * dwarf2.def: Rename DW_AT_use_GNAT_descriptive_type into
 DW_AT_GNAT_use_descriptive_type.
 
 gcc/ChangeLog:
 
 * dwarf2out.c (gen_compile_unit_die): Add
 DW_AT_use_GNAT_descriptive_type attribute for Ada units.
 ---
  gcc/dwarf2out.c|4 
  include/dwarf2.def |2 +-
  2 files changed, 5 insertions(+), 1 deletions(-)
 
 diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
 index d1ca4ba..057605c 100644
 --- a/gcc/dwarf2out.c
 +++ b/gcc/dwarf2out.c
 @@ -19318,6 +19318,10 @@ gen_compile_unit_die (const char *filename)
/* The default DW_ID_case_sensitive doesn't need to be specified.  */
break;
  }
 +
 +  if (language == DW_LANG_Ada95)
 +add_AT_flag (die, DW_AT_GNAT_use_descriptive_type, 1);
 +
return die;
  }
  
 diff --git a/include/dwarf2.def b/include/dwarf2.def
 index 71a37b3..4dd636e 100644
 --- a/include/dwarf2.def
 +++ b/include/dwarf2.def
 @@ -398,7 +398,7 @@ DW_AT (DW_AT_VMS_rtnbeg_pd_address, 0x2201)
  /* GNAT extensions.  */
  /* GNAT descriptive type.
 See http://gcc.gnu.org/wiki/DW_AT_GNAT_descriptive_type .  */
 -DW_AT (DW_AT_use_GNAT_descriptive_type, 0x2301)
 +DW_AT (DW_AT_GNAT_use_descriptive_type, 0x2301)
  DW_AT (DW_AT_GNAT_descriptive_type, 0x2302)
  /* UPC extension.  */
  DW_AT (DW_AT_upc_threads_scaled, 0x3210)
 -- 
 1.7.0.4
 


-- 
Joel

[RFA/dwarf v2] Add DW_AT_GNAT_use_descriptive_type flag for Ada units.

[Joel Brobecker]

Hi Jason,

On Tue, Feb 19, 2013 at 10:50:46PM -0500, Jason Merrill wrote:
 On 02/19/2013 10:42 PM, Joel Brobecker wrote:
 This is useful when a DIE does not have a descriptive type attribute.
 In that case, the debugger needs to determine whether the unit
 was compiled with a compiler that normally provides that information,
 or not.
 
 Ah.  OK, then.  But I'd prefer to call it
 DW_AT_GNAT_use_descriptive_type, to follow the convention of keeping
 the vendor tag at the beginning of the name.

Almost a year ago, you privately approved a small patch of mine,
with the small request above. I'm sorry I let it drag so long!
Here is the updated patch.

include/ChangeLog:

* dwarf2.def: Rename DW_AT_use_GNAT_descriptive_type into
DW_AT_GNAT_use_descriptive_type.

gcc/ChangeLog:

* dwarf2out.c (gen_compile_unit_die): Add
DW_AT_use_GNAT_descriptive_type attribute for Ada units.

Tested on x86_64-linux.

I should also adjust the Wiki page accordingly, but the login process
keeps timing out. I know I have the right login and passwd since
I succesfully reset them using the passwd recovery procedure, just
in case the error was due to bad credentials. I'll try again later.

If approved, I will also take care of coordinating the dwarf2.def
change with binutils-gdb.git.

Is this patch still OK to commit?

Thank you,
-- 
Joel

Re: [RFA/dwarf v2] Add DW_AT_GNAT_use_descriptive_type flag for Ada units.

[Joel Brobecker]

[resending with the patch - sorry about that]

Hi Jason,

On Tue, Feb 19, 2013 at 10:50:46PM -0500, Jason Merrill wrote:
 On 02/19/2013 10:42 PM, Joel Brobecker wrote:
 This is useful when a DIE does not have a descriptive type attribute.
 In that case, the debugger needs to determine whether the unit
 was compiled with a compiler that normally provides that information,
 or not.
 
 Ah.  OK, then.  But I'd prefer to call it
 DW_AT_GNAT_use_descriptive_type, to follow the convention of keeping
 the vendor tag at the beginning of the name.

Almost a year ago, you privately approved a small patch of mine,
with the small request above. I'm sorry I let it drag so long!
Here is the updated patch.

include/ChangeLog:

* dwarf2.def: Rename DW_AT_use_GNAT_descriptive_type into
DW_AT_GNAT_use_descriptive_type.

gcc/ChangeLog:

* dwarf2out.c (gen_compile_unit_die): Add
DW_AT_use_GNAT_descriptive_type attribute for Ada units.

Tested on x86_64-linux.

I should also adjust the Wiki page accordingly, but the login process
keeps timing out. I know I have the right login and passwd since
I succesfully reset them using the passwd recovery procedure, just
in case the error was due to bad credentials. I'll try again later.

If approved, I will also take care of coordinating the dwarf2.def
change with binutils-gdb.git.

Is this patch still OK to commit?

Thank you,
-- 
Joel
From 7aae3721addf6905113d9f0287a5cbb5301a462b Mon Sep 17 00:00:00 2001
From: Joel Brobecker brobec...@adacore.com
Date: Thu, 3 Jan 2013 09:25:12 -0500
Subject: [PATCH] [dwarf] Add DW_AT_GNAT_use_descriptive_type flag for Ada units.

This patch first renames the DW_AT_use_GNAT_descriptive_type DWARF
attribute into DW_AT_GNAT_use_descriptive_type to better follow
the usual convention of keeping the vendor tag at the beginning
of the name.

It then modifies dwadrf2out to generate this attribute for Ada units.

include/ChangeLog:

* dwarf2.def: Rename DW_AT_use_GNAT_descriptive_type into
DW_AT_GNAT_use_descriptive_type.

gcc/ChangeLog:

* dwarf2out.c (gen_compile_unit_die): Add
DW_AT_use_GNAT_descriptive_type attribute for Ada units.
---
 gcc/dwarf2out.c|4 
 include/dwarf2.def |2 +-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index d1ca4ba..057605c 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -19318,6 +19318,10 @@ gen_compile_unit_die (const char *filename)
   /* The default DW_ID_case_sensitive doesn't need to be specified.  */
   break;
 }
+
+  if (language == DW_LANG_Ada95)
+add_AT_flag (die, DW_AT_GNAT_use_descriptive_type, 1);
+
   return die;
 }
 
diff --git a/include/dwarf2.def b/include/dwarf2.def
index 71a37b3..4dd636e 100644
--- a/include/dwarf2.def
+++ b/include/dwarf2.def
@@ -398,7 +398,7 @@ DW_AT (DW_AT_VMS_rtnbeg_pd_address, 0x2201)
 /* GNAT extensions.  */
 /* GNAT descriptive type.
See http://gcc.gnu.org/wiki/DW_AT_GNAT_descriptive_type .  */
-DW_AT (DW_AT_use_GNAT_descriptive_type, 0x2301)
+DW_AT (DW_AT_GNAT_use_descriptive_type, 0x2301)
 DW_AT (DW_AT_GNAT_descriptive_type, 0x2302)
 /* UPC extension.  */
 DW_AT (DW_AT_upc_threads_scaled, 0x3210)
-- 
1.7.0.4

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Joel Brobecker]

 Thanks!  That's great progress on the Binutils side.

You are very welcome.

 What is the status of patches for GCC to generate DWARF for AIX XCOFF
 and do the AIX assembler and linker recognize, consume and process the
 directives produced by GCC correctly?

I haven't looked at this part in details, but our recollection is that
it's a matter of configuring GCC with --with-gnu-as and --with-gnu-ld,
together with a small patch to make DWARF the default. AFAIK, the rest
should be working as expected.

-- 
Joel

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Joel Brobecker]

   AFAICT, for gcc+gas it should already work with binutils that include
   the AdaCore patch for DWARF support. But this has apparently not been
   tested with AIX ld, and there are AdaCore local patches pending.
   http://sourceware.org/ml/binutils/2011-04/msg00250.html
   http://www.sourceware.org/ml/gdb/2013-01/msg00030.html
  
  What is the status of merging Adacore's patches for DWARF support on AIX?

For cross-reference purposes, I sent the following update on
binutils:

FYI: patches for powerpc-aix...
http://www.sourceware.org/ml/binutils/2013-02/msg00233.html

So, not quite there yet, but getting a lot closer.

-- 
Joel

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Joel Brobecker]

  AFAICT, for gcc+gas it should already work with binutils that include
  the AdaCore patch for DWARF support. But this has apparently not been
  tested with AIX ld, and there are AdaCore local patches pending.
  http://sourceware.org/ml/binutils/2011-04/msg00250.html
  http://www.sourceware.org/ml/gdb/2013-01/msg00030.html
 
 What is the status of merging Adacore's patches for DWARF support on AIX?

Sorry, David. I have been meaning to work on that ever since
we talked about it...

I spent some time today isolating the patches. I am currently
testing the patches we wrote for support on AIX 5.3. I then see
a few more patches to extend support to AIX 7.1 - section alignment
constraints, and stuff related to TLS.

Just for anyone who is curious, this is what I am testing.
It is missing the pieces for the other tools such as objdump,
for instance. But I think those can be submitted separately.

It might not apply to HEAD just yet, because I'm going at it
step by step. For those who use git, I applied it on top of:

commit 889f73fdb5bec852e083f47703f31592ef3ee77b
Author: Alan Modra amo...@bigpond.net.au
Date:   Thu Oct 18 23:00:04 2012 +

daily update

-- 
Joel
From dc928a0dbd0e762577c51204b043d6b6f066940d Mon Sep 17 00:00:00 2001
From: Joel Brobecker brobec...@adacore.com
Date: Thu, 14 Feb 2013 23:53:25 +0100
Subject: [PATCH] AIX: add DWARF support

* bfd/coff-rs6000.c (xcoff_dwsect_names): Add .dwframe,
.dwloc, .dwmacif and .dwmacro.
* bfd/libxcoff.h (XCOFF_DWSECT_NBR_NAMES): Set to 12.
* xcofflink.c (xcoff_mark): Mark all debugging symbols.
(bfd_xcoff_size_dynamic_sections): Mark all debugging sections.
(xcoff_link_input_bfd): Gah???
* gas/config/tc-ppc.c (ppc_named_section): Add handling
of DWARF sections.
---
 bfd/coff-rs6000.c   |6 -
 bfd/libxcoff.h  |2 +-
 bfd/xcofflink.c |   65 +-
 gas/config/tc-ppc.c |   29 ++-
 4 files changed, 72 insertions(+), 30 deletions(-)

diff --git a/bfd/coff-rs6000.c b/bfd/coff-rs6000.c
index 0945aca..9388ce3 100644
--- a/bfd/coff-rs6000.c
+++ b/bfd/coff-rs6000.c
@@ -3916,7 +3916,11 @@ const struct xcoff_dwsect_name xcoff_dwsect_names[] = {
   { SSUBTYP_DWARNGE, .dwarnge,  TRUE },
   { SSUBTYP_DWABREV, .dwabrev,  FALSE },
   { SSUBTYP_DWSTR,   .dwstr,TRUE },
-  { SSUBTYP_DWRNGES, .dwrnges,  TRUE }
+  { SSUBTYP_DWRNGES, .dwrnges,  TRUE },
+  { 0x4700,  .dwframe,  TRUE },
+  { 0x4701,  .dwloc,TRUE },
+  { 0x4702,  .dwmacif,  FALSE },
+  { 0x4703,  .dwmacro,  FALSE }
 };
 
 static const struct xcoff_backend_data_rec bfd_xcoff_backend_data =
diff --git a/bfd/libxcoff.h b/bfd/libxcoff.h
index 53a5e72..7583d5c 100644
--- a/bfd/libxcoff.h
+++ b/bfd/libxcoff.h
@@ -251,7 +251,7 @@ struct xcoff_dwsect_name {
 
 /* Number of entries in the array.  The number is known and public so that user
can 'extend' this array by index.  */
-#define XCOFF_DWSECT_NBR_NAMES	8
+#define XCOFF_DWSECT_NBR_NAMES	12
 
 /* The dwarf sections array.  */
 extern const struct xcoff_dwsect_name
diff --git a/bfd/xcofflink.c b/bfd/xcofflink.c
index 4adfb17..ad31643 100644
--- a/bfd/xcofflink.c
+++ b/bfd/xcofflink.c
@@ -2902,8 +2902,7 @@ xcoff_mark (struct bfd_link_info *info, asection *sec)
   sec-flags |= SEC_MARK;
 
   if (sec-owner-xvec == info-output_bfd-xvec
-   coff_section_data (sec-owner, sec) != NULL
-   xcoff_section_data (sec-owner, sec) != NULL)
+   coff_section_data (sec-owner, sec) != NULL)
 {
   struct xcoff_link_hash_entry **syms;
   struct internal_reloc *rel, *relend;
@@ -2911,18 +2910,21 @@ xcoff_mark (struct bfd_link_info *info, asection *sec)
   unsigned long i, first, last;
 
   /* Mark all the symbols in this section.  */
-  syms = obj_xcoff_sym_hashes (sec-owner);
-  csects = xcoff_data (sec-owner)-csects;
-  first = xcoff_section_data (sec-owner, sec)-first_symndx;
-  last = xcoff_section_data (sec-owner, sec)-last_symndx;
-  for (i = first; i = last; i++)
-	if (csects[i] == sec
-	 syms[i] != NULL
-	 (syms[i]-flags  XCOFF_MARK) == 0)
-	  {
-	if (!xcoff_mark_symbol (info, syms[i]))
-	  return FALSE;
-	  }
+  if (xcoff_section_data (sec-owner, sec) != NULL)
+{
+  syms = obj_xcoff_sym_hashes (sec-owner);
+  csects = xcoff_data (sec-owner)-csects;
+  first = xcoff_section_data (sec-owner, sec)-first_symndx;
+  last = xcoff_section_data (sec-owner, sec)-last_symndx;
+  for (i = first; i = last; i++)
+if (csects[i] == sec
+ syms[i] != NULL
+ (syms[i]-flags  XCOFF_MARK) == 0)
+  {
+if (!xcoff_mark_symbol (info, syms[i]))
+  return FALSE;
+  }
+}
 
   /* Look through the section relocs.  */
   if ((sec-flags  SEC_RELOC) != 0
@@ -2965,7 +2967,8

Ping: [RFA/dwarf] Add DW_AT_use_GNAT_descriptive_type flag for Ada units.

[Joel Brobecker]

Hello,

I was hoping someone would kindly review this patch? It is an
important part for debugging Ada code, helping with performance.

Thank you!

On Tue, Jan 08, 2013 at 07:24:14AM -0500, Joel Brobecker wrote:
 Hello,
 
 I just noticed that part of the proposal we made for...
 http://gcc.gnu.org/wiki/DW_AT_GNAT_descriptive_type
 
 ... got missed in the patch that got checked in:
 http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00099.html
 
 In particular, we're missing the second part, where we are
 expected to generate a DW_AT_use_GNAT_descriptive_type flag
 in the CU in order to tell the consumers that we are providing
 the descriptive type.
 
 gcc/ChangeLog:
 
 * dwarf2out.c (gen_compile_unit_die): Add
 DW_AT_use_GNAT_descriptive_type attribute for Ada units.
 
 Tested on x86_64-linux, no regression. I also tested against
 the GDB testsuite, before and after, and no regression.  This
 is expected, since GDB currently does not look for this attribute
 (but I would like it to).
 
 OK to apply for HEAD and 4.7?
 
 Thanks,
 -- 
 Joel
 
 ---
  gcc/dwarf2out.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)
 
 diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
 index a865250..8117ce9 100644
 --- a/gcc/dwarf2out.c
 +++ b/gcc/dwarf2out.c
 @@ -18940,6 +18940,10 @@ gen_compile_unit_die (const char *filename)
/* The default DW_ID_case_sensitive doesn't need to be specified.  */
break;
  }
 +
 +  if (language == DW_LANG_Ada95)
 +add_AT_flag (die, DW_AT_use_GNAT_descriptive_type, 1);
 +
return die;
  }
  
 -- 
 1.7.0.4

-- 
Joel

Re: [RFA/dwarf] Add DW_AT_use_GNAT_descriptive_type flag for Ada units.

[Joel Brobecker]

Ping?

Thank you!

On Tue, Jan 08, 2013 at 07:24:14AM -0500, Joel Brobecker wrote:
 Hello,
 
 I just noticed that part of the proposal we made for...
 http://gcc.gnu.org/wiki/DW_AT_GNAT_descriptive_type
 
 ... got missed in the patch that got checked in:
 http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00099.html
 
 In particular, we're missing the second part, where we are
 expected to generate a DW_AT_use_GNAT_descriptive_type flag
 in the CU in order to tell the consumers that we are providing
 the descriptive type.
 
 gcc/ChangeLog:
 
 * dwarf2out.c (gen_compile_unit_die): Add
 DW_AT_use_GNAT_descriptive_type attribute for Ada units.
 
 Tested on x86_64-linux, no regression. I also tested against
 the GDB testsuite, before and after, and no regression.  This
 is expected, since GDB currently does not look for this attribute
 (but I would like it to).
 
 OK to apply for HEAD and 4.7?
 
 Thanks,
 -- 
 Joel
 
 ---
  gcc/dwarf2out.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)
 
 diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
 index a865250..8117ce9 100644
 --- a/gcc/dwarf2out.c
 +++ b/gcc/dwarf2out.c
 @@ -18940,6 +18940,10 @@ gen_compile_unit_die (const char *filename)
/* The default DW_ID_case_sensitive doesn't need to be specified.  */
break;
  }
 +
 +  if (language == DW_LANG_Ada95)
 +add_AT_flag (die, DW_AT_use_GNAT_descriptive_type, 1);
 +
return die;
  }
  
 -- 
 1.7.0.4

-- 
Joel

Re: [RFA] statement before variable declaration in cp_parser_initializer_list.

[Joel Brobecker]

Hi Richard,

  Hmm?  We compile with a C++ compiler where this is perfectly valid ...
 
  I was compiling with GCC 4.7 where it gave me a warning... I don't know
  much about C++ anymore, so I didn't know. Oh well!
 
 Ah, for the 4.7 branch yes.

Eric Botcazou asked that we have the same code for both 4.7 and HEAD.
Would it be OK to apply it to both? It's not really strictly
necessary for the HEAD, but I don't see it as being harmful either.

Thank you!
-- 
Joel

[RFA/dwarf] Add DW_AT_use_GNAT_descriptive_type flag for Ada units.

[Joel Brobecker]

Hello,

I just noticed that part of the proposal we made for...
http://gcc.gnu.org/wiki/DW_AT_GNAT_descriptive_type

... got missed in the patch that got checked in:
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00099.html

In particular, we're missing the second part, where we are
expected to generate a DW_AT_use_GNAT_descriptive_type flag
in the CU in order to tell the consumers that we are providing
the descriptive type.

gcc/ChangeLog:

* dwarf2out.c (gen_compile_unit_die): Add
DW_AT_use_GNAT_descriptive_type attribute for Ada units.

Tested on x86_64-linux, no regression. I also tested against
the GDB testsuite, before and after, and no regression.  This
is expected, since GDB currently does not look for this attribute
(but I would like it to).

OK to apply for HEAD and 4.7?

Thanks,
-- 
Joel

---
 gcc/dwarf2out.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index a865250..8117ce9 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -18940,6 +18940,10 @@ gen_compile_unit_die (const char *filename)
   /* The default DW_ID_case_sensitive doesn't need to be specified.  */
   break;
 }
+
+  if (language == DW_LANG_Ada95)
+add_AT_flag (die, DW_AT_use_GNAT_descriptive_type, 1);
+
   return die;
 }
 
-- 
1.7.0.4

Re: [RFA] statement before variable declaration in cp_parser_initializer_list.

[Joel Brobecker]

  Eric Botcazou asked that we have the same code for both 4.7 and HEAD.
  Would it be OK to apply it to both? It's not really strictly
  necessary for the HEAD, but I don't see it as being harmful either.
 
 Sure.

Thank you! Now checked in.

-- 
Joel

[RFA] statement before variable declaration in cp_parser_initializer_list.

[Joel Brobecker]

Hello,

I happened to notice a warning while compiling GCC, and it seemed
like an easy fix...

gcc/cp/ChangeLog:

* parser.c (cp_parser_initializer_list): Move declaration
of variable non_const to start of lexical block.

Tested against x86_64-linux, no regression.
OK to commit? (obvious?)

Thanks,
-- 
Joel

---
 gcc/cp/parser.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 3dc2ec6..61d93f8 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -17932,9 +17932,10 @@ cp_parser_initializer_list (cp_parser* parser, bool* 
non_constant_p)
cp_lexer_next_token_is (parser-lexer, CPP_OPEN_SQUARE))
{
  /* In C++11, [ could start a lambda-introducer.  */
+ bool non_const = false;
+
  cp_parser_parse_tentatively (parser);
  cp_lexer_consume_token (parser-lexer);
- bool non_const = false;
  designator = cp_parser_constant_expression (parser, true, non_const);
  cp_parser_require (parser, CPP_CLOSE_SQUARE, RT_CLOSE_SQUARE);
  cp_parser_require (parser, CPP_EQ, RT_EQ);
-- 
1.7.0.4

Re: [RFA] statement before variable declaration in cp_parser_initializer_list.

[Joel Brobecker]

  Tested against x86_64-linux, no regression.
  OK to commit? (obvious?)
 
 Hmm?  We compile with a C++ compiler where this is perfectly valid ...

I was compiling with GCC 4.7 where it gave me a warning... I don't know
much about C++ anymore, so I didn't know. Oh well!

-- 
Joel

Re: [RFA] .gitignore: Ignore *.pyc files.

[Joel Brobecker]

Ping. This patch seems fairly straightforward to the point of
being almost obvious, but so far, no review (beyond one email
expressing interest).

Thanks!


 The GDB sources contain some python files, and executing them
 causes these .pyc files to appear.  We could ignore them in GDB
 only, but I think this is the type of extension (compilation
 artifact) which can be shared amoung all projects.
 
 ChangeLog:
 
 * .gitignore: Ignore *.pyc file.
 
 Ok to apply?
 Thanks,
 -- 
 Joel
 
 ---
  .gitignore |1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/.gitignore b/.gitignore
 index dc1bf3f..8e2e1e9 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -12,6 +12,7 @@
  *.la
  *.lo
  *.o
 +*.pyc
  *.tmp
  
  .deps
 -- 
 1.7.10.4

-- 
Joel

[RFA] .gitignore: Ignore *.pyc files.

[Joel Brobecker]

Hello,

The GDB sources contain some python files, and executing them
causes these .pyc files to appear.  We could ignore them in GDB
only, but I think this is the type of extension (compilation
artifact) which can be shared amoung all projects.

ChangeLog:

* .gitignore: Ignore *.pyc file.

Ok to apply?
Thanks,
-- 
Joel

---
 .gitignore |1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index dc1bf3f..8e2e1e9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,6 +12,7 @@
 *.la
 *.lo
 *.o
+*.pyc
 *.tmp
 
 .deps
-- 
1.7.10.4

Re: [RFA] Update config.sub to 2012-04-18 version.

[Joel Brobecker]

 ChangeLog:
 
 * config.sub: Update to 2012-04-18 version from official repo.

Thanks to everyone who answered. This patch is no in, both GCC  src.

-- 
Joel

[RFA] Update config.sub to 2012-04-18 version.

[Joel Brobecker]

Hello everyone,

I wasn't sure if I needed approval for this patch or not, but better
be safe than sorry. I'll apply to both GCC and then src when I receive
confirmation that it's OK to apply.

I would like to update the config.sub script to the latest version
from the official config repo.  The bits that I need are just the
ones related to LynxOS, but I figured it'd be better be consistent
with the official version.  I can change the patch to just commit
the one hunk for LynxOS, if people prefer.  But I think we'd become
inconsistent.

ChangeLog:

* config.sub: Update to 2012-04-18 version from official repo.

OK to apply?

---
 config.sub |   42 +++---
 1 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/config.sub b/config.sub
index 78176a4..59bb593 100755
--- a/config.sub
+++ b/config.sub
@@ -2,9 +2,9 @@
 # Configuration validation subroutine script.
 #   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
 #   2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
-#   2011 Free Software Foundation, Inc.
+#   2011, 2012 Free Software Foundation, Inc.
 
-timestamp='2011-10-29'
+timestamp='2012-04-18'
 
 # This file is (in principle) common to ALL GNU software.
 # The presence of a machine in this file suggests that SOME GNU software
@@ -21,9 +21,7 @@ timestamp='2011-10-29'
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA
-# 02110-1301, USA.
+# along with this program; if not, see http://www.gnu.org/licenses/.
 #
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
@@ -76,8 +74,8 @@ version=\
 GNU config.sub ($timestamp)
 
 Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 Free
-Software Foundation, Inc.
+2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
+Free Software Foundation, Inc.
 
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
@@ -132,6 +130,10 @@ case $maybe_os in
 os=-$maybe_os
 basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
 ;;
+  android-linux)
+os=-linux-android
+basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`-unknown
+;;
   *)
 basic_machine=`echo $1 | sed 's/-[^-]*$//'`
 if [ $basic_machine != $1 ]
@@ -223,6 +225,12 @@ case $os in
-isc*)
basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
;;
+   -lynx*178)
+   os=-lynxos178
+   ;;
+   -lynx*5)
+   os=-lynxos5
+   ;;
-lynx*)
os=-lynxos
;;
@@ -247,6 +255,7 @@ case $basic_machine in
# Some are omitted here because they have special meanings below.
1750a | 580 \
| a29k \
+   | aarch64 | aarch64_be \
| alpha | alphaev[4-8] | alphaev56 | alphaev6[78] | alphapca5[67] \
| alpha64 | alpha64ev[4-8] | alpha64ev56 | alpha64ev6[78] | 
alpha64pca5[67] \
| am33_2.0 \
@@ -319,8 +328,7 @@ case $basic_machine in
c6x)
basic_machine=tic6x-unknown
;;
-   m6811 | m68hc11 | m6812 | m68hc12 | picochip)
-   # Motorola 68HC11/12.
+   m6811 | m68hc11 | m6812 | m68hc12 | m68hcs12x | picochip)
basic_machine=$basic_machine-unknown
os=-none
;;
@@ -333,7 +341,10 @@ case $basic_machine in
strongarm | thumb | xscale)
basic_machine=arm-unknown
;;
-
+   xgate)
+   basic_machine=$basic_machine-unknown
+   os=-none
+   ;;
xscaleeb)
basic_machine=armeb-unknown
;;
@@ -356,6 +367,7 @@ case $basic_machine in
# Recognize the basic CPU types with company name.
580-* \
| a29k-* \
+   | aarch64-* | aarch64_be-* \
| alpha-* | alphaev[4-8]-* | alphaev56-* | alphaev6[78]-* \
| alpha64-* | alpha64ev[4-8]-* | alpha64ev56-* | alpha64ev6[78]-* \
| alphapca5[67]-* | alpha64pca5[67]-* | arc-* \
@@ -719,7 +731,6 @@ case $basic_machine in
i370-ibm* | ibm*)
basic_machine=i370-ibm
;;
-# I'm not sure what Sysv32 means.  Should this be sysv3.2?
i*86v32)
basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
os=-sysv32
@@ -816,6 +827,10 @@ case $basic_machine in
ms1-*)
basic_machine=`echo $basic_machine | sed -e 's/ms1-/mt-/'`
;;
+   msys)
+   basic_machine=i386-pc
+   os=-msys
+ 

Re: [RFA/libiberty] Darwin has case-insensitive filesystems

[Joel Brobecker]

 Looks OK to me.

Thanks, DJ. I've just checked the patch in on the GCC side.
I will push it on the src/GDB CVS momentarily.

-- 
Joel

[RFA/libiberty] Darwin has case-insensitive filesystems

[Joel Brobecker]

Hello,

HFS+, the FS on Darwin, is case insensitive. So this patch adjusts
filename_cmp.c to ignore the casing when comparing filenames on Darwin.

This is visible in GDB when trying to break on a file whose name
is, say 'Mixed_Case.adb', but was compiled using 'mixed_case.adb'
as the filename.  In that case, GDB says it cannot find 'Mixed_Case.adb'.

There are two parts:
  1. in include/filenames.h: I add a new macro
 HAVE_CASE_INSENSITIVE_FILE_SYSTEM, which is defined on systems
 that have DOS-like file systems, as well as on Darwin.
  2. Adjust filename_cmp and filename_ncmp to take it into account.

I am also wondering whether it makes sense or not to keep the
case-sensitive  no DOS-like features case separate, or whether
we should handle this case using the same code as on Windows/Darwin.
In other words, does it make a difference to be using strcmp/strncmp
when we can, versus always using our loop that compares character by
character?

include/ChangeLog:

* filenames.h (HAVE_CASE_INSENSITIVE_FILE_SYSTEM): Define
on Darwin, as well as on the systems that use a DOS-like
filesystem.

libiberty/ChangeLog:

* filename_cmp.c (filename_cmp, filename_ncmp): Add handling of
HAVE_CASE_INSENSITIVE_FILE_SYSTEM.

Tested on x86_64-darwin as well as on x86_64-linux. I haven't tested
on a Windows system yet, but I will get our gdb-testsuite's daily
results before tomorrow.

Does this look OK to commit?

Thanks!
-- 
Joel

---
 include/filenames.h  |8 
 libiberty/filename_cmp.c |   28 ++--
 2 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/include/filenames.h b/include/filenames.h
index d4955df..75ec330 100644
--- a/include/filenames.h
+++ b/include/filenames.h
@@ -34,10 +34,18 @@ extern C {
 #  ifndef HAVE_DOS_BASED_FILE_SYSTEM
 #define HAVE_DOS_BASED_FILE_SYSTEM 1
 #  endif
+#  ifndef HAVE_CASE_INSENSITIVE_FILE_SYSTEM
+#define HAVE_CASE_INSENSITIVE_FILE_SYSTEM 1
+#  endif
 #  define HAS_DRIVE_SPEC(f) HAS_DOS_DRIVE_SPEC (f)
 #  define IS_DIR_SEPARATOR(c) IS_DOS_DIR_SEPARATOR (c)
 #  define IS_ABSOLUTE_PATH(f) IS_DOS_ABSOLUTE_PATH (f)
 #else /* not DOSish */
+#  if defined(__APPLE__)
+#ifndef HAVE_CASE_INSENSITIVE_FILE_SYSTEM
+#  define HAVE_CASE_INSENSITIVE_FILE_SYSTEM 1
+#endif
+#  endif /* __APPLE__ */
 #  define HAS_DRIVE_SPEC(f) (0)
 #  define IS_DIR_SEPARATOR(c) IS_UNIX_DIR_SEPARATOR (c)
 #  define IS_ABSOLUTE_PATH(f) IS_UNIX_ABSOLUTE_PATH (f)
diff --git a/libiberty/filename_cmp.c b/libiberty/filename_cmp.c
index 0eed120..5179f8d 100644
--- a/libiberty/filename_cmp.c
+++ b/libiberty/filename_cmp.c
@@ -50,19 +50,27 @@ and backward slashes are equal.
 int
 filename_cmp (const char *s1, const char *s2)
 {
-#ifndef HAVE_DOS_BASED_FILE_SYSTEM
+#if !defined(HAVE_DOS_BASED_FILE_SYSTEM) \
+ !defined(HAVE_CASE_INSENSITIVE_FILE_SYSTEM)
   return strcmp(s1, s2);
 #else
   for (;;)
 {
-  int c1 = TOLOWER (*s1);
-  int c2 = TOLOWER (*s2);
+  int c1 = *s1;
+  int c2 = *s2;
 
+#if defined (HAVE_CASE_INSENSITIVE_FILE_SYSTEM)
+  c1 = TOLOWER (c1);
+  c2 = TOLOWER (c2);
+#endif
+
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
   /* On DOS-based file systems, the '/' and the '\' are equivalent.  */
   if (c1 == '/')
 c1 = '\\';
   if (c2 == '/')
 c2 = '\\';
+#endif
 
   if (c1 != c2)
 return (c1 - c2);
@@ -100,21 +108,29 @@ and backward slashes are equal.
 int
 filename_ncmp (const char *s1, const char *s2, size_t n)
 {
-#ifndef HAVE_DOS_BASED_FILE_SYSTEM
+#if !defined(HAVE_DOS_BASED_FILE_SYSTEM) \
+ !defined(HAVE_CASE_INSENSITIVE_FILE_SYSTEM)
   return strncmp(s1, s2, n);
 #else
   if (!n)
 return 0;
   for (; n  0; --n)
   {
-  int c1 = TOLOWER (*s1);
-  int c2 = TOLOWER (*s2);
+  int c1 = *s1;
+  int c2 = *s2;
 
+#if defined (HAVE_CASE_INSENSITIVE_FILE_SYSTEM)
+  c1 = TOLOWER (c1);
+  c2 = TOLOWER (c2);
+#endif
+
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
   /* On DOS-based file systems, the '/' and the '\' are equivalent.  */
   if (c1 == '/')
 c1 = '\\';
   if (c2 == '/')
 c2 = '\\';
+#endif
 
   if (c1 == '\0' || c1 != c2)
 return (c1 - c2);
-- 
1.7.1