diff mbox series

[COMMITTED] Fix procfs.c compilation

Message ID yddwmtzva61.fsf@CeBiTec.Uni-Bielefeld.DE
State New
Headers
Series [COMMITTED] Fix procfs.c compilation |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 fail Patch failed to apply
linaro-tcwg-bot/tcwg_gdb_build--master-arm fail Patch failed to apply

Commit Message

Rainer Orth Nov. 30, 2023, 9:54 a.m. UTC 
  procfs.c doesn't currently compile on Solaris:

/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function ‘virtual int procfs_target::can_use_hw_breakpoint(bptype, int, int)’:
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3017:9: error: ‘ptr_type’ was not declared in this scope; did you mean ‘var_types’?
 3017 |   type *ptr_type
      |         ^~~~~~~~
      |         var_types

This was caused by this patch:

commit 99d9c3b92ca96a7425cbb6b1bf453ede9477a2ee
Author: Simon Marchi <simon.marchi@efficios.com>
Date:   Fri Sep 29 14:24:38 2023 -0400

    gdb: remove target_gdbarch

Partially undoing it restores the build.

Tested on amd64-pc-solaris2.11, committed to master.

Btw., I'd considered reviving the Solaris buildbots to guard against
this kind of issues.  However, they'd both (sparcv9 and amd64) would
need to be build-only: the make check phase takes 3-5 times as long as
the build, there are about 2500 failures and quite a number of those are
flakey.  I have no idea if the new buildmaster allows for such a
compile-only configuration, though (the previous one did).

	Rainer

Comments

Simon Marchi Nov. 30, 2023, 4:29 p.m. UTC | #1 
On 11/30/23 04:54, Rainer Orth wrote:
> procfs.c doesn't currently compile on Solaris:
> 
> /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function ‘virtual int procfs_target::can_use_hw_breakpoint(bptype, int, int)’:
> /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3017:9: error: ‘ptr_type’ was not declared in this scope; did you mean ‘var_types’?
>  3017 |   type *ptr_type
>       |         ^~~~~~~~
>       |         var_types
> 
> This was caused by this patch:
> 
> commit 99d9c3b92ca96a7425cbb6b1bf453ede9477a2ee
> Author: Simon Marchi <simon.marchi@efficios.com>
> Date:   Fri Sep 29 14:24:38 2023 -0400
> 
>     gdb: remove target_gdbarch
> 
> Partially undoing it restores the build.
> 
> Tested on amd64-pc-solaris2.11, committed to master.
> 
> Btw., I'd considered reviving the Solaris buildbots to guard against
> this kind of issues.  However, they'd both (sparcv9 and amd64) would
> need to be build-only: the make check phase takes 3-5 times as long as
> the build, there are about 2500 failures and quite a number of those are
> flakey.  I have no idea if the new buildmaster allows for such a
> compile-only configuration, though (the previous one did).
> 
> 	Rainer

Thanks for catching and fixing this.

Having build-only builders would already be really great, I'm pretty
sure it's possible (CCing Mark Wielaard).

If you can identify a few simple and stable tests, it's possible to run
just those (I think that's what the buildbot does even for Linux/x86
today).  It would at least help ensure that GDB is not completely
broken.

Simon
Rainer Orth Dec. 1, 2023, 10:09 a.m. UTC | #2 
Hi Simon,

>> Btw., I'd considered reviving the Solaris buildbots to guard against
>> this kind of issues.  However, they'd both (sparcv9 and amd64) would
>> need to be build-only: the make check phase takes 3-5 times as long as
>> the build, there are about 2500 failures and quite a number of those are
>> flakey.  I have no idea if the new buildmaster allows for such a
>> compile-only configuration, though (the previous one did).

> Having build-only builders would already be really great, I'm pretty
> sure it's possible (CCing Mark Wielaard).

I think I checked when the new buildmaster went first online, but
couldn't find anything at the time.  I've now rechecked the new config
and indeed there are quite a number of build-only configs in use.

> If you can identify a few simple and stable tests, it's possible to run
> just those (I think that's what the buildbot does even for Linux/x86
> today).  It would at least help ensure that GDB is not completely
> broken.

Seems like a good compromise between a pure build-only config and one
that runs the full testsuite, but drowns us in noise from timeouts and
flakiness.   I'll have a look.

Thanks.
	Rainer
Mark Wielaard Dec. 10, 2023, 11:07 p.m. UTC | #3 
Hi Rainer,

