Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (sTix)

Bottom

« 1 2 3 (4) 5 6 7 ... 12 »

sTix

Re: gcc 9 and 10

Posted on: 2022/1/11 7:37 #61

Just popping in

@kas1e
Quote:

So did i understand right (haven study it for real at the moment) that gmon.out format is the same "dwarf" based section which we have inside of the binary if compile it with -gstabs ?

I don't know. But it makes sense that gprof needs sort of the same information as gdb to work.

Topic | Forum

sTix

Re: gcc 9 and 10

Posted on: 2022/1/10 22:15 #62

Just popping in

@kas1e

You should get those errors if you do like this:

gcc -pg -gdwarf-2 test.c -o test
gprof test gmon.out > _

It's not just a question of dwarf version though, there's obviously something generating garbage data somewhere.

Topic | Forum

sTix

Re: gcc 9 and 10

Posted on: 2022/1/10 21:35 #63

Just popping in

@kas1e
Quote:

If you have anything intersting to say or so, plz speak :)

Sounds like it's related to the gdb problems. But it doesn't seem to help to build using an older dwarf version either. It looks like binutils is broken (unless someone has been very busy updating the dwarf format):

BFD: Dwarf Error: found dwarf version '5', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '0', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '768', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '47133', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '200', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '295', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '5464', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '68', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '178', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '1024', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '46852', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '26990', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '260', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '0', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '1029', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '5', this reader only handles version 2, 3 and 4 information.
BFD: Dwarf Error: found dwarf version '1280', this reader only handles version 2, 3 and 4 information.

Topic | Forum

sTix

Re: gcc 9 and 10

Posted on: 2022/1/10 18:39 #64

Just popping in

@kas1e
Quote:

Btw, i see the last one on SBA repo 11.1 but on GCC page 2021-07-28 11.2 were out. Is it possible to ask you about merge?:)

https://github.com/sba1/adtools/pull/113

Once that's in I'll probably make another PR for a couple of minor clib2 changes as well.

Topic | Forum

sTix

Re: gcc 9 and 10

Posted on: 2022/1/6 20:11 #65

Just popping in

@walkero

Quick answers, I'm in a hurry :)

1: 5.2
2: No, haven't looked much at coreutils since 5.2 is fine by me.
3: No, 64-bit. But it shouldn't matter.
4: Yes.
5: Sounds suspicious.
6: I don't know if anyone tried but it shouldn't be to hard, it's just a point release (and the v9 patches could perhaps give some clues).

Topic | Forum

sTix

Re: Do we still not have a patch for direct paula->ahi redirection ?

Posted on: 2022/1/4 19:35 #66

Just popping in

@kas1e
Quote:

EDIT2: tried to compile BestFakeMode and while it compiles with some warnings it fails to link saying about undefs to the "ham6" and "ham8" from engine.c. Checked that file and they there just inlined. So remove inline and all links fine (seems newer compilers don't like inlines anymore).

New compilers like them even more than the old ones :) It's just that they need to reside in the same compilation unit unless you're using LTO. This has always been the case. That's why you often see inline functions in header files.

Topic | Forum

sTix

Re: AmigaOS4 SDK 53.34 Questions?

Posted on: 2021/12/29 20:17 #67

Just popping in

@rjd324
Quote:

Question: Why does clib2/string.h in 53.34 not contain 'strnlen' whilst the version of clib2 on github does?

In order to get C++17 going, clib2 needed some work. And since the sources are out there, it's quicker to just do it rather than wait for someone else to do it (especially when it's not entirely clear what really needs to be done).

Topic | Forum

sTix

Re: gcc 9 and 10

Posted on: 2021/12/27 23:40 #68

Just popping in

@kas1e
Quote:

While installing GCC 11 from the Adtools repo find out that in Makefile it has: CLIB2_URL=https://github.com/sodero/clib2

isn't it installs your clb2 already ?:)

That's the way it's supposed to be, it's needed for C++17. The SHA1 is set though, so you're not going to get anything funky.
If you use my adtools repo you'll get HEAD on master from my clib2 fork which contains threading and so on.

Topic | Forum

sTix

Re: gcc 9 and 10

Posted on: 2021/12/26 15:03 #69

Just popping in

@kas1e
Quote:

Btw, i see the last one on SBA repo 11.1 but on GCC page 2021-07-28 11.2 were out. Is it possible to ask you about merge?:)

Definitely, the plan is to bump version 11 one more time. 12.0 is probably not far off. I'll look into this after the holidays are over.

Topic | Forum

sTix

Re: gcc 9 and 10

Posted on: 2021/12/26 1:12 #70

Just popping in

@kas1e
Quote:

What one is better to grab: from your page which is 10.3.0_buld2 or from SBA1's page? i mean gcc11 is not too beta ?:)

The best would be to build from SBA:s repo. I you build mine you would get a clib2 with c11 thread support which is highly experimental, more experimental than I can recommend :)

Topic | Forum

sTix

Re: Netsurf, annoying debug log

Posted on: 2021/11/27 20:49 #71

Just popping in

@Chris

I really appreciate your work. 3.11 seems stable sofar, fast too.

Topic | Forum

sTix

Re: Face of Qt 6

Posted on: 2021/9/7 14:53 #72

Just popping in

@alfkil

Lovely!

Topic | Forum

sTix

Re: Face of Qt 6

Posted on: 2021/8/29 20:33 #73

Just popping in

I'd say yes. You have a nice frame there so you ought to be able to fill it up with something clock-like in a week :)

Topic | Forum

sTix

Re: MutexAttemptWithSignal

Posted on: 2021/8/28 9:54 #74

Just popping in

@broadblues

No, I don't have any real use case. I was just surprised by this behaviour while experimenting with timers. I thought that I could attempt to lock, hang until a timeout signal arrived and then verify that the timeout occured. This only makes sense when having multiple threads of course, for testing purposes I thought that I could skip the threading part, because I'm lazy. I didn't expect the mutex to keep track of ownership since it non-recursive. I don't understand why it does that, it's unneccesary and leads to unintuitive results IMO. It's just my opinion though, in ISO C11 the outcome of the same operation is undefined, so I guess the behaviour can be considered correct.

Topic | Forum

sTix

Re: MutexAttemptWithSignal

Posted on: 2021/8/24 10:21 #75

Just popping in

@graff

I don't use any code to signal the task, the code is nothing but the lines you see above. I use the Scout utility which seems to peek into the task struct to see what signals the task is waiting on. And just like salass00 wrote above, it's waiting for SIGF_SINGLE|sigmask, so I signal using sigmask only and it unblocks as expected, but then returns 0. I do get a valid sigbit from AllocSignal also, not -1.

Topic | Forum

sTix

Re: MutexAttemptWithSignal

Posted on: 2021/8/23 21:07 #76

Just popping in

@salass00

I guess it's possible to shave off a few bytes and cpu cycles by not caring about ownership. Not being owned by a thread makes it possible to throw them around, one thread locking, another one unlocking and so on. I don't know if this is applicable on AmigaOS though. I'm just doing some random experiments to learn the Amiga way of doing things. The only use case I care about is testing AttemptWithSignal ;) Didn't turn out the way I expected, but I learnt something. Thanks!

Topic | Forum

sTix

Re: MutexAttemptWithSignal

Posted on: 2021/8/23 15:43 #77

Just popping in

@salass00

Thanks for helping out. The snippet below should be safe though? It behaves in the exact same way.


BYTE sigbit = AllocSignal(-1);

APTR mtx = AllocSysObjectTags(ASOT_MUTEX, ASOMUTEX_Recursive, FALSE, TAG_END); 

MutexObtain(mtx); 

uint32 sigmask = MutexAttemptWithSignal(mtx, 1 << sigbit);

Topic | Forum

sTix

Re: MutexAttemptWithSignal

Posted on: 2021/8/23 7:57 #78

Just popping in

@salass00

Ok, good to know. So in other words I'm tricking myself to believe that the mutex is obtained by signaling manually?

Edited by sTix on 2021/8/23 8:32:18

Topic | Forum

sTix

MutexAttemptWithSignal

Posted on: 2021/8/22 22:50 #79

Just popping in

I must be missing something very basic here:


APTR mtx = AllocSysObjectTags(ASOT_MUTEX, ASOMUTEX_Recursive, FALSE, TAG_END);

MutexObtain(mtx);

uint32 sigmask = MutexAttemptWithSignal(mtx, SIGF_SINGLE);

Like I expect, the MutexAttemptWithSignal call hangs. If I use Scout to signal the task, it continues. That's also what I would expect. But sigmask is 0. If I understand the documentation correctly it should have been SIGF_SINGLE, shouldn't it?

Topic | Forum

sTix

Re: gcc 9 and 10

Posted on: 2021/7/19 22:59 #80

Just popping in

@Raziel

Thanks! I think I was wrong above, isn't our gdb stuck at dwarf-2?

Topic | Forum

Top

« 1 2 3 (4) 5 6 7 ... 12 »