Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
48 user(s) are online (40 user(s) are browsing Forums)

Members: 0
Guests: 48

more...

Support us!

Headlines

 
  Register To Post  

« 1 2 3 4 (5) 6 7 8 ... 21 »
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@sTix
Quote:

Yes, I'm slightly interested (and slightly reluctant). IMO the major gaps right now are git (sgit seems to have halted?) and gdb.


Without native git, we at least can use cross-compiler's git, or even download from the web, but without native GDB with dwarf4 support, we can't debug os4 bins in realtime (even that patch about which I told before didn't help, because once you link binary building with dwarf2 but with all those stubs .a libs which build with dwarf4, GDB then still cry that this is dwarf4 and can't do shit with).

Quote:

Yes, I'm slightly interested (and slightly reluctant). IMO the major gaps right now are git (sgit seems to have halted?) and gdb.


As far as I see, gdb 8.3 on morphos use Binutils-2.33.1. Why exactly that one dunno, probably the author of gdb port just sticks to it for internal reasons, so I mean Binutils.

From another side, maybe it will be easier to add dwarf4 support to our current gdb version?

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.


Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: gcc 9 and 10
Not too shy to talk
Not too shy to talk


See User information
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.

Also I wonder if anyone has tried to build git under AmiCygnix so it could at least be run from there.

There are some pure python implementations of git too.

Go to top
Re: gcc 9 and 10
Just popping in
Just popping in


See User information
@kas1e

I absolutely agree that gdb would be a game changer as development would be sooooo much easier with a working debugger.

Go to top
Re: gcc 9 and 10
Just popping in
Just popping in


See User information
@sTix

Quote:

Yes, I'm slightly interested (and slightly relectant). IMO the major gaps right now is git (sgit seems to have halted?) and gdb.


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. Anyone willing to help work on it would be very appreciated!


Go to top
Re: gcc 9 and 10
Just popping in
Just popping in


See User information
@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.

Go to top
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@sTix
Quote:

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.


Yeah, but problem that most libs (those which on os4depot ones, any older local builds of developers, etc), build with more or less decent versions of GCC. And even if you build dwarf2 binary , but link it with those libs which were build as it (so dwarf4), GDB then says "dwarf4, sorry".

Quote:

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 formats.


Yeah, it has heavily broken as far as I can see now. On x5000 even if I just load the binary into, and do "break main", and then "r", it just didn't break on main, but exit instead.

I need to check if it works on peg2 at all now. And if is, then it mean x5000 specific (at least we have something of that sort with Alfkil when debug spotless and db101 until he loose motivation)

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: gcc 9 and 10
Just popping in
Just popping in


See User information
@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.

Go to top
Re: gcc 9 and 10
Just popping in
Just popping in


See User information
@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.

Go to top
Re: gcc 9 and 10
Just popping in
Just popping in


See User information
@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.

Go to top
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@sTix
Quote:

Is gdb in the SDK broken or am I missing something? I've tried both the stabs and the dwarf 2 formats.


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.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: gcc 9 and 10
Just popping in
Just popping in


See User information
@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

Go to top
Re: gcc 9 and 10
Just popping in
Just popping in


See User information
@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.

Go to top
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@sTix
Quote:

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.


When I ask Thomas about it half of year ago, he says "They have a special debug interrupt that is completely different from the trace interrupt in previous architectures. The facilities themselves do exist, but you have to write special code for it." He wasn't sure at this time if the debug interrupt routes over the TRAP exception handler at all, but he doesn't think there is any way to discern which one it is. But from that discussion come this enhancement request: https://execsg.solie.ca/mantis/view.php?id=52

This is done with the comment "Debug interrupt can now be accessed via TRAPNUM_TRACE (this more or less ties in with previous incarnations of the facilities)". So, we just need to test it all if it works, etc.

EDIT:

I also think we may have some issues with "alignment" : on x5000 CPU, as it misses 4 opcodes (lfs, lfsu, stfs, stfsu). without which we always need to align the data/code, etc. That can be another reason why old gdb didn't work on x5000 too.