On Fri, Dec 01, 2023 at 11:09:36AM +0100, Rainer Orth wrote:
> >> Btw., I'd considered reviving the Solaris buildbots to guard against
> >> this kind of issues.  However, they'd both (sparcv9 and amd64) would
> >> need to be build-only: the make check phase takes 3-5 times as long as
> >> the build, there are about 2500 failures and quite a number of those are
> >> flakey.  I have no idea if the new buildmaster allows for such a
> >> compile-only configuration, though (the previous one did).
> 
> > Having build-only builders would already be really great, I'm pretty
> > sure it's possible (CCing Mark Wielaard).
> 
> I think I checked when the new buildmaster went first online, but
> couldn't find anything at the time.  I've now rechecked the new config
> and indeed there are quite a number of build-only configs in use.

We do have workers for different architectures, but they are all
GNU/Linux. If you have a Solaris worker that can be used then please
contact https://sourceware.org/mailman/listinfo/buildbot

> > If you can identify a few simple and stable tests, it's possible to run
> > just those (I think that's what the buildbot does even for Linux/x86
> > today).  It would at least help ensure that GDB is not completely
> > broken.
> 
> Seems like a good compromise between a pure build-only config and one
> that runs the full testsuite, but drowns us in noise from timeouts and
> flakiness.   I'll have a look.

Currently the list of tests run for gdb is fairly small, but they are
all must succeed tests (they are run under native, gdbserver and
extended-gdbserver):
https://sourceware.org/cgit/builder/tree/builder/master.cfg#n2883

Cheers,

Mark
Rainer Orth Dec. 11, 2023, 2:40 p.m. UTC | #4 
Hi Mark,

> On Fri, Dec 01, 2023 at 11:09:36AM +0100, Rainer Orth wrote:
>> >> Btw., I'd considered reviving the Solaris buildbots to guard against
>> >> this kind of issues.  However, they'd both (sparcv9 and amd64) would
>> >> need to be build-only: the make check phase takes 3-5 times as long as
>> >> the build, there are about 2500 failures and quite a number of those are
>> >> flakey.  I have no idea if the new buildmaster allows for such a
>> >> compile-only configuration, though (the previous one did).
>> 
>> > Having build-only builders would already be really great, I'm pretty
>> > sure it's possible (CCing Mark Wielaard).
>> 
>> I think I checked when the new buildmaster went first online, but
>> couldn't find anything at the time.  I've now rechecked the new config
>> and indeed there are quite a number of build-only configs in use.
>
> We do have workers for different architectures, but they are all
> GNU/Linux. If you have a Solaris worker that can be used then please
> contact https://sourceware.org/mailman/listinfo/buildbot

I do: both systems (Solaris 11.4/SPARC and Solaris 11.4/amd64) used to
run compile-only buildbots with the previous buildmaster.

They are currently used for LLVM (sparcv9, amd64) and Golang (amd64)
buildbots, but have some free capacity.

>> > If you can identify a few simple and stable tests, it's possible to run
>> > just those (I think that's what the buildbot does even for Linux/x86
>> > today).  It would at least help ensure that GDB is not completely
>> > broken.
>> 
>> Seems like a good compromise between a pure build-only config and one
>> that runs the full testsuite, but drowns us in noise from timeouts and
>> flakiness.   I'll have a look.
>
> Currently the list of tests run for gdb is fairly small, but they are
> all must succeed tests (they are run under native, gdbserver and
> extended-gdbserver):
> https://sourceware.org/cgit/builder/tree/builder/master.cfg#n2883

I'll check if those work reliably.  In the worst case, the Solaris bots
would have to become compile-only, so at least guarding against build
failures.  However, I'm uncertain about gdbserver: I don't even know if
it compiles on Solaris, let alone does anything useful.

	Rainer
Mark Wielaard Dec. 12, 2023, 9:40 a.m. UTC | #5 
Hi Rainer,

On Mon, Dec 11, 2023 at 03:40:20PM +0100, Rainer Orth wrote:
> > On Fri, Dec 01, 2023 at 11:09:36AM +0100, Rainer Orth wrote:
> >> >> Btw., I'd considered reviving the Solaris buildbots to guard against
> >> >> this kind of issues.  However, they'd both (sparcv9 and amd64) would
> >> >> need to be build-only: the make check phase takes 3-5 times as long as
> >> >> the build, there are about 2500 failures and quite a number of those are
> >> >> flakey.  I have no idea if the new buildmaster allows for such a
> >> >> compile-only configuration, though (the previous one did).
> >> 
> >> > Having build-only builders would already be really great, I'm pretty
> >> > sure it's possible (CCing Mark Wielaard).
> >> 
> >> I think I checked when the new buildmaster went first online, but
> >> couldn't find anything at the time.  I've now rechecked the new config
> >> and indeed there are quite a number of build-only configs in use.
> >
> > We do have workers for different architectures, but they are all
> > GNU/Linux. If you have a Solaris worker that can be used then please
> > contact https://sourceware.org/mailman/listinfo/buildbot
> 
> I do: both systems (Solaris 11.4/SPARC and Solaris 11.4/amd64) used to
> run compile-only buildbots with the previous buildmaster.
> 
> They are currently used for LLVM (sparcv9, amd64) and Golang (amd64)
> buildbots, but have some free capacity.

