Re: Older gcc for MacOS

[Chris Johns]

On 20/1/2022 8:32 am, Joel Sherrill wrote:
> On Wed, Jan 19, 2022 at 3:00 PM Chris Johns  wrote:
>>
>> On 8/1/22 9:34 am, Joel Sherrill wrote:
>>> On Fri, Jan 7, 2022 at 4:17 PM Chris Johns  wrote:

 On 8/1/22 8:28 am, Ryan Long wrote:
> Hi,
>
> Our MacOS VM is failing to build several of the tools on the RTEMS 5 
> branch. We
> think that using an older version of gcc should get all of the tools to 
> build. I
> tried build gcc-4.8 with the RSB, but I get the following error.
>
>
> tester@VM-MacOS bare % ../source-builder/sb-set-builder
> --prefix=${HOME}/rtems-cron-5/tools/gcc-48 gnu-tools-4.8.2
> RTEMS Source Builder - Set Builder, 5 (6225eadda1de modified)
> Build Set: gnu-tools-4.8.2
> error: gnu-tools-4.8.2:24: cannot find file: devel/gcc-4.8.2-newlib-cvs-1
> Build Set: Time 0:00:00.000607
> Build FAILED
>
>
> Does anyone know how to get these tools to build?
>

 It looks like the recipe has rotted.
>>>
>>> Was there a native gcc recipe? The name includes newlib which would
>>> imply it is intended for use with RTEMS.
>>
>> The `bare/config` tree had recipes to build bare metal tool chains.
>>
>>> Also clearly old with cvs in the name.
>>>
>>> Having the ability to build an older gcc would ease the burden of
>>> using 5 on newer FreeBSD, Linux, etc with stricter compilers. As
>>> with everything, doing it with the RSB gives us control.
>>
>> Yes but do we want to head down that path?
> 
> What's the alternative? Updating the tools on older branches?

I do not fully understand the reason to build these old and now rotted gcc 
versions?

> The host environments and the released RTEMS versionN build requirements
> are two different sets which should overlap nicely at a point at time but
> as OSes update and the RTEMS build requirements stay fixed, things go
> downhill.

Yes and Apple have been aggressive in pushing users forward and that is not 
helping.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: NTP client recommendation for RTEMS?

[Chris Johns]

On 24/2/2022 2:03 am, Sebastian Huber wrote:
> On 22/02/2022 21:25, Joel Sherrill wrote:
>> On Tue, Feb 22, 2022, 1:45 PM Sebastian Huber
>> > > wrote:
>>
>>     On 22/02/2022 20:30, Joel Sherrill wrote:
>>  > On Tue, Feb 22, 2022 at 1:21 PM Sebastian Huber
>>  > >     >  wrote:
>>  >> On 22/02/2022 19:22, Joel Sherrill wrote:
>>  >>> Are you planning to get the NTP server side of the freebsd-org
>>     code working?
>>  >>>
>>  >>> Or get it building but not testing it?
>>  >>>
>>  >>> Or just focusing on building and testing JUST the client part.
>>  >> I ported the ntpd from FreeBSD to an older version of the
>>     libbsd. I only
>>  >> tested the client part and this seems to work fine after some
>>     basic tests.
>>  > OK. That matches what I expected. Is the libbsd version to old to
>>     merge
>>  > against? Any plans to merge this?
>>  >
>>  > Alternatively, is your work available to be used as the basis for
>>     updating
>>  > to 6-freebsd-12?
>>
>>     I have a very long TODO list. Actually, I started with the current
>>     6-freebsd-12 branch, but it didn't work, so in principle generating
>>     patches for this branch should be easy.
>>
>> Thanks. If we end up working on this, we will sync with you to help and avoid
>> duplicate work.
> 
> I pushed the NTP work to my github repository:
> 
> https://github.com/sebhub/rtems-libbsd/tree/6-freebsd-12-ntpd
> 
> I think we have to revert some changes done for the NFS support. 

Please do not. I would prefer the problem be discussed and understood first and
alternatives considered.

> For example, I don't know why the system call support for kqueue and the 
> sockets> moved to a separate file and was changed to use the FreeBSD file 
> descriptors.

