@salass00

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.

@billyfish

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.

@salass00

Will (or is) gdb be able to also genug shared builds?
Will it be possible to trace those shared build crashes in scummvm?

@Raziel
Asking the wrong one again ?:)

Quote:

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:

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

Thank you, yes missed changing the @

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!

@billyfish
Quote:

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.

@All

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:



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:



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:

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:




And add this:

Quote:

But this one never called, instead still pure exec:target_xfer_partial is called still.

EDIT:

I then build exactly the same 7.5.1 version of GDB on my linux/x64 , enabled debug in gdb/target.c, and that how it looks like there:



As can be seen those "nulls" in the exec:target_xfer_partial at the begining are fine, and then on x86 we have:

Quote:

So on our side we didn't reach "target_thread_address_space" and fail right after "target_thread_architecture".

And our failing part in gdb/target.c are:




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.

@afxgroup

Quote:

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

target_thread_architecture (process 27384) = 0x15791d0 [powerpc:common]

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.

Anyone ?:)