Lets discuss on the buildbot mailinglist how we can hook those up if
you want to.

> >> > If you can identify a few simple and stable tests, it's possible to run
> >> > just those (I think that's what the buildbot does even for Linux/x86
> >> > today).  It would at least help ensure that GDB is not completely
> >> > broken.
> >> 
> >> Seems like a good compromise between a pure build-only config and one
> >> that runs the full testsuite, but drowns us in noise from timeouts and
> >> flakiness.   I'll have a look.
> >
> > Currently the list of tests run for gdb is fairly small, but they are
> > all must succeed tests (they are run under native, gdbserver and
> > extended-gdbserver):
> > https://sourceware.org/cgit/builder/tree/builder/master.cfg#n2883
> 
> I'll check if those work reliably.  In the worst case, the Solaris bots
> would have to become compile-only, so at least guarding against build
> failures.  However, I'm uncertain about gdbserver: I don't even know if
> it compiles on Solaris, let alone does anything useful.

We can be very flexible in what we build/test. It doesn't need to be
the same set of tests, we can remove gdbserver build/tests for
Solaris, etc. We can do builds on every commit, collapse builds for
the last set of commit or just once a day.

Cheers,

Mark
Rainer Orth Dec. 13, 2023, 9:15 a.m. UTC | #6 
Hi Mark,

>> > We do have workers for different architectures, but they are all
>> > GNU/Linux. If you have a Solaris worker that can be used then please
>> > contact https://sourceware.org/mailman/listinfo/buildbot
>> 
>> I do: both systems (Solaris 11.4/SPARC and Solaris 11.4/amd64) used to
>> run compile-only buildbots with the previous buildmaster.
>> 
>> They are currently used for LLVM (sparcv9, amd64) and Golang (amd64)
>> buildbots, but have some free capacity.
>
> Lets discuss on the buildbot mailinglist how we can hook those up if
> you want to.

certainly.  Being pretty busy right now, I'll most like have to postpone
this to early next year.

>> >> > If you can identify a few simple and stable tests, it's possible to run
>> >> > just those (I think that's what the buildbot does even for Linux/x86
>> >> > today).  It would at least help ensure that GDB is not completely
>> >> > broken.
>> >> 
>> >> Seems like a good compromise between a pure build-only config and one
>> >> that runs the full testsuite, but drowns us in noise from timeouts and
>> >> flakiness.   I'll have a look.
>> >
>> > Currently the list of tests run for gdb is fairly small, but they are
>> > all must succeed tests (they are run under native, gdbserver and
>> > extended-gdbserver):
>> > https://sourceware.org/cgit/builder/tree/builder/master.cfg#n2883
>> 
>> I'll check if those work reliably.  In the worst case, the Solaris bots
>> would have to become compile-only, so at least guarding against build
>> failures.  However, I'm uncertain about gdbserver: I don't even know if
>> it compiles on Solaris, let alone does anything useful.
>
> We can be very flexible in what we build/test. It doesn't need to be
> the same set of tests, we can remove gdbserver build/tests for
> Solaris, etc. We can do builds on every commit, collapse builds for
> the last set of commit or just once a day.

Excellent: so we can easily tune the worker to the machine's capacity.

I've meanwhile checked that set of gdb tests: most of them seem to PASS
reliably on Solaris, while a few FAIL while they should really be
UNSUPPORTED.  As I suspected, gdbserver never has been ported to
Solaris, so that set of tests will have to be omitted.

Thanks.
	Rainer
diff mbox series

Patch

diff --git a/gdb/procfs.c b/gdb/procfs.c
--- a/gdb/procfs.c
+++ b/gdb/procfs.c
@@ -3014,7 +3014,7 @@  procfs_target::can_use_hw_breakpoint (en
      procfs_address_to_host_pointer will reveal that an internal error
      will be generated when the host and target pointer sizes are
      different.  */
-  type *ptr_type
+  struct type *ptr_type
     = builtin_type (current_inferior ()->arch ())->builtin_data_ptr;
 
   if (sizeof (void *) != ptr_type->length ())