The change lets us use FreeBSD fd support and after this work I think the change
is major improvement over the implementation I had to work with. Using RTEMS
direct fd support in mixed ways with VFS in LibBSD would only make things 
confusing.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] GDB: Prefer Python 3 over 2

[Chris Johns]

On 19/3/2022 8:33 pm, Sebastian Huber wrote:
> On 18/03/2022 22:56, Chris Johns wrote:
>>
>>> On 19 Mar 2022, at 2:40 am, Sebastian Huber
>>>  wrote:
>>>
>>> On 17/03/2022 12:51, Sebastian Huber wrote:
 This fixes the build of a recent GDB version:
 gdb/python/py-micmd.c: In function 'int
 micmdpy_uninstall_command(micmdpy_object*)':
 gdb/python/py-micmd.c:430:20: error: 'PyDict_GetItemWithError' was not
 declared in this scope
     PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (),
  ^~~
>>
>> Has a bug report been raised with gdb?
> 
> The Python 2 EOL was January 1, 2020. This code was added by:
> 
> commit 740b42ceb7c7ae7b5343183782973576a93bc7b3
> Author: Andrew Burgess 
> Date:   Tue Jun 23 14:45:38 2020 +0100
> 
>     gdb/python/mi: create MI commands using python
> 
> It is not a bug from my point of view.

The change has been reviewed again ...

commit 5ec0444e8312c17e628739ebd7b8f0e29df3c9e9
Author: Andrew Burgess 
Date:   Fri Mar 18 15:55:34 2022 +

gdb: supply PyDict_GetItemWithError when compiling with Python2

Commit

  commit 740b42ceb7c7ae7b5343183782973576a93bc7b3
  Date:   Tue Jun 23 14:45:38 2020 +0100

  gdb/python/mi: create MI commands using python

Introduced a use of PyDict_GetItemWithError, which is not available in
Python2, and so the Python2 build was broken.

This commit provides a work around for this:

  #define PyDict_GetItemWithError PyDict_GetItem

The arguments passed to these calls are identical, the difference is
that the WithError version will return with an exception raised in
some error cases, while the PyDict_GetItem suppresses some errors, and
just returns nullptr.

Given that we are almost at the GDB 12 branch point, this commit is
the easiest change to get the Python2 build working again.  After GDB
12 branches the plan is to remove Python2 support, so this #define
will be removed anyway.

As far as functionality I think this #define will be fine.  In the
"normal" no error case, then obviously, everything will be fine.  The
only difference is what happens when an error occurs.

The only errors I think could happen if Python runs into problems
hashing the string, or comparing the strings for equality.  Given the
limited strings we're working with I don't expect that this should
occur during normal operation.  So, my expectation is that this should
only happen if they user has gone and messed around with this hash in
some way - in which case I think it's OK if weird things happen.

This issue was discussed on IRC, and I think Simon might be working on
an alternative patch to remove the _mi_commands dictionary from the
gdb module, in which case the use of PyDict_GetItemWithError will be
removed completely.  I'm posting this just in case people want to
consider a minimal work around for the breakage in the short term.

>>> I was able to build the latest GDB with this patch. Otherwise all
>>> architectures failed with the above error.
>>
>> Has gdb dropped Python 2 support?
> 
> It seems so.

It seems from above is after gdb 12 has branched. We could settle on gdb 12 for
rtems6?

>>
>> What happens on a host without python3 installed? Does the error appear? Does
>> this in effect force RTEMS to drop the Python2 requirement for rtems6?
> 
> I guess if we want to use the next GDB release, then Python 3 is required.
> 

Then this changes rtems6 because it forces a major change I had not expected on
to rtems6. I suggest a separate thread be started to again consider removing
python 2 support for rtems6. It do not bother me but we have some users where is
may so it is best to ask openly.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] GDB: Prefer Python 3 over 2

[Sebastian Huber]

On 20/03/2022 23:22, Chris Johns wrote:

On 19/3/2022 8:33 pm, Sebastian Huber wrote:

On 18/03/2022 22:56, Chris Johns wrote:



On 19 Mar 2022, at 2:40 am, Sebastian Huber
 wrote:

On 17/03/2022 12:51, Sebastian Huber wrote:

This fixes the build of a recent GDB version:
gdb/python/py-micmd.c: In function 'int
micmdpy_uninstall_command(micmdpy_object*)':
gdb/python/py-micmd.c:430:20: error: 'PyDict_GetItemWithError' was not
declared in this scope
     PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (),
  ^~~


Has a bug report been raised with gdb?


The Python 2 EOL was January 1, 2020. This code was added by:

commit 740b42ceb7c7ae7b5343183782973576a93bc7b3
Author: Andrew Burgess 
Date:   Tue Jun 23 14:45:38 2020 +0100

     gdb/python/mi: create MI commands using python

It is not a bug from my point of view.


The change has been reviewed again ...

commit 5ec0444e8312c17e628739ebd7b8f0e29df3c9e9
Author: Andrew Burgess 
Date:   Fri Mar 18 15:55:34 2022 +

 gdb: supply PyDict_GetItemWithError when compiling with Python2


Good timing.

I still think the patch to prefer the Python 3 installation of the 
Python 2 installation makes sense. We will have this issue again if I 
want to build the GDB main branch some time in the future.





I was able to build the latest GDB with this patch. Otherwise all
architectures failed with the above error.


Has gdb dropped Python 2 support?


It seems so.


It seems from above is after gdb 12 has branched. We could settle on gdb 12 for
rtems6?


Given that GDB 12 isn't released yet this doesn't sound like a constraint.





What happens on a host without python3 installed? Does the error appear? Does
this in effect force RTEMS to drop the Python2 requirement for rtems6?


I guess if we want to use the next GDB release, then Python 3 is required.



Then this changes rtems6 because it forces a major change I had not expected on
to rtems6. I suggest a separate thread be started to again consider removing
python 2 support for rtems6. It do not bother me but we have some users where is
may so it is best to ask openly.


Yes, this makes sense.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] GDB: Prefer Python 3 over 2

[Chris Johns]

On 21/3/2022 5:54 pm, Sebastian Huber wrote:
> On 20/03/2022 23:22, Chris Johns wrote:
>> On 19/3/2022 8:33 pm, Sebastian Huber wrote:
>>> On 18/03/2022 22:56, Chris Johns wrote:

> On 19 Mar 2022, at 2:40 am, Sebastian Huber
>  wrote:
>
> On 17/03/2022 12:51, Sebastian Huber wrote:
>> This fixes the build of a recent GDB version:
>> gdb/python/py-micmd.c: In function 'int
>> micmdpy_uninstall_command(micmdpy_object*)':
>> gdb/python/py-micmd.c:430:20: error: 'PyDict_GetItemWithError' was not
>> declared in this scope
>>  PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (),
>>   ^~~

 Has a bug report been raised with gdb?
>>>
>>> The Python 2 EOL was January 1, 2020. This code was added by:
>>>
>>> commit 740b42ceb7c7ae7b5343183782973576a93bc7b3
>>> Author: Andrew Burgess 
>>> Date:   Tue Jun 23 14:45:38 2020 +0100
>>>
>>>  gdb/python/mi: create MI commands using python
>>>
>>> It is not a bug from my point of view.
>>
>> The change has been reviewed again ...
>>
>> commit 5ec0444e8312c17e628739ebd7b8f0e29df3c9e9
>> Author: Andrew Burgess 
>> Date:   Fri Mar 18 15:55:34 2022 +
>>
>>  gdb: supply PyDict_GetItemWithError when compiling with Python2
> 
> Good timing.
> 
> I still think the patch to prefer the Python 3 installation of the Python 2
> installation makes sense. We will have this issue again if I want to build the
> GDB main branch some time in the future.

Yeah I think this is sensible. If we can still build python2 then I am OK with
this change.

> I was able to build the latest GDB with this patch. Otherwise all
> architectures failed with the above error.

 Has gdb dropped Python 2 support?