And, there were another report, x5000 specific too: https://execsg.solie.ca/mantis/view.php?id=53

Maybe all of this needs to be taken into account and tested/retested.


Edited by kas1e on 2021/2/12 17:11:56
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: gcc 9 and 10
Just popping in
Just popping in


See User information
@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.

Go to top
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@sTix
Quote:

Interesting. But is it possible for normal users to get access to the bug tracker?


I were under impression that this is public. Strange if it not ..

Quote:

Do you have MorphOS on your x5000 BTW? It would be interesting to see if / how gdb works there.


On on peg2 at moment, but about to buy a gfx card specially for morphos tests as well. So will have it after a week or so.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@sTix

This is pretty sure not a genuine crash of gcc9/10 but probably a long standing one. (Haven't tested with anything else than gcc10.1.0)

If i set the stack of WB shell to the lowest possible (65528) and try to compile my project, i *always* get a very hard crash with no grimreaper coming up and only rudimentary output on serial.

kernel 54.30 (1.1.2021AmigaOne X1000 release
Machine model
(AmigaOne X1000)
Dump of context at 0xDF9593E0
Trap type
DSI exception
DSISR
42000000  DAR54DD0FF0
Page
0xDF9672A0 (Virtual0x54DD0000Physical0x00000000Flags0x 800)
Machine State (raw): 0x100000000000B030
Machine State 
(verbose): [Hyper] [ExtInt on] [Super] [IAT on] [DAT on]
Instruction pointerin module kernel+0x00050668 (0x02050668)
Crashed processgmake (0x5336A9C0)
DSI verbose error descriptionAccess to address 0x54DD0FF0 not found in hash or BAT (page fault)
Access was a store operation
 0
0204BCBC 54DD1010 07F7FF00 02B216A4 DF8E6D98 00000003 00000000 6FF78068
 8
00000003 02B20000 6FF78068 00000003 93933393 FE00090E 00000000 00000000
16
00001000 00000000 00000000 DF953F60 00000000 00000080 00000000 00001000
24
0000004F 6FF78000 0000000E 00000003 0000000F 00000004 00000024 DF8E6D98
CR
53933393   XERC0000000  CTR02031C68  LR0204CAE0

Disassembly of crash site
:
 02050658: 
81430000   lwz               r10,0(r3)
 
0205065C7F895040   cmplw             cr7,r9,r10
 02050660
4C9C0020   bgelr-            cr7
 02050664
4BFFFE90   b                 0x20504F4
>02050668: 9421FFE0   stwu              r1,-32(r1)
 
0205066C93C10018   stw               r30,24(r1)
 
020506703FC00295   lis               r30,661
 02050674
93E1001C   stw               r31,28(r1)
 02050678: 
7C7F1B78   mr                r31,r3
 0205067C
813E8B18   lwz               r9,-29928(r30)

Kernel command lineserial debuglevel=0

Registers pointing to code
:


Does anyone know why?
Doesn't gmake use a stack cookie?
Shouldn't that be handled by the system?

I've raised the stack in shell to 500.000 again and it started to compile.

Go to top
Re: gcc 9 and 10
Just popping in
Just popping in


See User information
@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?

Go to top
Re: gcc 9 and 10
Just popping in
Just popping in


See User information
@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

Go to top
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@sTix

Yup, sorry.
Tired after nightshifts.

Its gmake that crashes and it doesn't matter what source file, it will crash as soon as gmake is invoked.

I have a big project (scummvm) here and am just trying with 500kb of stack, which doesnt throw any errors upto now.

Before that I had the shell set to 2 mb, but I thought that must be overkill, so I went on to see what happens if I drain the stack...well, not that good idea of an idea.

Go to top
Re: gcc 9 and 10
Just popping in
Just popping in


See User information
@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.

Go to top

  Register To Post
« 1 2 3 4 (5) 6 7 8 ... 21 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project