My sources can be downloaded at

http://dl.dropbox.com/u/5482530/gdb.lha

(in a few minutes). I didn't take the time to
organize it, so it is filled with .o files, .svn stuff
and a lot of other crap.

@tonyw:

I was thinking the same thing, that the port was
deleted, but why am I able to receive an actual
message from it a little later on?

@Daedalus

It should return the signal it receives. That is, if it receives SIGBREAKF_CTRL_C, then it returns that, if it receives a signal from the port, it returns a field with just the ports signal bit set. That's how it works in my test app, and that's how the docs describe it. Only place it doesn't work is in GDB. Strange...

@kas1e

I'm just fooling around. I managed to compile it and
fix a bug that made it crash every time it loaded some
code, but apart from that there's not so much progress.

Working on GDB, I discover that IExec->Wait() often returns
-1. The docs say nothing about error conditions, so what could
this possibly mean?

This is the line:

sig = IExec->Wait(SIGBREAKF_CTRL_C|SIGBREAK_CTRL_D|1<<msgport->mp_SigBit);

EDIT: Byt the way, the port _has_ been created, and the sigbit is set.

@joerg

Just saw your response now. Thanks J?rg!

sched_yield() is (afaik) supposed to make the current task/thread
jump to the back of the task list. Is there some way to do/emulate this
with exec or pthreads?

@Framiga

Yup, or rather now I'm running 16-bit with no shadows, no problems as they say. Bit of a shame, though.

EDIT: Is there a tag to disable shadows in 24-bit?

http://dl.dropbox.com/u/5482530/a.out
http://tinyurl.com/y4g8ypw

You need both these files to run the example.
If you compile and run this code, you will get a grim reaper. The question is why.

Obviously it is IElf->RelocateSection() that is the problem. In the
autodocs it says:

"Note: If the section was absolute, or no reloc could be found for the
section, nothing happens and this function will return TRUE. The reason
for this is that really the intention was to have a usable, relocated section. It's not my fault if there was nothing to do..."

What I read from this is, that you can call RelocateSection() on any section without problems. This doesn't seem to be the case judging from the above code sample.


I'm trying to work on GDB, and this example has been distilled from Thomas Friedens sources in the adtools project. There seems to be a difference in the meaning of the Elf32_Shdr->sh_info member. In thomas' code it seems, that he expects it to contain the section number, but this makes GDB crash. The documentation on elf.library doesn't explain anything about the sctructures in <libraries/elf.h>, only the methods are described.

@ChrisH

Please read the previous posts again, I'm using flex here with Radeon 9250/128MB. Also, the problem is not the amount of video ram, because a comparatively high window doesn't display the same 'huckups' as a wide one.

@Elwood: If you try and run an autoscrolling screen in resolution 1280x1080 but with actual width set to 1920, you are able to reconstruct the same behavior in a smaller resolution.


Hmm, I guess people think that this is a pretty lame problem to bring up. Now consider this: I use Shell windows _all_ the time, and when opening a new shell with 'cli', you get a window, which covers the entire width of the wb screen. While I kind of like this "widescreen consol'ism", I hate the fact, that dragging the shell feels itchy, and I always end up resizing the shell to a little less than the entire width of the screen, just to get rid of this hick'ing. Is this lame? I don't know, you tell me

EDIT: Yeah I know, it's lame...

Just a note:

Has someone reported this problem (or maybe "problem")? I don't know
who to report to .


EDIT:

@MickJT:

But that doesn't make sense, since the shadow is both to the right and beneath the window, so a vertically extended window will also have a large shadow. My personal theory is, that it somehow has to do with the size of blocks or chunks that video memory can be allocated in, but then again, I don't know a thing about modern graphics chips design.

@Amigo1

Hehe, you've got a grip at the right end of the stick... now take a look at this:

http://video.google.com/videoplay?docid=7065205277695921912#



No, of course you don't have to sit and watch 2 hours of psychological internet p***ography! 8-D But really, in the end, it all comes down to us all being trapped in the greed based profit system, and theoretically we should be able to use technology to free ourselves from menial labour, making room for everyone to contribute COST FREE to the spiritual heritage of humanity .

@tonyw + nbache

As niels says, it's not the size of the window that triggers it, it's the width _independantly_ of the height. A window of the same volume, but with more height, doesn't display the same behavior.

Furthermore, the effect is the same no matter what type of window I use (I just chose Shell for the example for simplicity). If I do the same with a workbench folder, the dragging is _altogether_ slower and more jerky, but there is the very same drop in performance when I reach the _exact_ same width as with the Shell window. So no, it is not only the amount of video ram used, it is something else as well.

Also there is a small "feature", that should work in any resolution with Autoscoll turned on and has the same size as the screen: If you move a windows titlebar way up so it goes out the top of the screen, you will notice, that you cannot resize the window all the way to the bottom!

@TSK

Quote:

I think that would be too dangerous, imagine if you want to just list the contents of your system partition, but accidentally miss the correct area, setting off a complete disc copy or disc move operation! I think it would be safe and logical to just list the contents, and if you want to copy the disc, use the old method or use workbench.

@orgin
Good work. One request: Could the 'Find...' requester have support for c-string formatting, like \n, \t etc.? (At least in the 'contents' field.)

EDIT: And possibly the 'Filename' field could be _not_ case sensitive as default?

EDIT: Also, it is a little dumb, that you can't work with the file lister once you are in the search requester. For instance, if you want to edit a file instead of opening it, you can't unless you open a new filer (and you can't clone, so you need to travel the whole path for the new lister, then...) or if you remember all of the search results after closing it.

It would be good if the search box was an independent task, so you could continue using the Filer!

Would somebody please test this small but strange issue. It needs a SAM with a Radeon 9250/128MB running in 1920x1080 mode (or higher?) in ARGB32 mode.

1) Open a Shell window (works with other types of windows also, but let's keep it simple)

2) Resize it to cover the _entire_ screen width, that is all the way from left side of the screen to right side of the screen. Make the height of the window as small as possible.

3) Drag the window around. If you have the same setup as me, you should notice, that it is very jerky.

4) Resize the window, so it is just about 100 pixels less wide.

5) Drag the window around again. You should notice, that it now drags completely smooth.

How is this possible?

6) Resize the window to cover the _entire_ screen height, and make it wide enough, that it has _at least_ the same volume as the previous window when it covered the entire width of the screen.

7) Drag it around and notice, that there is no problem dragging around that much window, when it is distributed in height instead of width.

Is this a bug, or is it just something nifty with the Radeon card?

NB: Changing to a lower resolution and/or changing to 16-bit removes the issue. Also, the problem doesn't seem to be there on an AmigaOne with Radeon 9250/256MB. Strange...

@yoodoo2

Quote:

Hehe, I'm actually trying to research a bit into the subject at the moment. Since all userfriendly online resources on ppc assembly seems to point to Mac OS, it is definitely something that is missed. I might try and write a small tutorial kind of thing on the subject, and if it makes the deadline, you are of course free to use it .

How about a short section on ppc register and stack use in aos4? This would enable c-programmers to optimize small sections with asm .

@broadblues

Quote:

Hmm... Yeah, that's strange. I'm not in the same place as my Sam right now, so I will have to check when I get back in a week or so.

EDIT: I forgot to mention, that I changed from linking dynamically to linking static - this was because Edgar provided me with an updated static freetype library, so I no longer needed to use the OS .so version. I don't remember the exact phrasing of the error messages, when I link static only. I'm quite sure, that they mention REL24 relocation truncated, but I'm not sure that they mention .plt at all. I will have to check...

Quote:

Well, nothing special, really... it's "just" the libQtWebKit module It seems to consist of appr. 1500 object files...

@broadblues

Quote:

But at the moment, I'm not using any shared objects at all, so _therefore_ it's not an issue.

180 MB is the real size of the library with no debug information. It contains nearly 1500 object files . The executable itself ends up being 80 MB in size.

Quote:

I know the issue is a bit tricky, but so far I have had no issues with using AmiCygnix in combination with shared objects, probably due to the fact (as you point out yourself) that the Amicygnix libraries never calls code in the shared objects. But yeah... Maybe I'll ask Edgar to do a .so version of the libraries, hope he has time .

@tonyw

Hmm... I'm not sure, I think I'm only using newlib libraries. Anyway, all the Amicygnix libraries are static, the rest are not.

But since I just managed to compile and link the whole thing with only static objects, and since the critical factor turns out the be the -mlongcall flag, mixing shared and static objects shouldn't be the issue.

I'm not sure wether -mlongcall versus no -mlongcall is going to be an issue, though...?

@nbache

Yes, making it smaller would be a good solution. Problem is, I know so relatively little about the code I'm working with, so I wouldn't know where to start...

In the meantime, I managed to compile and link the code by means of adding -fPIC and -mlongcall to the compiler and recompiling all the Qt libs (the recompile took just about 20 hours...). Of course I can't know for sure, but I think the critical point here is the -mlongcall flag, that supposedly turns all the relative jumps and branches into absolute 32 bit ones. I'm building with only static objects now (no -use-dynld), so the shared objects V1 vs. V2 is not the issue. Also, I tried linking static only with my old objects (those without -fPIC and -mlongcall), and it still didn't work...

Problem with -mlongcall is, that the code gets slightly slower. Next thing I'm going to do is, that I'm going to link the Qt libs as all shared objects and see if I can get it working that way. As you said, Niels, I might have to split up the WebKit library in smaller parts to get it working.

Still my conclusion is, that if this is a general issue with large executables compiled with gcc on aos4, then there should be some information on how to solve it in the SDK docs, because other people are bound to get into the same problems as me in the future. Also, -mlongcall would not be a general solution unless ALL of the libraries used to link the code are compiled with this flag. As for my example, I'm just lucky, that recompiling Qt "solved" the problem.