In message <576E69AA.4090201@aaug.net>
John Tytgat <John.Tytgat@aaug.net> wrote:
>It's roughly two years ago I last contributed to AsAsm so I'm not 100%
>sure any more about all following details.
>
>The idea of AsAsm is to be compatible with ROOL's ObjAsm (incl. command
>line options) and on top of that not only support AOF but also the ELF
>file format. That also means following what ARM adds as functionality
>to their assembler. So that's why at some point the -cpu/-fpu options
>appeared and the -soft-float one got dropped.
>
>It is (was) work in progress. For how things are to be implemented in
>the ELF file format I followed what ARM defined in their public EABI/ELF
>documents. Those -cpu/-fpu options are, partly, defining the EABI
>flavour needs to be written, including the EABI object attributes. That
>hasn't happened, hence, I believe we're now writing a pre-EABI ELF
>format which is rightfully considered hard-float by the binutils linker.
>
>By just defining ELF_EABI at build time you fall by default in the
>soft-float case (but also claim to be EABI compliant which I'm not sure
>if that's really true) but the real way forward is to write proper EABI
>object attributes based on command line options and attributes specified
>in the assembler source.
>
>Personally I find it pity that I ran out of steam doing all this,
>hopefully someone can pick up this project. I'm happy to give advice if
>wanted. If the RISC OS developer community wants to leverage on the
>existing free/open compiler/linker tools (gcc, llvm ecosystem, binutils,
>etc.) for RISC OS, as OS, development, this realistic rules out AOF and
>only leaves ELF file format. And then AsAsm is important piece in that
>puzzle. Or alternatively have to teach non-free/open ObjAsm to output
>ELF + DWARF and then also support ELF fully in the link linker...
Thanks for filling in the background, John. It explains the symptoms
I saw.
I think it's most unlikely that I could contribute - I'm not a good
enough programmer, certainly from the POV of reading other people's
code and understanding what needs to be done, on a large project
such as this, so I have to hope that someone cleverer than me can
do so.
Anyway, having discussed it and understood more: I guess the right
thing for me to do now is put in a bug report so it can be tracked?
Dave
____________________________________________________________
Send any screenshot to your friends in seconds...
Works in all emails, instant messengers, blogs, forums and social networks.
TRY IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if2 for FREE
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Sunday, 26 June 2016
Saturday, 25 June 2016
Re: [gccsdk] asasm always claims to want hardware FP
On 06/23/2016 04:23 PM, Dave Higton wrote:
> There seems to be a problem with asasm of gcc 4.7.4. See the ROOL
> Community Support forum, topic "DeskLib and GCC 4.7.4" for details.
>
> In short, even the most trivial code assembled with asasm 2.01 r6919
> results in an ELF file that claims to use hardware FP (even though
> there is no FP in the code at all), and I haven't found it possible
> to influence this. r5871 accepted a command line option -soft-float
> that r6919 doesn't. r6919 accepts an option -fpu= but none of the
> 53 options available causes it to change its behaviour.
It's roughly two years ago I last contributed to AsAsm so I'm not 100%
sure any more about all following details.
The idea of AsAsm is to be compatible with ROOL's ObjAsm (incl. command
line options) and on top of that not only support AOF but also the ELF
file format. That also means following what ARM adds as functionality
to their assembler. So that's why at some point the -cpu/-fpu options
appeared and the -soft-float one got dropped.
It is (was) work in progress. For how things are to be implemented in
the ELF file format I followed what ARM defined in their public EABI/ELF
documents. Those -cpu/-fpu options are, partly, defining the EABI
flavour needs to be written, including the EABI object attributes. That
hasn't happened, hence, I believe we're now writing a pre-EABI ELF
format which is rightfully considered hard-float by the binutils linker.
By just defining ELF_EABI at build time you fall by default in the
soft-float case (but also claim to be EABI compliant which I'm not sure
if that's really true) but the real way forward is to write proper EABI
object attributes based on command line options and attributes specified
in the assembler source.
Personally I find it pity that I ran out of steam doing all this,
hopefully someone can pick up this project. I'm happy to give advice if
wanted. If the RISC OS developer community wants to leverage on the
existing free/open compiler/linker tools (gcc, llvm ecosystem, binutils,
etc.) for RISC OS, as OS, development, this realistic rules out AOF and
only leaves ELF file format. And then AsAsm is important piece in that
puzzle. Or alternatively have to teach non-free/open ObjAsm to output
ELF + DWARF and then also support ELF fully in the link linker...
John.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> There seems to be a problem with asasm of gcc 4.7.4. See the ROOL
> Community Support forum, topic "DeskLib and GCC 4.7.4" for details.
>
> In short, even the most trivial code assembled with asasm 2.01 r6919
> results in an ELF file that claims to use hardware FP (even though
> there is no FP in the code at all), and I haven't found it possible
> to influence this. r5871 accepted a command line option -soft-float
> that r6919 doesn't. r6919 accepts an option -fpu= but none of the
> 53 options available causes it to change its behaviour.
It's roughly two years ago I last contributed to AsAsm so I'm not 100%
sure any more about all following details.
The idea of AsAsm is to be compatible with ROOL's ObjAsm (incl. command
line options) and on top of that not only support AOF but also the ELF
file format. That also means following what ARM adds as functionality
to their assembler. So that's why at some point the -cpu/-fpu options
appeared and the -soft-float one got dropped.
It is (was) work in progress. For how things are to be implemented in
the ELF file format I followed what ARM defined in their public EABI/ELF
documents. Those -cpu/-fpu options are, partly, defining the EABI
flavour needs to be written, including the EABI object attributes. That
hasn't happened, hence, I believe we're now writing a pre-EABI ELF
format which is rightfully considered hard-float by the binutils linker.
By just defining ELF_EABI at build time you fall by default in the
soft-float case (but also claim to be EABI compliant which I'm not sure
if that's really true) but the real way forward is to write proper EABI
object attributes based on command line options and attributes specified
in the assembler source.
Personally I find it pity that I ran out of steam doing all this,
hopefully someone can pick up this project. I'm happy to give advice if
wanted. If the RISC OS developer community wants to leverage on the
existing free/open compiler/linker tools (gcc, llvm ecosystem, binutils,
etc.) for RISC OS, as OS, development, this realistic rules out AOF and
only leaves ELF file format. And then AsAsm is important piece in that
puzzle. Or alternatively have to teach non-free/open ObjAsm to output
ELF + DWARF and then also support ELF fully in the link linker...
John.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] asasm always claims to want hardware FP
On Fri, 24 Jun 2016 23:00:43 +0100, Theo Markettos <theo@markettos.org.uk> wrote:
> Possibly
> -apcs nofp/softfp
>
> since the default is:
> 3/noropi/norwpi/32bit/swstackcheck/fp/nointerwork/hardfp
> I think you need to flip the 'fp' and 'hardfp' parts of that.
Just to avoid any confusion, the APCS options /fp and /nofp are nothing to
do with floating point - they're talking about whether functions use r11 as
a frame pointer register.
Ben
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Possibly
> -apcs nofp/softfp
>
> since the default is:
> 3/noropi/norwpi/32bit/swstackcheck/fp/nointerwork/hardfp
> I think you need to flip the 'fp' and 'hardfp' parts of that.
Just to avoid any confusion, the APCS options /fp and /nofp are nothing to
do with floating point - they're talking about whether functions use r11 as
a frame pointer register.
Ben
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Friday, 24 June 2016
Re: [gccsdk] [Bug 263] New: Set Alias$command containing |M in generated !Run files causes trouble for string comparison
In message <bug-263-73@http.www.riscos.info/bugzilla3/>
bugzilla-daemon@riscos.info wrote:
> http://www.riscos.info/bugzilla3/show_bug.cgi?id=263
>
> Summary: Set Alias$command containing |M in generated !Run
> files causes trouble for string comparison
> Product: GCC/GCCSDK
> Version: other
> Platform: Other
> OS/Version: RISC OS
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Porting Scripts and Packaging
> AssignedTo: gccsdk-bugzilla@markettos.org.uk
> ReportedBy: bugzilla@markettos.org.uk
> Estimated Hours: 0.0
>
>
> Carlos Michael Santillan writes:
>
> I found a problem with some packages at riscos.info. I use the
> Vorbis-Tools for my little application OggTag. It looks that a lot of
> the command line programms at riscos.info has this problem.
>
>
> In Vorbis-Tools !Boot is the command
>
> Set Alias$vorbiscomment WimpSlot -min 686k |M Run
> <Vorbis-Tools$Dir>.vorbiscomment %%*0
>
> In !Run of OggTag I wanted to check for vorbiscomment with
>
> If "<Alias$vorbiscomment>" = "" Then Error OggTag requires the
> Vorbis-Tools
>
Why? you can check for the existance of the (simple) variable Vorbis-Tools$Dir or use
IfThere <Vorbis-Tools$Dir>.vorbiscomment Then Else Error OggTag requires the Vorbis-Tools
That would show that that directory has been booted, and that vorbiscomment exists.
BTW, checking for the existance of the alias, is still no guarantee that it is set up to work correctly, just that it exists, so no improvement really.
I appreciate your enthusiasm for tackling the obey language though.
Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
bugzilla-daemon@riscos.info wrote:
> http://www.riscos.info/bugzilla3/show_bug.cgi?id=263
>
> Summary: Set Alias$command containing |M in generated !Run
> files causes trouble for string comparison
> Product: GCC/GCCSDK
> Version: other
> Platform: Other
> OS/Version: RISC OS
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Porting Scripts and Packaging
> AssignedTo: gccsdk-bugzilla@markettos.org.uk
> ReportedBy: bugzilla@markettos.org.uk
> Estimated Hours: 0.0
>
>
> Carlos Michael Santillan writes:
>
> I found a problem with some packages at riscos.info. I use the
> Vorbis-Tools for my little application OggTag. It looks that a lot of
> the command line programms at riscos.info has this problem.
>
>
> In Vorbis-Tools !Boot is the command
>
> Set Alias$vorbiscomment WimpSlot -min 686k |M Run
> <Vorbis-Tools$Dir>.vorbiscomment %%*0
>
> In !Run of OggTag I wanted to check for vorbiscomment with
>
> If "<Alias$vorbiscomment>" = "" Then Error OggTag requires the
> Vorbis-Tools
>
Why? you can check for the existance of the (simple) variable Vorbis-Tools$Dir or use
IfThere <Vorbis-Tools$Dir>.vorbiscomment Then Else Error OggTag requires the Vorbis-Tools
That would show that that directory has been booted, and that vorbiscomment exists.
BTW, checking for the existance of the alias, is still no guarantee that it is set up to work correctly, just that it exists, so no improvement really.
I appreciate your enthusiasm for tackling the obey language though.
Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] asasm always claims to want hardware FP
On Thu, Jun 23, 2016 at 03:23:44PM +0100, Dave Higton wrote:
> In short, even the most trivial code assembled with asasm 2.01 r6919
> results in an ELF file that claims to use hardware FP (even though
> there is no FP in the code at all), and I haven't found it possible
> to influence this. r5871 accepted a command line option -soft-float
> that r6919 doesn't. r6919 accepts an option -fpu= but none of the
> 53 options available causes it to change its behaviour.
In the absence of anyone more knowledgeable chipping in, I think you might
want an -apcs flag.
The table of options is here:
http://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Ftools%2Fasasm%2Fsrc%2Fmain.c
Possibly
-apcs nofp/softfp
since the default is:
3/noropi/norwpi/32bit/swstackcheck/fp/nointerwork/hardfp
I think you need to flip the 'fp' and 'hardfp' parts of that.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> In short, even the most trivial code assembled with asasm 2.01 r6919
> results in an ELF file that claims to use hardware FP (even though
> there is no FP in the code at all), and I haven't found it possible
> to influence this. r5871 accepted a command line option -soft-float
> that r6919 doesn't. r6919 accepts an option -fpu= but none of the
> 53 options available causes it to change its behaviour.
In the absence of anyone more knowledgeable chipping in, I think you might
want an -apcs flag.
The table of options is here:
http://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Ftools%2Fasasm%2Fsrc%2Fmain.c
Possibly
-apcs nofp/softfp
since the default is:
3/noropi/norwpi/32bit/swstackcheck/fp/nointerwork/hardfp
I think you need to flip the 'fp' and 'hardfp' parts of that.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] [Bug 183] Updated VNCServe
http://www.riscos.info/bugzilla3/show_bug.cgi?id=183
Theo Markettos <bugzilla@markettos.org.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |bugzilla@markettos.org.uk
Resolution| |FIXED
--- Comment #1 from Theo Markettos <bugzilla@markettos.org.uk> 2016-06-24 14:34:37 PDT ---
Jeffrey Lee has taken up maintenance, so I think VNCServe is well covered for
the time being.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Theo Markettos <bugzilla@markettos.org.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |bugzilla@markettos.org.uk
Resolution| |FIXED
--- Comment #1 from Theo Markettos <bugzilla@markettos.org.uk> 2016-06-24 14:34:37 PDT ---
Jeffrey Lee has taken up maintenance, so I think VNCServe is well covered for
the time being.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] [Bug 245] SWI &4C4152 not know
http://www.riscos.info/bugzilla3/show_bug.cgi?id=245
Theo Markettos <bugzilla@markettos.org.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
--- Comment #4 from Theo Markettos <bugzilla@markettos.org.uk> 2016-06-24 14:28:30 PDT ---
In the absence of any further info I'm closing this as a suspected emulator
bug. Happy to reopen if there's more details.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Theo Markettos <bugzilla@markettos.org.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
--- Comment #4 from Theo Markettos <bugzilla@markettos.org.uk> 2016-06-24 14:28:30 PDT ---
In the absence of any further info I'm closing this as a suspected emulator
bug. Happy to reopen if there's more details.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] [Bug 263] Set Alias$command containing |M in generated !Run files causes trouble for string comparison
http://www.riscos.info/bugzilla3/show_bug.cgi?id=263
--- Comment #1 from Theo Markettos <bugzilla@markettos.org.uk> 2016-06-24 14:18:17 PDT ---
Changing build-program to generate SetMacro instead of Set may fix it, but it
requires further testing.
This is mostly a placeholder so we don't forget about it.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
--- Comment #1 from Theo Markettos <bugzilla@markettos.org.uk> 2016-06-24 14:18:17 PDT ---
Changing build-program to generate SetMacro instead of Set may fix it, but it
requires further testing.
This is mostly a placeholder so we don't forget about it.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] [Bug 263] New: Set Alias$command containing |M in generated !Run files causes trouble for string comparison
http://www.riscos.info/bugzilla3/show_bug.cgi?id=263
Summary: Set Alias$command containing |M in generated !Run
files causes trouble for string comparison
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: Porting Scripts and Packaging
AssignedTo: gccsdk-bugzilla@markettos.org.uk
ReportedBy: bugzilla@markettos.org.uk
Estimated Hours: 0.0
Carlos Michael Santillan writes:
I found a problem with some packages at riscos.info. I use the
Vorbis-Tools for my little application OggTag. It looks that a lot of
the command line programms at riscos.info has this problem.
In Vorbis-Tools !Boot is the command
Set Alias$vorbiscomment WimpSlot -min 686k |M Run
<Vorbis-Tools$Dir>.vorbiscomment %%*0
In !Run of OggTag I wanted to check for vorbiscomment with
If "<Alias$vorbiscomment>" = "" Then Error OggTag requires the
Vorbis-Tools
With this command I get "String not recognised". The reason is the "|M"
in the Set Alias$... command of Vorbis-Tools. With the help of Thomas
Milius I found a way round the problem:
Unset vorbiscommentCmdLen
X SetEval vorbiscommentCmdLen LEN(Alias$vorbiscomment)
If "<vorbiscommentCmdLen>" = 0 Then Error OggTag requires Vorbis-Tools
Unset vorbiscommentCmdLen
But I think a better way is to change
Set Alias$vorbiscomment WimpSlot -min 686k |M Run
<Vorbis-Tools$Dir>.vorbiscomment %%*0
in Vorbis-Tools !Boot to
SetMacro Alias$vorbiscomment Set WimpSlot -min 686k |M Run
<Vorbis-Tools$Dir>.vorbiscomment %%*0
In !Boot are similar commands for the other Vorbis tools.
I hope you understand the Problem. If you have installed the
Vorbis-Tools try
If "<Alias$vorbiscomment>" = "" Then Error OggTag requires Vorbis-Tools
in a Taskwindow or if you have installed Curl
If "<Alias$curl>" = "" Then Error See the error
or GZip
If "<Alias$gzip>" = "" Then Error See the error
...
With Whois there is no problem with
If "<Alias$whois>" = "" Then Error See the problem
because there is no WimpSlot in the alias. But I think to set the
WimpSlot is a good idea.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Summary: Set Alias$command containing |M in generated !Run
files causes trouble for string comparison
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: Porting Scripts and Packaging
AssignedTo: gccsdk-bugzilla@markettos.org.uk
ReportedBy: bugzilla@markettos.org.uk
Estimated Hours: 0.0
Carlos Michael Santillan writes:
I found a problem with some packages at riscos.info. I use the
Vorbis-Tools for my little application OggTag. It looks that a lot of
the command line programms at riscos.info has this problem.
In Vorbis-Tools !Boot is the command
Set Alias$vorbiscomment WimpSlot -min 686k |M Run
<Vorbis-Tools$Dir>.vorbiscomment %%*0
In !Run of OggTag I wanted to check for vorbiscomment with
If "<Alias$vorbiscomment>" = "" Then Error OggTag requires the
Vorbis-Tools
With this command I get "String not recognised". The reason is the "|M"
in the Set Alias$... command of Vorbis-Tools. With the help of Thomas
Milius I found a way round the problem:
Unset vorbiscommentCmdLen
X SetEval vorbiscommentCmdLen LEN(Alias$vorbiscomment)
If "<vorbiscommentCmdLen>" = 0 Then Error OggTag requires Vorbis-Tools
Unset vorbiscommentCmdLen
But I think a better way is to change
Set Alias$vorbiscomment WimpSlot -min 686k |M Run
<Vorbis-Tools$Dir>.vorbiscomment %%*0
in Vorbis-Tools !Boot to
SetMacro Alias$vorbiscomment Set WimpSlot -min 686k |M Run
<Vorbis-Tools$Dir>.vorbiscomment %%*0
In !Boot are similar commands for the other Vorbis tools.
I hope you understand the Problem. If you have installed the
Vorbis-Tools try
If "<Alias$vorbiscomment>" = "" Then Error OggTag requires Vorbis-Tools
in a Taskwindow or if you have installed Curl
If "<Alias$curl>" = "" Then Error See the error
or GZip
If "<Alias$gzip>" = "" Then Error See the error
...
With Whois there is no problem with
If "<Alias$whois>" = "" Then Error See the problem
because there is no WimpSlot in the alias. But I think to set the
WimpSlot is a good idea.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Thursday, 23 June 2016
[gccsdk] asasm always claims to want hardware FP
There seems to be a problem with asasm of gcc 4.7.4. See the ROOL
Community Support forum, topic "DeskLib and GCC 4.7.4" for details.
In short, even the most trivial code assembled with asasm 2.01 r6919
results in an ELF file that claims to use hardware FP (even though
there is no FP in the code at all), and I haven't found it possible
to influence this. r5871 accepted a command line option -soft-float
that r6919 doesn't. r6919 accepts an option -fpu= but none of the
53 options available causes it to change its behaviour.
r6919 comes from a fresh install of !gcc, using PackMan, a couple
of weeks back. PackMan is still telling me that my installation
is up to date.
Dave
____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop!
Check it out at http://www.inbox.com/marineaquarium
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Community Support forum, topic "DeskLib and GCC 4.7.4" for details.
In short, even the most trivial code assembled with asasm 2.01 r6919
results in an ELF file that claims to use hardware FP (even though
there is no FP in the code at all), and I haven't found it possible
to influence this. r5871 accepted a command line option -soft-float
that r6919 doesn't. r6919 accepts an option -fpu= but none of the
53 options available causes it to change its behaviour.
r6919 comes from a fresh install of !gcc, using PackMan, a couple
of weeks back. PackMan is still telling me that my installation
is up to date.
Dave
____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop!
Check it out at http://www.inbox.com/marineaquarium
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Friday, 17 June 2016
Re: [Rpcemu] Simpler title bar
In article
<CAOnWdoi7ZrY5g0XmQ8hPExN66Wc5i9LgPgb18jzO0m8pvWqWRg@mail.gmail.com>,
Reuben Thomas <rrt@sc3d.org> wrote:
> It would be nice to be able to turn off the MIPS display in the title
> bar, which I find distracting.
> It also looks a little rough to put the version number in the title bar.
> If it were acceptable, I'd be happy to supply a patch to add
> command-line parsing (on all three platforms) to support a
> "--mips-title" option, and a "--version" flag.
> The version number can of course already be found in the standard way,
> from Help#About.
Mmmmnnnn!
I have multiple copies of RPCEmu installed for testing purposes...
Leave it alone, I do some testing... and find it useful to see at a glance
what version I'm using for a particular test set.
MIPS not that bothered, though it is interesting some times to see how
much loading an app does while processing things.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CAOnWdoi7ZrY5g0XmQ8hPExN66Wc5i9LgPgb18jzO0m8pvWqWRg@mail.gmail.com>,
Reuben Thomas <rrt@sc3d.org> wrote:
> It would be nice to be able to turn off the MIPS display in the title
> bar, which I find distracting.
> It also looks a little rough to put the version number in the title bar.
> If it were acceptable, I'd be happy to supply a patch to add
> command-line parsing (on all three platforms) to support a
> "--mips-title" option, and a "--version" flag.
> The version number can of course already be found in the standard way,
> from Help#About.
Mmmmnnnn!
I have multiple copies of RPCEmu installed for testing purposes...
Leave it alone, I do some testing... and find it useful to see at a glance
what version I'm using for a particular test set.
MIPS not that bothered, though it is interesting some times to see how
much loading an app does while processing things.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Simpler title bar
It would be nice to be able to turn off the MIPS display in the title bar, which I find distracting.
It also looks a little rough to put the version number in the title bar.
If it were acceptable, I'd be happy to supply a patch to add command-line parsing (on all three platforms) to support a "--mips-title" option, and a "--version" flag.
The version number can of course already be found in the standard way, from Help→About.
Re: [Rpcemu] Defunct ROM site link on RPCEmu web site
On 25 May 2016 at 12:20, Reuben Thomas <rrt@sc3d.org> wrote:
The site listed as "Alternative site 2" on http://www.marutan.net/rpcemu/manual/romimage.html no longer exists; you might want to remove it from the list.The other two sites listed still work, so no problem.
The target URL is still broken; it appears not to be a transient problem; but it's still listed in the RPCEmu site. Is there some reason to keep it? (Typos I've pointed out have been fixed, but this broken link remains.)
Monday, 13 June 2016
Re: [Rpcemu] Pulseaudio has constant CPU load even when sound is disabled
In article
<CAOnWdojXiSvO2BNSfgk2tdghtuDwt1ynNgAnp5s7FPKbpKhM5w@mail.gmail.com>,
Reuben Thomas <rrt@sc3d.org> wrote:
> On 8 June 2016 at 17:13, Jim Lesurf <jcgl@audiomisc.co.uk> wrote:
> > In article
> > <CAOnWdogzYmCLi2FN2NfTtp54EwNe8H00V4HMwQEkUbMnZaH3HA@mail.gmail.com>,
> > Reuben Thomas <rrt@sc3d.org> wrote:
> > > Using rpcemu 0.8.14, emulating an SA-RPC running RISC OS 3.71, I
> > > notice that pulseaudio is running with a constant appreciable load
> > > (~20% of a core on my machine), which stops when I quit rpcemu.
> >
> > > This would be less than ideal even if I had sound switched on, but
> > > it's off!
> >
> > I can't advise on the reasons why the above occurs. TBH one of the
> > first things I do with any new Linux install is to try and beat
> > Pulseaudio to death with a big stick as I find it a real PITA! If I
> > can't kill it, I do what I can to isolate and bypass it.
> >
> #I had trouble with Pulseaudio the first time I tried using it, but for
> years now it has been stable and reliable out of the box, and provides
> functionality (such as audio I/O sharing between apps and per-app volume
> controls) unmatched by ALSA, along with non-mind-numbing configuration
> (which I hardly ever have to use). I can't speak for those who are doing
> live sound processing, where low-level considerations may apply.
Just to explain briefly, although I realise it isn't directly relevant
here.
For me the problem is that any 'mixers' like PA tend to fiddle with the
audio data. Often coverting *everything* to the same sample rate and bit
depth. This gets in the way when you want each file to played 'bit perfect'
and your using sample rates up to 192k. i.e. *not* letting everything -
even audio CD format - get played out at 48k. In addition PA in my
experience often overrules what I've set elsewhere. So if the concern is
audio *quality*, PA can be real problem. Whereas ALSA makes it simple to
get a 'direct path' from player software to playing hardware. Pass the
parcel.
Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CAOnWdojXiSvO2BNSfgk2tdghtuDwt1ynNgAnp5s7FPKbpKhM5w@mail.gmail.com>,
Reuben Thomas <rrt@sc3d.org> wrote:
> On 8 June 2016 at 17:13, Jim Lesurf <jcgl@audiomisc.co.uk> wrote:
> > In article
> > <CAOnWdogzYmCLi2FN2NfTtp54EwNe8H00V4HMwQEkUbMnZaH3HA@mail.gmail.com>,
> > Reuben Thomas <rrt@sc3d.org> wrote:
> > > Using rpcemu 0.8.14, emulating an SA-RPC running RISC OS 3.71, I
> > > notice that pulseaudio is running with a constant appreciable load
> > > (~20% of a core on my machine), which stops when I quit rpcemu.
> >
> > > This would be less than ideal even if I had sound switched on, but
> > > it's off!
> >
> > I can't advise on the reasons why the above occurs. TBH one of the
> > first things I do with any new Linux install is to try and beat
> > Pulseaudio to death with a big stick as I find it a real PITA! If I
> > can't kill it, I do what I can to isolate and bypass it.
> >
> #I had trouble with Pulseaudio the first time I tried using it, but for
> years now it has been stable and reliable out of the box, and provides
> functionality (such as audio I/O sharing between apps and per-app volume
> controls) unmatched by ALSA, along with non-mind-numbing configuration
> (which I hardly ever have to use). I can't speak for those who are doing
> live sound processing, where low-level considerations may apply.
Just to explain briefly, although I realise it isn't directly relevant
here.
For me the problem is that any 'mixers' like PA tend to fiddle with the
audio data. Often coverting *everything* to the same sample rate and bit
depth. This gets in the way when you want each file to played 'bit perfect'
and your using sample rates up to 192k. i.e. *not* letting everything -
even audio CD format - get played out at 48k. In addition PA in my
experience often overrules what I've set elsewhere. So if the concern is
audio *quality*, PA can be real problem. Whereas ALSA makes it simple to
get a 'direct path' from player software to playing hardware. Pass the
parcel.
Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Sunday, 12 June 2016
Re: [Rpcemu] Running 1280x1024
On 13 June 2016 at 00:41, Reuben Thomas <rrt@sc3d.org> wrote:
I've now had a chance to try this with a fresh Universal Boot.
I can also confirm that dynarec is now working fine for me (and I can see what a difference it makes to the MIPS; nice to know if I ever want to do something compute-intensive under emulation!).
Re: [Rpcemu] Running 1280x1024
On 8 June 2016 at 15:27, Reuben Thomas <rrt@sc3d.org> wrote:
[Apologies for not replying properly; I had list delivery switched off for the last few years, and only switched it back on after getting a reply to my message, which I therefore didn't receive, but read in the archives.]Thanks, Peter Howkins.As I don't seem to have a proper 3.7x !Boot, and am only using the emulator lightly, I'll wait until the next rpcemu release to use larger screen sizes (or until I find time to update my !Boot), and to re-enable dynarec (though on my modest 2011-era 4-core Intel Core i5 system, performance is perfectly acceptable even without).
I've now had a chance to try this with a fresh Universal Boot.
Changing the BandLimit command parameters unfortunately doesn't increase the amount of RAM RISC OS thinks it has, so while it now allows 1280×1024, it restricts me to 4 greys in that mode.
However, it does work fine, and Universal Boot seems to fix some other problems (my previous !Boot, although it had some 3.7-specific stuff, did not seem to have the full complement including proper StrongARM support).
Re: [Rpcemu] Pulseaudio has constant CPU load even when sound is disabled
On 8 June 2016 at 17:13, Jim Lesurf <jcgl@audiomisc.co.uk> wrote:
In article
<CAOnWdogzYmCLi2FN2NfTtp54EwNe8H00V4HMwQEkUbMnZaH3HA@mail.gmail.com>,
Reuben Thomas <rrt@sc3d.org> wrote:
> Using rpcemu 0.8.14, emulating an SA-RPC running RISC OS 3.71, I notice
> that pulseaudio is running with a constant appreciable load (~20% of a
> core on my machine), which stops when I quit rpcemu.
> This would be less than ideal even if I had sound switched on, but it's
> off!
I can't advise on the reasons why the above occurs. TBH one of the first
things I do with any new Linux install is to try and beat Pulseaudio to
death with a big stick as I find it a real PITA! If I can't kill it, I do
what I can to isolate and bypass it.
I had trouble with Pulseaudio the first time I tried using it, but for years now it has been stable and reliable out of the box, and provides functionality (such as audio I/O sharing between apps and per-app volume controls) unmatched by ALSA, along with non-mind-numbing configuration (which I hardly ever have to use). I can't speak for those who are doing live sound processing, where low-level considerations may apply.
I suspect the bug here is in some Allegro/Pulseaudio interaction, though obviously it could still be in rpcemu. As it happens, sparing ⅛ of ¼ of my cores while running rpcemu isn't a big deal, but if this isn't a known bug I guess I should file one.
Github page failure
Hi,
I was just trying to view this git page:
https://github.com/freebsd/freebsd/tree/master/lib/libusb
but with Atari build 3570 it starts to download and then fails.
Failure when receiving data from the peer
Peter
I was just trying to view this git page:
https://github.com/freebsd/freebsd/tree/master/lib/libusb
but with Atari build 3570 it starts to download and then fails.
Failure when receiving data from the peer
Peter
[gccsdk] [Bug 262] GCC 4.7.4 Rel 2 buffer overflow detected when -Os used
http://www.riscos.info/bugzilla3/show_bug.cgi?id=262
--- Comment #1 from David Thomas <dave@davespace.co.uk> 2016-06-12 08:06:57 PDT ---
Created attachment 87
--> http://www.riscos.info/bugzilla3/attachment.cgi?id=87
Crash output
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
--- Comment #1 from David Thomas <dave@davespace.co.uk> 2016-06-12 08:06:57 PDT ---
Created attachment 87
--> http://www.riscos.info/bugzilla3/attachment.cgi?id=87
Crash output
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] [Bug 262] GCC 4.7.4 Rel 2 buffer overflow detected when -Os used
http://www.riscos.info/bugzilla3/show_bug.cgi?id=262
David Thomas <dave@davespace.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS/Version|RISC OS |Linux
Severity|feature request |normal
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
David Thomas <dave@davespace.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS/Version|RISC OS |Linux
Severity|feature request |normal
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] [Bug 262] New: GCC 4.7.4 Rel 2 buffer overflow detected when -Os used
http://www.riscos.info/bugzilla3/show_bug.cgi?id=262
Summary: GCC 4.7.4 Rel 2 buffer overflow detected when -Os used
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: feature request
Priority: P1
Component: C compiler
AssignedTo: leenoar@sky.com
ReportedBy: dave@davespace.co.uk
Estimated Hours: 0.0
Created attachment 86
--> http://www.riscos.info/bugzilla3/attachment.cgi?id=86
Preprocessed source file to repro the issue.
GCCSDK 4.7.4 release 2 built locally on Ubuntu 14.04.4 LTS.
Compiler crashes when -Os is used. Log attached. Any other -O level seems fine.
Preprocessed source attached.
jenkins@microserver:~/workspace/PrivateEye/libs/appengine$
/home/dave/src/gccsdk/cross/bin/arm-unknown-riscos-gcc -c walk-cont.pp.c -o
datastruct/hash/walk-cont.o -Os
*** buffer overflow detected ***:
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1 terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7329f)[0x7f848493b29f]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f84849d2bbc]
/lib/x86_64-linux-gnu/libc.so.6(+0x109a90)[0x7f84849d1a90]
/lib/x86_64-linux-gnu/libc.so.6(+0x108c2b)[0x7f84849d0c2b]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1[0x9ef503]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(final_scan_insn+0xba9)[0x625b39]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(final+0x24a)[0x6264ea]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1[0x6266e6]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(execute_one_pass+0xfe)[0x705b9e]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(execute_pass_list+0x15)[0x705ee5]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(execute_pass_list+0x27)[0x705ef7]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(execute_pass_list+0x27)[0x705ef7]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(tree_rest_of_compilation+0x73)[0x7da763]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1[0x59644a]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(cgraph_optimize+0x6bc)[0x597d3c]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(cgraph_finalize_compilation_unit+0x75)[0x5980f5]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(c_write_global_declarations+0xf8)[0x4de978]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(toplev_main+0xacc)[0x79516c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f84848e9f45]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1[0x4cde5f]
======= Memory map: ========
00400000-010fd000 r-xp 00000000 08:42 6678470
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1
012fc000-012fd000 r--p 00cfc000 08:42 6678470
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1
012fd000-0130d000 rw-p 00cfd000 08:42 6678470
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1
0130d000-014a4000 rw-p 00000000 00:00 0
026ae000-02938000 rw-p 00000000 00:00 0 [heap]
7f84848c8000-7f8484a82000 r-xp 00000000 08:42 2101535
/lib/x86_64-linux-gnu/libc-2.19.so
7f8484a82000-7f8484c82000 ---p 001ba000 08:42 2101535
/lib/x86_64-linux-gnu/libc-2.19.so
7f8484c82000-7f8484c86000 r--p 001ba000 08:42 2101535
/lib/x86_64-linux-gnu/libc-2.19.so
7f8484c86000-7f8484c88000 rw-p 001be000 08:42 2101535
/lib/x86_64-linux-gnu/libc-2.19.so
7f8484c88000-7f8484c8d000 rw-p 00000000 00:00 0
7f8484c8d000-7f8484ca3000 r-xp 00000000 08:42 2110253
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f8484ca3000-7f8484ea2000 ---p 00016000 08:42 2110253
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f8484ea2000-7f8484ea3000 rw-p 00015000 08:42 2110253
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f8484ea3000-7f8484f89000 r-xp 00000000 08:42 3145839
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
7f8484f89000-7f8485188000 ---p 000e6000 08:42 3145839
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
7f8485188000-7f8485190000 r--p 000e5000 08:42 3145839
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
7f8485190000-7f8485192000 rw-p 000ed000 08:42 3145839
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
7f8485192000-7f84851a7000 rw-p 00000000 00:00 0
7f84851a7000-7f84851aa000 r-xp 00000000 08:42 2097260
/lib/x86_64-linux-gnu/libdl-2.19.so
7f84851aa000-7f84853a9000 ---p 00003000 08:42 2097260
/lib/x86_64-linux-gnu/libdl-2.19.so
7f84853a9000-7f84853aa000 r--p 00002000 08:42 2097260
/lib/x86_64-linux-gnu/libdl-2.19.so
7f84853aa000-7f84853ab000 rw-p 00003000 08:42 2097260
/lib/x86_64-linux-gnu/libdl-2.19.so
7f84853ab000-7f84854b0000 r-xp 00000000 08:42 2097255
/lib/x86_64-linux-gnu/libm-2.19.so
7f84854b0000-7f84856af000 ---p 00105000 08:42 2097255
/lib/x86_64-linux-gnu/libm-2.19.so
7f84856af000-7f84856b0000 r--p 00104000 08:42 2097255
/lib/x86_64-linux-gnu/libm-2.19.so
7f84856b0000-7f84856b1000 rw-p 00105000 08:42 2097255
/lib/x86_64-linux-gnu/libm-2.19.so
7f84856b1000-7f84856d4000 r-xp 00000000 08:42 2101493
/lib/x86_64-linux-gnu/ld-2.19.so
7f84858a8000-7f84858d1000 rw-p 00000000 00:00 0
7f84858d1000-7f84858d3000 rw-p 00000000 00:00 0
7f84858d3000-7f84858d4000 r--p 00022000 08:42 2101493
/lib/x86_64-linux-gnu/ld-2.19.so
7f84858d4000-7f84858d5000 rw-p 00023000 08:42 2101493
/lib/x86_64-linux-gnu/ld-2.19.so
7f84858d5000-7f84858d6000 rw-p 00000000 00:00 0
7ffec4801000-7ffec4822000 rw-p 00000000 00:00 0
[stack]
7ffec4901000-7ffec4903000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]
datastruct/hash/walk-cont.c: In function 'hash_walk_continuation':
datastruct/hash/walk-cont.c:95:1: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gccsdk.riscos.info/> for instructions.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Summary: GCC 4.7.4 Rel 2 buffer overflow detected when -Os used
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: feature request
Priority: P1
Component: C compiler
AssignedTo: leenoar@sky.com
ReportedBy: dave@davespace.co.uk
Estimated Hours: 0.0
Created attachment 86
--> http://www.riscos.info/bugzilla3/attachment.cgi?id=86
Preprocessed source file to repro the issue.
GCCSDK 4.7.4 release 2 built locally on Ubuntu 14.04.4 LTS.
Compiler crashes when -Os is used. Log attached. Any other -O level seems fine.
Preprocessed source attached.
jenkins@microserver:~/workspace/PrivateEye/libs/appengine$
/home/dave/src/gccsdk/cross/bin/arm-unknown-riscos-gcc -c walk-cont.pp.c -o
datastruct/hash/walk-cont.o -Os
*** buffer overflow detected ***:
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1 terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7329f)[0x7f848493b29f]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f84849d2bbc]
/lib/x86_64-linux-gnu/libc.so.6(+0x109a90)[0x7f84849d1a90]
/lib/x86_64-linux-gnu/libc.so.6(+0x108c2b)[0x7f84849d0c2b]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1[0x9ef503]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(final_scan_insn+0xba9)[0x625b39]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(final+0x24a)[0x6264ea]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1[0x6266e6]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(execute_one_pass+0xfe)[0x705b9e]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(execute_pass_list+0x15)[0x705ee5]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(execute_pass_list+0x27)[0x705ef7]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(execute_pass_list+0x27)[0x705ef7]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(tree_rest_of_compilation+0x73)[0x7da763]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1[0x59644a]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(cgraph_optimize+0x6bc)[0x597d3c]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(cgraph_finalize_compilation_unit+0x75)[0x5980f5]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(c_write_global_declarations+0xf8)[0x4de978]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1(toplev_main+0xacc)[0x79516c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f84848e9f45]
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1[0x4cde5f]
======= Memory map: ========
00400000-010fd000 r-xp 00000000 08:42 6678470
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1
012fc000-012fd000 r--p 00cfc000 08:42 6678470
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1
012fd000-0130d000 rw-p 00cfd000 08:42 6678470
/home/dave/src/gccsdk/cross/libexec/gcc/arm-unknown-riscos/4.7.4/cc1
0130d000-014a4000 rw-p 00000000 00:00 0
026ae000-02938000 rw-p 00000000 00:00 0 [heap]
7f84848c8000-7f8484a82000 r-xp 00000000 08:42 2101535
/lib/x86_64-linux-gnu/libc-2.19.so
7f8484a82000-7f8484c82000 ---p 001ba000 08:42 2101535
/lib/x86_64-linux-gnu/libc-2.19.so
7f8484c82000-7f8484c86000 r--p 001ba000 08:42 2101535
/lib/x86_64-linux-gnu/libc-2.19.so
7f8484c86000-7f8484c88000 rw-p 001be000 08:42 2101535
/lib/x86_64-linux-gnu/libc-2.19.so
7f8484c88000-7f8484c8d000 rw-p 00000000 00:00 0
7f8484c8d000-7f8484ca3000 r-xp 00000000 08:42 2110253
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f8484ca3000-7f8484ea2000 ---p 00016000 08:42 2110253
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f8484ea2000-7f8484ea3000 rw-p 00015000 08:42 2110253
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f8484ea3000-7f8484f89000 r-xp 00000000 08:42 3145839
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
7f8484f89000-7f8485188000 ---p 000e6000 08:42 3145839
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
7f8485188000-7f8485190000 r--p 000e5000 08:42 3145839
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
7f8485190000-7f8485192000 rw-p 000ed000 08:42 3145839
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
7f8485192000-7f84851a7000 rw-p 00000000 00:00 0
7f84851a7000-7f84851aa000 r-xp 00000000 08:42 2097260
/lib/x86_64-linux-gnu/libdl-2.19.so
7f84851aa000-7f84853a9000 ---p 00003000 08:42 2097260
/lib/x86_64-linux-gnu/libdl-2.19.so
7f84853a9000-7f84853aa000 r--p 00002000 08:42 2097260
/lib/x86_64-linux-gnu/libdl-2.19.so
7f84853aa000-7f84853ab000 rw-p 00003000 08:42 2097260
/lib/x86_64-linux-gnu/libdl-2.19.so
7f84853ab000-7f84854b0000 r-xp 00000000 08:42 2097255
/lib/x86_64-linux-gnu/libm-2.19.so
7f84854b0000-7f84856af000 ---p 00105000 08:42 2097255
/lib/x86_64-linux-gnu/libm-2.19.so
7f84856af000-7f84856b0000 r--p 00104000 08:42 2097255
/lib/x86_64-linux-gnu/libm-2.19.so
7f84856b0000-7f84856b1000 rw-p 00105000 08:42 2097255
/lib/x86_64-linux-gnu/libm-2.19.so
7f84856b1000-7f84856d4000 r-xp 00000000 08:42 2101493
/lib/x86_64-linux-gnu/ld-2.19.so
7f84858a8000-7f84858d1000 rw-p 00000000 00:00 0
7f84858d1000-7f84858d3000 rw-p 00000000 00:00 0
7f84858d3000-7f84858d4000 r--p 00022000 08:42 2101493
/lib/x86_64-linux-gnu/ld-2.19.so
7f84858d4000-7f84858d5000 rw-p 00023000 08:42 2101493
/lib/x86_64-linux-gnu/ld-2.19.so
7f84858d5000-7f84858d6000 rw-p 00000000 00:00 0
7ffec4801000-7ffec4822000 rw-p 00000000 00:00 0
[stack]
7ffec4901000-7ffec4903000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]
datastruct/hash/walk-cont.c: In function 'hash_walk_continuation':
datastruct/hash/walk-cont.c:95:1: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gccsdk.riscos.info/> for instructions.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Wednesday, 8 June 2016
Re: [Rpcemu] Pulseaudio has constant CPU load even when sound is disabled
In article
<CAOnWdogzYmCLi2FN2NfTtp54EwNe8H00V4HMwQEkUbMnZaH3HA@mail.gmail.com>,
Reuben Thomas <rrt@sc3d.org> wrote:
> Using rpcemu 0.8.14, emulating an SA-RPC running RISC OS 3.71, I notice
> that pulseaudio is running with a constant appreciable load (~20% of a
> core on my machine), which stops when I quit rpcemu.
> This would be less than ideal even if I had sound switched on, but it's
> off!
I can't advise on the reasons why the above occurs. TBH one of the first
things I do with any new Linux install is to try and beat Pulseaudio to
death with a big stick as I find it a real PITA! If I can't kill it, I do
what I can to isolate and bypass it.
Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CAOnWdogzYmCLi2FN2NfTtp54EwNe8H00V4HMwQEkUbMnZaH3HA@mail.gmail.com>,
Reuben Thomas <rrt@sc3d.org> wrote:
> Using rpcemu 0.8.14, emulating an SA-RPC running RISC OS 3.71, I notice
> that pulseaudio is running with a constant appreciable load (~20% of a
> core on my machine), which stops when I quit rpcemu.
> This would be less than ideal even if I had sound switched on, but it's
> off!
I can't advise on the reasons why the above occurs. TBH one of the first
things I do with any new Linux install is to try and beat Pulseaudio to
death with a big stick as I find it a real PITA! If I can't kill it, I do
what I can to isolate and bypass it.
Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Running 1280x1024
[Apologies for not replying properly; I had list delivery switched off for the last few years, and only switched it back on after getting a reply to my message, which I therefore didn't receive, but read in the archives.]
Thanks, Peter Howkins.
As I don't seem to have a proper 3.7x !Boot, and am only using the emulator lightly, I'll wait until the next rpcemu release to use larger screen sizes (or until I find time to update my !Boot), and to re-enable dynarec (though on my modest 2011-era 4-core Intel Core i5 system, performance is perfectly acceptable even without).
[Rpcemu] Pulseaudio has constant CPU load even when sound is disabled
Using rpcemu 0.8.14, emulating an SA-RPC running RISC OS 3.71, I notice that pulseaudio is running with a constant appreciable load (~20% of a core on my machine), which stops when I quit rpcemu.
This would be less than ideal even if I had sound switched on, but it's off!
Monday, 6 June 2016
Re: [Rpcemu] Running 1280x1024
On Mon, Jun 06, 2016 at 01:01:03AM +0100, Reuben Thomas wrote:
> I'm running rpcemu 0.8.14 on an x86_64 GNU/Linux system (Ubuntu 14.04).
> I am using RISC OS 3.71, with StrongARM emulation, 2Mb VRAM selected, and
> 32Mb of RAM. I am not using dynrec (I found it unusably unstable) and I
> have "reduce CPU usage" selected.
The dynarec issue and the one you mention below are probably the same
thing ...
> I am running happily in 1024x768x256 colours. I have the (apparently
> default) AKF85 monitor selection.
> When I switch to 1280x1024, the display change normally works fine, but I
> get constant crashes until I switch back to 1024x768.
> Any clues?
> If I've failed to supply enough/the right information, do let me know!
The last version added auto patching for 8MB VRAM for RISC OS 3.7 if 2MB
VRAM is sslected. There's a bug in it (now fixed in the development
repository).
Basically to enable large screen modes in 3.7 select 0MB VRAM and find the
BandLimit line in the file !Boot.RO370Hook.Boot.PreDesk.Configure.!Run add
a 0 to the end of each of those numbers, this should allow larger
modes with 0MB VRAM (don't do this on a real machine, but it's fine on an
emulator).
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> I'm running rpcemu 0.8.14 on an x86_64 GNU/Linux system (Ubuntu 14.04).
> I am using RISC OS 3.71, with StrongARM emulation, 2Mb VRAM selected, and
> 32Mb of RAM. I am not using dynrec (I found it unusably unstable) and I
> have "reduce CPU usage" selected.
The dynarec issue and the one you mention below are probably the same
thing ...
> I am running happily in 1024x768x256 colours. I have the (apparently
> default) AKF85 monitor selection.
> When I switch to 1280x1024, the display change normally works fine, but I
> get constant crashes until I switch back to 1024x768.
> Any clues?
> If I've failed to supply enough/the right information, do let me know!
The last version added auto patching for 8MB VRAM for RISC OS 3.7 if 2MB
VRAM is sslected. There's a bug in it (now fixed in the development
repository).
Basically to enable large screen modes in 3.7 select 0MB VRAM and find the
BandLimit line in the file !Boot.RO370Hook.Boot.PreDesk.Configure.!Run add
a 0 to the end of each of those numbers, this should allow larger
modes with 0MB VRAM (don't do this on a real machine, but it's fine on an
emulator).
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Sunday, 5 June 2016
[Rpcemu] Running 1280x1024
I'm running rpcemu 0.8.14 on an x86_64 GNU/Linux system (Ubuntu 14.04).
I am using RISC OS 3.71, with StrongARM emulation, 2Mb VRAM selected, and 32Mb of RAM. I am not using dynrec (I found it unusably unstable) and I have "reduce CPU usage" selected.
I am running happily in 1024x768x256 colours. I have the (apparently default) AKF85 monitor selection.
When I switch to 1280x1024, the display change normally works fine, but I get constant crashes until I switch back to 1024x768.
Any clues?
If I've failed to supply enough/the right information, do let me know!
[Rpcemu] Web site typos
On the home page:
"but not limited too" → "but not limited to"
"How to get code committed into the repository" should probably be a heading.
Subscribe to:
Posts (Atom)