Who's Online |
90 user(s) are online ( 47 user(s) are browsing Forums)
Members: 0
Guests: 90
more...
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2021/2/18 13:30
#121
|
Just popping in 
|
@Raziel No problem at all, it's just nice with some trafic 
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2021/2/18 13:11
#122
|
Just popping in
|
@Raziel I was also a bit to quick Gmake is not a part of adtools so if we want to fix that we need to do it elsewhere. But it's not really critical, I guess most people have a decent stacksize nowadays.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2021/2/18 12:25
#123
|
Just popping in
|
@raziel I have 10 minutes until the next meeting so I had a peek anyway There's a cookie in there: static const char * __attribute__((used)) amigaos_stack_cookie = "$STACK:768000"; *Oh*, now I see what you're writing. It's *make*. I guess I need to take another look then
|
|
|
|
|
|
Re: GDB
|
Posted on: 2021/2/18 12:18
#124
|
Just popping in
|
@kas1e Quote: Next, I got my new x1950 graphics card, and able to install the latest morphos and latest SDK on it (where they have GDB 8.3 port), and check if it can break/trace things: and it can. Everything works as expected.
Through, that point us to nowhere: it can be that morphos' kernel just has all things in place already for x5000. But from another side, we also can check morphos' diffs for gdb to see if there anything special for x5000 done. I think it points us somewhere at least. Like you say, it probably works thanks to MorphOS itself, but it doesn't hurt to study the GDB patches. Was it Thomas that did the work on the current GDB?
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2021/2/18 11:56
#125
|
Just popping in
|
@Raziel
Yes, gcc needs a lot of stack. A stack cookie is a good idea if there isn't one there already (I haven't looked but I'll do that tonight). But picking a good value is less straight forward than for a 'normal' application since it depends on what source code you're working with of course. Perhaps we should just give it 'a lot', 10M or so. A more ambitious approach would be to pick a big project (let's say kas1es OWB) and use Valgrind (Massif) to get a real measurement and add some on top of that.
Does it crash when compiling or when linking BTW?
|
|
|
|
|
|
Re: updating sgit
|
Posted on: 2021/2/13 12:47
#126
|
Just popping in
|
@billyfish
If it's file backed mmaps only, one file at the time with no msyncs, it should be straight forward. If it's more complicated than that, a fake implementation will probably be very inefficient. It would be great if someone took the time to do it, it's probably a pretty common porting problem. My guess is that this could be a good candidate for trying out the OS4 extmem feature.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2021/2/12 18:16
#127
|
Just popping in
|
@kas1e
Interesting. But is it possible for normal users to get access to the bug tracker?
Do you have MorphOS on your x5000 BTW? It would be interesting to see if / how gdb works there.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2021/2/12 14:48
#128
|
Just popping in
|
@kas1e Quote: Tried the same GDB on pegasos2 and on x5000. On pegasos2 tracing/breakpoints works, on X5000 didn't.
So as peg2 is G4, but x5000 are not and mean to be "embedded kind" in means their debugging facilities are different too. X5000 CPU has a special debug interrupt, but this one is different from the trace interrupt in G4. This means that needs to be taken into account when making tracing/breakpoint works on x5000.
In other words, it means some x5000 specific code probably. Excellent, then it works, sort of. The neccessary changes should be out there somewhere I guess. Whoever is doing an embedded application with this CPU ought to have what we're looking for.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2021/2/12 14:40
#129
|
Just popping in
|
@NinjaCyborg Quote: One trick you can use with git is to access your sgit folder from a different (non Amiga) machine, to execute commands sgit does not support
I recently did this to execute the 'remote' command to link my repo to github. Then one can push, pull and commit as usual. Yes, I've been thinking of doing something like this. E-mailing patches back and forth isn't ideal
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2021/2/12 14:33
#130
|
Just popping in
|
@billyfish Quote: I started work on upgrading to the latest libgit2, and got it using AmiSSL rather than a static older version of OpenSSL, but I stopped when I hit the fact the it uses mmap () and munmap () now. I think there was only one or two instances where it was writing to a mmap'd buffer, the rest were just reading which is obviously easier to deal with. My build environment could use the older libgit2 or a newer one so I'm going to update the instructions on my forked repo as how to build the different versions and see if I can get the energy to have another crack at it. Nice. But the mmap and munmap problem shouldn't be too hard if the mapped file fits into memory (thanks to the Amiga way of managing memory). I might overlook something, but isn't it just mmap -> read the whole file into a buffer, munmap -> write buffer to file? Quote: Anyone willing to help work on it would be very appreciated! We desperately need more people.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2021/2/12 14:13
#131
|
Just popping in
|
@kas1e Quote: Btw, by core utils means what ones? Native versions of make, awk, bison, new python, Perl, sed, cp, cat, and all that ? If so, it also not of _that_ big problem, because again, it at least can be solved in some way by using cross-compiler, while without native GDB you can do shit in terms of debugging :) IMHO, native GDB is that which we need 100% and it really necessary, and not cross-compilers, not virtual machines can cover it at the moment. It's these ones: http://www.maizure.org/projects/decoded-gnu-coreutils/True, they're not that important TBH.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2021/2/12 13:48
#132
|
Just popping in
|
@kas1e It would be good with a working baseline before someone (again, I don't want to point any fingers in my direction ) starts to work on a recent gdb. It's not fun to solve two problems at the same time.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2021/2/12 13:11
#133
|
Just popping in
|
@kas1e
I didn't know this, but gcc 10 still supports dwarf 2 using the '-gdwarf-2' option. Using that, it's possible to load binaries using the gdb from the official SDK. Most things don't work though, I can inspect sources but break points don't work. When I tried it with the old compiler in the SDK it's the same thing. Is gdb in the SDK broken or am I missing something? I've tried both the stabs and the dwarf 2 format.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2021/2/12 12:20
#134
|
Just popping in
|
@kas1e Quote: Btw, do you have an interest in working on newer Binutils? Why I ask, is that I download Morphos's SDK source code, and there is not _that_ many changes in the diff file. Taking into account that we already have some version with specific amigaos4 changes + diff from morphos devs, it can be (i hope) a little bit easier? Yes, I'm slightly interested (and slightly relectant). IMO the major gaps right now is git (sgit seems to have halted?) and gdb. Quote: And maybe after that, we can have at least working gdb (seeing patch sets from 5.3 version for os4, and changes in 8.3 version on morphos, it also didn't look like _that_ hard). Aren't you mixing up coreutils and binutils (I do that myself all the time)? Examining the MorphOS patches sounds like a good idea. I'll have a peek but I can't make any promises, to much going on here with work, kids not in school due to covid-19 and so on...
|
|
|
|
|
|
Re: python3.8 AmigaOS4 in development
|
Posted on: 2021/2/12 8:22
#135
|
Just popping in
|
@afxgroup Great work! There's a gcc 10.2.0 now BTW. Bleeding edge
|
|
|
|
|
|
Re: SDL2
|
Posted on: 2021/2/7 10:49
#136
|
Just popping in
|
@kas1e and @raziel I appreciate your encouraging words. I realize that what I wrote came across as frustration, but it really shouldn't be interpreted that way. I'm still motivated. It's just that there needs to be a bit of planning involved if you want to last a full marathon. If you start having pain after just 20km then you need to slow down, it's supposed to start at 35km, not before that
|
|
|
|
|
|
Re: SDL2
|
Posted on: 2021/2/6 12:12
#137
|
Just popping in
|
@Raziel
The focus right now is to integrate everything in the main repos, adtools and clib2 (the latter is the bottleneck). It makes sense to start with gcc 9 since that patch set is smaller. If it takes too much time I'll publish a gcc 10 build as well. But it's slowly coming to a point where I'm having problems keeping track of branches and PR:s so integration is prio 1. If it doesn't work out with the integration I'll probably halt gcc and clib2 work for now, it simply gets too confusing for everyone.
|
|
|
|
|
|
Re: SDL2
|
Posted on: 2021/2/6 0:41
#138
|
Just popping in
|
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2021/2/4 12:00
#139
|
Just popping in
|
@Raziel
It's probably just the linker you're after. But no, I doubt anyone would dare to take on something like this. Even if it would be possible (in theory at least), it sounds extremely intrusive which would make it a nightmare to keep up with upstream. If you have a project this big, you probably have very long build times as well. In other words, a cross-compiler would be your best friend.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2021/2/2 12:10
#140
|
Just popping in
|
@kas1e Agree, but my PR in clib2 is 29 days old by now so I thought I might as well do a PR for adtools, then there's one fork less. SBA is very quick responding to PR:s. About clib2, indeed me and afxgroup should work together IMHO. Once we get a clear yes / no from Barthel we can decide on how to proceed. If we get a no, then we can drop 68k and turn clib2 into an os4 lib only. If that's the case then we can drop my repo, or afxgroup:s (depending on what you want afxgroup, I don't have any emotional attachment to my repo , in fact I'd like to get rid of it). We could also consider asking SBA to create a new repo under adtools. If we're going to drop 68k and do all sorts of funky things then at some point perhaps we should consider calling it something else to eliminate one source of confusion (and Barthel probably doesn't want to be tainted by our mistakes). Before, and if, we do the last one, we should get Barthels opinion of course.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
