I'll dig through the code to find out where the file is opened and let you know tomorrow. Given that the code used was real_fseek in bfdio.c, I'd guess that some printfs to lines 121-124 in that file will show which one was called or checking for where HAVE_FOPEN64 is defined. I can checkout the branch before we fixed it tomorrow and let you know if that's ok.
You should be able to check with "if (fp->_flags & __SL64)" whether the file is 64-bit enabled, just to see if that is the cause of the problem or not.
Will (or is) gdb be able to also genug shared builds?
If you ask if the current GDB from SDK is able to debug binaries that use sobjs: it can probabaly in some sort (there were some sobjs related code in the old GDB for sure), but all newer gcc produce dwarf4 debug binaries which old GDB can't handle, so even if it can, you probably will be out of luck, because either scummvm or one of the link libs surely builds with newer GCC (meaning GDB will say "sorry, dwarf4 support, can handle only dwarf2).
As for "will new version support it": If you will read the whole thread (boring, yes), you will see that we currently disable sobjs, because at first, we need to make a new version that works everywhere as expected with the usual apps, and then make it works on x5000 too. And only when everything will be good, and if there nothing left to fix, and if there will be wish from any developer to deal with, then sobjs support can be added probably.
But better don't hold the hope for. Sobjs on amigaos4 known to be sucking crap and I are sure once someone will start to dig in to make proper support of it in GDB, he will meet with all sort of limitations, shortcomings and unimplemented features which can't be a workaround.
Quote:
Will it be possible to trace those shared build crashes in scummvm?
We even didn't have a proper debugger to debug plain binaries, taking aside that custom-hack-support of sobjs we had in os4.
And, to add, GDB will not offer you a lot in comparison with stack trace from GR if you didn't know assembly code. In GDB you surely can do a lot of things, but they in no way mean "now you will know why it crashes exactly, only because you run binary inside of GDB".
GDB is good for many other things as well, like, for example, you run a program, and it NOT_CRASHED but reacts wrong and you don't know why. So you can break executions, and see stack, registers, memory, etc, etc. It's more like a tool for developers, to help them.
kas1e described it well, I'd just add a couple of extra things. With gdb you can set breakpoints at any point in a program which will halt the program at that point so you can inspect variables, etc and can step through the program line by line. It will also allow you to check c variables and even call functions to check their results within gdb itself. It makes development so much easier!
I'll have another look at the code tomorrow and we can try and work out how to get the exec part sorted
I checked morphos' GDB 8.3 port, and they surely didn't have anything modified in exec.c. Through exec.c of GDB8.x changed pretty much and didn't contain anymore those functions which 6.3 or 7.5.1 still has. See how it were done in 6.3 one: https://sourceforge.net/p/adtools/code ... tree/trunk/gdb/gdb/exec.c (check for amigaos4 ifdefs)
As a side note, I build GDB with support of ncurses (use PDCurses, which is an alternative but with SDL2 implementation), so we can run gdb over "TUI", like "gdb -tui" and:
(click open in new tab for full-size):
Through crashes in rl_dispatch_subseq() once it tried to operate with.
So, while we think if it better or not to attach/close the file via hooks inside of exec.c as it was done in our old gdb 6.3a, I made it the same, together with enabling debug output and with enabling debug gdb/target.c in both, our old gdb 6.3a and new 7.5.1 to compare what we should have and what we have. So, there results:
GDB 6.3.a
That our current SDK version, and when we run this gdb over test binary, doing a list, then set a breakpoint and type "run", that what we have in the console with enabled debug in a target.c:
3/0.Work:aa> gdb_6_3a_clib2 test_dwarf2
GNU gdb 6.3 (AmigaOS build 20050719)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "ppc-amigaos"...
(gdb) list
list
target_xfer_memory (0x7fd4944c, xxx, 4, read, xxx) = 0
1 #include <stdio.h>
2 int main()
3 {
4 printf("asdf\n");
5 }
(gdb) break 1
break 1
Breakpoint 1 at 0x7fd4944c: file test.c, line 1.
(gdb) r
r
Starting program: Work:aa/test_dwarf2
target_xfer_memory (0x7fd4944c, xxx, 4, read, xxx) = 4, bytes = 94 21 ff f0
target_xfer_memory (0x7fd4944c, xxx, 4, write, xxx) = 4, bytes = 7d 82 10 08
target_insert_breakpoint (0x7fd4944c, xxx) = 0
target_fetch_registers (pc) = 00000000 0x0 0
target_terminal_inferior ()
target_resume (-1, continue, 0)
target_wait (-1, status) = 1653873664, status->kind = stopped, signal = SIGBUS
target_fetch_registers (pc) = 023aecf0 0x23aecf0 37416176
target_terminal_ours_for_output ()
Program received signal SIGBUS, Bus error.
target_xfer_memory (0x7fd4944c, xxx, 4, write, xxx) = 4, bytes = 94 21 ff f0
target_remove_breakpoint (0x7fd4944c, xxx) = 0
target_terminal_ours ()
target_fetch_registers (r1) = 02249f90 0x2249f90 35954576
0x023aecf0 in ?? ()
target_create_inferior (Work:aa/test_dwarf2, , xxx, 1)
(gdb)
That Sigbus error with 0x023aecf0 in ?? () there mean not a deal for us (that x5000 issue we had to deal with).
GDB 7.5.1
Now, that what we have when we doing the same (enable debug in gdb/target.c, add attaching a file via a hook in exec.c, etc). There is the console output:
10/0.Work:aa> gdb_751 test
GNU gdb (GDB) 7.5.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "ppc-amigaos".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /Work/aa/test...done.
(gdb) list
list
target_memory_map ()
target_get_section_table ()
exec:target_xfer_partial (2, (null), 0x62662488, 0x0, 0x10004d4, 4) = 4, bytes = 3d 20 01 00
target_get_section_table ()
exec:target_xfer_partial (2, (null), 0x62662558, 0x0, 0x10004d4, 4) = 4, bytes = 3d 20 01 00
1 #include <stdio.h>
2 int main()
3 {
4 printf("asdf\n");
5 }
(gdb) break 1
break 1
target_get_section_table ()
exec:target_xfer_partial (2, (null), 0x62662458, 0x0, 0x10004d4, 4) = 4, bytes = 3d 20 01 00
target_get_section_table ()
exec:target_xfer_partial (2, (null), 0x626626d0, 0x0, 0x10004d4, 4) = 4, bytes =
3d 20 01 00
Breakpoint 1 at 0x10004d4: file test.c, line 1.
(gdb) r
r
Starting program: /Work/aa/test
[New process 1755977616]
target_thread_architecture (process 1755977616) = 0x61eb0018 [powerpc:common]
target_terminal_ours ()
../../gdb/target.c:3242: internal-error: Can't determine the current address space of thread process 1755977616
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
../../gdb/target.c:3242: internal-error: Can't determine the current address space of thread process 1755977616
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
***Command 'gdb_751' returned with unfreed signals 80000000!
10/1.Work:aa>
See, output and calling function pretty differently. I do check both GDB sources, and for example, target_memory_map() and target_get_section_table() are new things not present in the old gdb, so that expected that they are called. But next, we fail in target_thread_architecture() with "Can't determine the current address space of thread process 1755977616"
The same happens if I test the new version on pegasos2 too, so it's not x5000 related.
I see that in old amigaos-nat we have implemented "amigaos_xfer_memory", which is then used. Through see what we have at end of amigaos-nat:
Quote:
/* FIXME use to_xfer_partial instead of deprecated_xfer_memory */ /**/amigaos_ops.deprecated_xfer_memory = amigaos_xfer_memory;
So it was already deprecated in 6.3a, and probably now (and in our in 7.5.1 too) "amigaos_xfer_partial()" is should be used instead.
At the moment i tried to just add into amigaos-nat that:
/* Fall-back to the "main" address space of the inferior. */
inf = find_inferior_pid (ptid_get_pid (ptid));
if (inf == NULL || inf->aspace == NULL)
internal_error (__FILE__, __LINE__,
_("Can't determine the current "
"address space of thread %s\n"),
target_pid_to_str (ptid));
return inf->aspace;
}
Added few printfs, and:
1). for first we never go inside of the for (t = current_target.beneath; t != NULL; t = t->beneath) loop. 2). when we "fallback", inf is NULL too.
Edited by kas1e on 2021/2/26 4:26:09 Edited by kas1e on 2021/2/26 4:31:20 Edited by kas1e on 2021/2/26 4:36:48 Edited by kas1e on 2021/2/26 4:38:03 Edited by kas1e on 2021/2/26 4:52:45 Edited by kas1e on 2021/2/26 19:23:23 Edited by kas1e on 2021/2/26 19:23:55 Edited by kas1e on 2021/2/26 19:28:36 Edited by kas1e on 2021/2/26 19:48:05 Edited by kas1e on 2021/2/26 19:54:24 Edited by kas1e on 2021/2/26 20:22:34
Unlucky fseeko64 is not working correctly on newlib. Don't know if something has broken from your tests but i've tried your p7zip with an 8GB file and it fail. I've tested it with my clib2 version i'm using now and it is working. So something has changed in newlib code (most probably)
As a test I just used p7zip on my beta installation to create a 6.5GiB archive file from ~11GiB worth of music files and it worked without problems, though it took about 14 hours to finish.
I then ran "7za t" on the archive on both AmigaOS and Ubuntu and both reported that the archive was okay and with no errors.
Then I extracted the archive on AmigaOS using the p7zip port again and this also worked fine with no errors (I also compared md5sums on a couple of the extracted files and they do match the originals).
What file system are you using? JXFS has broken relative seeking as well as other bugs that will never be fixed because it is no longer developed and should not be used anymore. For the tests above I used SFS\2 partitions (ssh2-handler was used to transfer the archive to my Ubuntu system for the test there).
@All Installed PPC Linux on my x5000 (Fienix one), and build GDB 7.5.1 there as well, with also enabling debug in the gdb/target.c: to see, maybe with PPC things a bit different than on x64. And loading a simple test case with "list" and "break 1 / run", as in previous tests with our current GDB 6.3a from SDK/ GDB 7.5.1 on os4 / GDB 7.5.1 linux/x64, but now on Linux PPC on x5000 looks like this:
So, the same target_memory_map() and target_get_section_table() at the begining, the same "nulls" in the begining of the exec:target_xfer_partial() so all fine there.
And when we set break and do run, then it also show after every
then : target_thread_address_space (process 27384) = 1
So, for us as can be seen target_thread_address_space() is not happens.
Dunno what the problem is: or the way of calling functions changes, and we need to implement some other one, or we just need to deal with all those "infs / ptids" so that stuff will work correctly.
To make our life easier I commit another change where add to the gdb/exec.c necessary changes, so exec_seglist is no more NULL, and we going further.
And then, we meet with the error about which I told in the last posts: ../../gdb/target.c:3242: internal-error: Can't determine the current address space of thread process.
target_thread_address_space() is in that gdb/target.c, and if we add there printfs, then :
1). for first we never go inside of the for (t = current_target.beneath; t != NULL; t = t->beneath) loop. 2). when we "fallback", inf is NULL too.
It feels that we have issues with "pids" and whole "inf" pointers.
For enabling debug output in gdb/target.c, on line 208 of that file change static int targetdebug = 0; to static int targetdebug = 1;
@sTix Maybe you also can have a look at that problem we had now ?:)
@All Almost every os4 developer all the time says that we need a debugger, and want to have working GDB. Now, things can be done, if any of us bit by bit will fix issues. Is no one interesting in spending a day/two on that issue on which we stuck for a damn week already?
Edited by kas1e on 2021/3/6 8:18:47 Edited by kas1e on 2021/3/6 8:19:45
Sorry, home schooling keeps getting in the way! After Monday, it will be easier as they'll be back in school. As for GDB, we've made good progress, we'll get there I've been taking a look at the IExec debug interface too
Just like billyfish, I'm also a bit bogged down at the moment. But I don't think being stuck for a week is a disaster. I think this will take quite some time, it's not a minor bump, it's catching up with 10+ years of work in a project that has 10+ times as many developers as the complete Amiga community has, all flavours included. I really hope I'm wrong though :)
I've been taking a look at the IExec debug interface too
Issues with x5000 surely can wait till we make basics works on other machines where it should work.
First, we need to understand why we "Can't determine the current address space of thread process". My guess is about inf/ptid things. Maybe even our new changes may cause this? Alternatively, there some functions which need to be implemented in the AmigaOS-nat part, and as example we can take any other one, like, for example, "rs6000-nat.c".
@sTix Quote:
But I don't think being stuck for a week is a disaster.
Disaster is a loosing of interest which we had now :) Things can be done much faster if developers have just lost an hour in a day on GDB, which for 10 years most developers ask for. And we can have a working version just in few weeks. Sadly, while I always find the time, I never was a developer, because of which need always beg someone else :( And when there is no progress in days and weeks, and even no sign of it, it just makes it feels like a dead-end, like only I have interest in.
The reason I've been looking at the debug interface isn't for the x5000, it's that functions like ObtainDebugSymbol() and StackTrace() may be what we need to be able to do things like inspect a variable by its name rather than having to inspect registers or anything like that.
@billyfish :) Yeah... That will be helpful once we deal with the main issue we had now. But without fixing the current issue we can't progress further.
1). for first we never go inside of the for (t = current_target.beneath; t != NULL; t = t->beneath) loop.
2). when we "fallback", inf is NULL too.
Ok here's what I've found so far. The inferior created by amigaos_create_inferior () is never added to the inferior list in inferior.c. If I add
add_inferior ((int) debug_data.current_process);
then it gets added to the list and
inf = find_inferior_pid (pid);
on target.c:3249 now finds the inferior but it has aspace = NULL.
So add_inferior () isn't enough to get the aspace and pspace parts of the resulting inferior set up.
Changing the added code to
inf_p = add_inferior_with_spaces ();
if (inf_p)
{
inf_p -> pid = (int) debug_data.current_process;
}
seems a bit hacky but then gdb runs all the way through without crashing but not with its functionality all working.
Now add_inferior_with_spaces () adds a new address space rather than all of the gdb inferiors sharing a single address space which is because gdbarch_has_shared_address_space() returns 0.
So does OS4 have a shared address space? If so we can call set_gdbarch_has_shared_address_space() and may get further. Otherwise we need to set up the inferior with the correct aspace, pspace values, etc.
I checked other "nat" realizations for other platforms, and seems that in general, we do it still correct and as expected even in 7.5.1: we fill the "struct target_ops *xxxx"; (in our case we call it like "static struct target_ops amigaos_ops";) then fill necessary bits, and call "add_target(&xxxx);" Then if we have filled "to_create_inferior" with our inferior function it called them when need it. Just in our case, for some reason, it never added to the inferior list in inferior.c anymore.
But I have never seen any other platform direct call to add_inferior_with_spaces().
My bet we then need fully rewrite this amigaos_create_inferior() just from scratch, with our own code. Without needs to worry wtf there from before time (and in that process, we will then understand how it all works).
And anyway, is it mean that this part of code in our current amigaos_create_inferior() just doing nothing ? :
So does OS4 have a shared address space? If so we can call set_gdbarch_has_shared_address_space() and may get further. Otherwise we need to set up the inferior with the correct aspace, pspace values, etc.
I can ask in os4beta/dev maillists, or Thomas directly about. But what you mean by OS4 have a shared address space? Shared with what/by what ?:) As I aware all amigaos4 memory is shared, and everyone can access any part of it. As well as we have "shared" tags when allocating memory too (but I suck at those details)
Edited by kas1e on 2021/3/8 18:59:35 Edited by kas1e on 2021/3/8 19:01:30
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
Donate
I've been taking a look at the IExec debug interface too 
