Re: [PATCHv2 2/3] gdb: introduce program_space::get_entry_point_info function

[Pedro Alves <pedro@palves.net>]

Hi!

On 2026-06-15 11:29, Andrew Burgess wrote:
> Pedro Alves <pedro@palves.net> writes:
> 
>> On 2026-06-11 22:59, Andrew Burgess wrote:
>>> +    # Only svr4 targets currently support querying the inferior entry
>>> +    # address.
>>> +    if {[istarget *-linux*]} {
>>
>> There are more svr4 targets than linux.  I think this style of allow-list has
>> a good chance of never getting updated.  Deny-lists are better, IMHO.  If the
>> test fails on some port, that might trigger someone to add the feature
>> there.
> 
> Hey Pedro,
> 
> I'm still looking at your other feedback, but before I start making this
> specific change, I just wanted to clarify how you see this as being
> different from what I have right now.
> 
> If I write this as a deny list, e.g.
> 
>  if { ![istarget ....] && ![istarget ....] } {
>    # Run tests.
>  }
> 
> Is there not the same problem?  We rely on someone realising that the
> reason the test isn't run on their target is some missing GDB
> functionality, and them adding the functionality and removing the
> `istarget` block for their target.


Speaking from principles, and not this particular case:

The difference is that there was a failure that made someone see that
some functionality is missing.  With the allow-list, nobody ever notices it.

With a target-based allow-list, even if someone adds some functionality
to a port, it's typical to not comb through the testsuite and
relax the relevant allow-lists to also allow their targets.  

And even if they want to, there's no easy marker to grep for.  E.g, say I
implement feature X on Windows, then how do I know that I need to
grep for "istarget Y" to find all the tests that I need to adjust?
And which Y?  And then which ones that hit my grep should I look at?

I'll give you one example, in gdb.threads/watchpoint-fork.exp:

 # Only GNU/Linux is known to support `set follow-fork-mode child'.
 if {[istarget "*-*-linux*"]} {
     test child FOLLOW_CHILD
 } else {
     untested "${testfile}: child"
 }

I think at least FreeBSD has supported that for over a decade.

> 
> Another option would be for me to just not add any test skipping right
> now.  I know this will lead to the test failing for some targets as the
> new feature is only implemented for svr4 targets.  Then, if someone on a
> failing target cares, they can add the missing feature.  This approach
> feels a bit mean, I don't like adding failing tests for others, but it
> does draw attention to the problem.

I think the best would be to just add a reasonable deny-list from
the get go.  I suspect this is going to be a good enough starting point:

proc supports_process_entry_point {} {
   if windows || darwin
     return 0

   if is_svr4_target 
     return 1 # works even if remote, svr4 is handled on the host.

   if remote
     return 0 # no RSP packet that gets us the info

   # Assume yes.
   return 1
}

> 
> I wonder if a better approach would to stick with my allow list, but add
> an 'unsupported' call in the else block.  Maybe someone on e.g. Windows,
> will periodically look at tests that report 'unsupported' and see if
> there is anything that could be done?  If 'unsupported' is the wrong
> type then I can use whatever you prefer.

I don't think so.  In my experience, people ignore/miss PASS -> UNSUPPORTED
regressions, let alone looking for UNSUPPORTED results indicating tests
they should/could enable.  It is still good to issue an UNSUPPORTED, but
I wouldn't make that the discovery mechanism.

Pedro Alves

> 
> I agree with your feedback on svr4 being wider than just Linux, I'll add
> a helper function for `is_svr4_target` to lib/gdb.exp and then make use
> of that, the svr4 list can then be improved over time.
> 

> Thanks,
> Andrew
>