>>>
>>> It seems so.
>>
>> It seems from above is after gdb 12 has branched. We could settle on gdb 12 
>> for
>> rtems6?
> 
> Given that GDB 12 isn't released yet this doesn't sound like a constraint.
> 

Great. We need to get the tools back to released source for the rtems6 release
so we should track this and then switch.

 What happens on a host without python3 installed? Does the error appear? 
 Does
 this in effect force RTEMS to drop the Python2 requirement for rtems6?
>>>
>>> I guess if we want to use the next GDB release, then Python 3 is required.
>>>
>>
>> Then this changes rtems6 because it forces a major change I had not expected 
>> on
>> to rtems6. I suggest a separate thread be started to again consider removing
>> python 2 support for rtems6. It do not bother me but we have some users 
>> where is
>> may so it is best to ask openly.
> 
> Yes, this makes sense.

Great

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] shell: Avoid potential stack corruption

[Chris Johns]

On 19/3/2022 8:29 pm, Sebastian Huber wrote:
> On 19/03/2022 08:31, Chris Johns wrote:
>>> On 15 Mar 2022, at 5:27 pm, Sebastian
>>> Huber  wrote:
>>>
>>> The rtems_shell_init() passed the address of a stack variable
>>> (exit_code) to rtems_shell_run().  If wait == false, then the stack
>>> variable goes out of scope but may be accessed by the created shell
>>> thread.
>>>
>>> The rtems_shell_script() was affected by the same problem.
>>>
>>> Close #4629.
>> Does this change remove the exit code?
> 
> No, the exit code member is still in the shell environment.
> 

Great. I was reviewing the change on my phone while walking somewhere.

Then the change is fine.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: NTP client recommendation for RTEMS?

[Sebastian Huber]

On 20/03/2022 23:08, Chris Johns wrote:

On 24/2/2022 2:03 am, Sebastian Huber wrote:

On 22/02/2022 21:25, Joel Sherrill wrote:

On Tue, Feb 22, 2022, 1:45 PM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>> wrote:

     On 22/02/2022 20:30, Joel Sherrill wrote:
  > On Tue, Feb 22, 2022 at 1:21 PM Sebastian Huber
  > mailto:sebastian.hu...@embedded-brains.de>>  wrote:
  >> On 22/02/2022 19:22, Joel Sherrill wrote:
  >>> Are you planning to get the NTP server side of the freebsd-org
     code working?
  >>>
  >>> Or get it building but not testing it?
  >>>
  >>> Or just focusing on building and testing JUST the client part.
  >> I ported the ntpd from FreeBSD to an older version of the
     libbsd. I only
  >> tested the client part and this seems to work fine after some
     basic tests.
  > OK. That matches what I expected. Is the libbsd version to old to
     merge
  > against? Any plans to merge this?
  >
  > Alternatively, is your work available to be used as the basis for
     updating
  > to 6-freebsd-12?

     I have a very long TODO list. Actually, I started with the current
     6-freebsd-12 branch, but it didn't work, so in principle generating
     patches for this branch should be easy.

Thanks. If we end up working on this, we will sync with you to help and avoid
duplicate work.


I pushed the NTP work to my github repository:

https://github.com/sebhub/rtems-libbsd/tree/6-freebsd-12-ntpd

I think we have to revert some changes done for the NFS support.


Please do not. I would prefer the problem be discussed and understood first and
alternatives considered.


Yes, I don't work this currently.




For example, I don't know why the system call support for kqueue and the 
sockets> moved to a separate file and was changed to use the FreeBSD file 
descriptors.


The change lets us use FreeBSD fd support and after this work I think the change
is major improvement over the implementation I had to work with. Using RTEMS
direct fd support in mixed ways with VFS in LibBSD would only make things 
confusing.


Using the FreeBSD file descriptors for the FreeBSD file system support 
makes sense. I don't understand why this is required for the kqueue and 
sockets support. It just adds a runtime, memory, and code overhead. You 
need this RTEMS file descriptor to FreeBSD file descriptor mapping in 
every send() and recv() call. Not everyone is using libbsd with the NFS 
client. What is the hard reason for having the FreeBSD file descriptors 
for kqueue and socket?


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel