Current_regcache looks like an easy fix it's just setting it from get_current_regcache (). I'm working my way through that and the warnings for amigaos-nat.c and will make a pull request for you when I'm done.
Merged pull-request, thanks! Through still can't compile as PC_REGNUM defined only in one function. But...
Are you sure about PC_REGNUM to be just 3? Why I ask because I compared the old GDB code in aix-thread.c file, where they use PC_REGNUM before too, and they changed it as I show before. I.e. previously it was in v6.3:
/* Predicate to test whether given register number is a "special" register. */
static int
special_register_p (int regno)
{
struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch);
return regno == PC_REGNUM
|| regno == tdep->ppc_ps_regnum
|| regno == tdep->ppc_cr_regnum
|| regno == tdep->ppc_lr_regnum
|| regno == tdep->ppc_ctr_regnum
|| regno == tdep->ppc_xer_regnum
|| (tdep->ppc_fpscr_regnum >= 0 && regno == tdep->ppc_fpscr_regnum)
|| (tdep->ppc_mq_regnum >= 0 && regno == tdep->ppc_mq_regnum);
}
And in 7.5.1 same function is:
/* Predicate to test whether given register number is a "special" register. */
static int
special_register_p (struct gdbarch *gdbarch, int regno)
{
struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
return regno == gdbarch_pc_regnum (gdbarch)
|| regno == tdep->ppc_ps_regnum
|| regno == tdep->ppc_cr_regnum
|| regno == tdep->ppc_lr_regnum
|| regno == tdep->ppc_ctr_regnum
|| regno == tdep->ppc_xer_regnum
|| (tdep->ppc_fpscr_regnum >= 0 && regno == tdep->ppc_fpscr_regnum)
|| (tdep->ppc_mq_regnum >= 0 && regno == tdep->ppc_mq_regnum);
}
See how they change PC_REGNUM
Quote:
BREAKPOINT_FROM_PC (), amigaos_find_lib () and amigaos_add_lib () are currently undefined, are they defined in the 6.3 branch anywhere?
As for amigaos_find_lib() and amigaos_add_lib(), they for loading up .sobjs , so we need to comment them out for now (via #ifndef HAVE_DLFCN_H). If you want to see how they were implemented, check this out: https://sourceforge.net/p/adtools/code ... k/gdb/gdb/solib-amigaos.c
Ack sorry, that was a total mistake! 😳 Yeah that's definitely wrong, I meant to go back and fix that and forgot to do that last night.
I'll carry on working on that file and make another pull request later. The signatures for the functions to add and remove breakpoints have changed quite a bit so that's the next thing that I'll update.
@sTix I usually sleep 6-7 hours, and the faster we deal with it, the happier we all will be :)
@billyfish Quote:
I'll carry on working on that file and make another pull request later. The signatures for the functions to add and remove breakpoints have changed quite a bit so that's the next thing that I'll update.
Yes, will be good if you can deal it the same fast as we going now :)
I checked other amigaos specific parts in older GDBs , and there is basically none. So, chances that once we deal with amigaos-nat.c we will have something working are very high.
We first will check on x1000/peg, and once all fine, then start to understand wtf with x5000.
@billyfish Btw, on the linking stage, not only BREAKPOINT_FROM_PC is missing, but also REGISTER_NAME and GDB_SIGNAL_to_name. The last one was just a mistake of mass-rename, so fixed it, and REGISTER_NAME used only in a few debugprinfs, so commented it out. Also deleted that #define PC_REGNUM 3 while was at it. All in the repo now.
I at moment commented out BREAKPOINT_FROM_PC to see what will happen if I will then load a file, set breakpoint and run it:): and at the first, amigaos_create_inferior() crashes, because of empty "exec_seglist" in IDOS->CreateNewProcTags() (probably we also need to add their safety check as well, as crashing is bad if exec_seglist will be empty by some reasons).
So, that because in old GDB, gdb/exec.c file in the exec_file_attach() we add: Quote:
Then it didn't crash, task creates, but after I have "Internal error: Can't determine the current address space of thread process 1652968448", which happens at the end of amigaos_create_inferior(), on those lines:
Quote:
/* FIXME: This is from the gdb source: You should call clear_proceed_status before calling proceed. */ proceed ((CORE_ADDR) -1, GDB_SIGNAL_0, 0);
Seems that part needs to be adapted as well. When I just comment that line out, gdb anyway exit with the same error :)
And I not sure it anyhow related to BREAKPOINT_FROM_PC commented as we even didn't enter amigaos_memory_insert_breakpoint().
I've replaced BREAKPOINT_FROM_PC, REGISTER_NAME and GDB_SIGNAL_to_name and altered the breakpoint function signatures to match the new spec. Just need to do some testing then I'll do another pull request.
I've submitted a pull request, see if it works for you
Thanks ! Will check it now !
As for those Workspace assigns that because need to deal with amiga path style (or alternatvely just add -lunix currently to not have them).
As for "illegal seek": you need to delete fully your local copy, then download fully repo, configure from scratch, etc, and then all will be fine. When it all about configure/reconfgure those things surely may have place, so fresh from scratch build are must (and it should be for now newlib of course)
@billyfish That will help for sure. Can you made such a small test case ? (i just not very well understand issue, so can't myself). If Frederik in interest to deal with in newlib testcase will help.
+1
I tried putting together a simple test program using fopen64(), fseeko64() and ftello64() and it works just fine here (I also added code for reading some data to make sure that it's really at the correct file position).
Also I'm pretty sure I used fseeko64() in my ports of unrar and p7zip and I didn't have any problems there.
Apart from 64-bit vs 32-bit offsets there is little to no difference between the implementations of fseeko64() and fseeko()/fseek() functions.
@billyfish I merged all your changes, just not via pull-request (as it has some conflicts), but manually one by one with pointing out (c) billyfish of course. Will add to the repo -lunix currently and amigaos4 ifndef for gdb_wait_for_event with warning that it needs to be deal with and not forgotten. So then clean rebuild and all should be fine.
Ah! Thanks for coming to the rescue with -lunix, works perfectly. So I currently have a crash in amigaos_create_inferior () when you run a program within gdb. Going by the debug printouts it is crashing in dos library from this call
Does anyone see anything immediately wrong with that call before I head off to the os autodocs ? exec_seglist being 0 maybe? I haven't used CreateNewProc () before so I'm just guessing
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)
I just do not know how correct is to follow that kind of hacks? (i mean touching gdb/exec.c). But once I add it like that exec_seglist is not 0 anymore, then it goes further, and then we have another issue which I wrote in that post "Internal error: Can't determine the current address space of thread process 1652968448". The issue happens from gdb/target.c.
Through firstly, we probably need to agree on how to going next. Should we change gdb/exec.c as it was in old GDB? Or there some better ways?
1. updated configure line in readme with adding -lunix, so just copy+paste it and no amiga paths issues for now (as well as created ticket about dealing with amiga paths natively without -lunix: https://github.com/kas1e/gdb/issues/5)
So, for now, anyone who download the whole repo, and just copy+paste configure/make commands from the readme will have a working binary with the ability to load dwarf4 bins and list the source of it and even disassembly it like "disas main" or "disas _start", etc.
Now, some real work starts probably. We need to agree if we touch gdb/exec.c as it was in old gdb, or find out a better way. After that, we need to understand why "can't determine the current address space of thread process" happens.
The ftello64() call that returns ESPIPE ("Illegal seek"), is that on a file handle opened by fopen64() or is it a regular fopen() one? If it's the latter it would explain the error.
The newlib 3.1.0 fseeko64() falls back on regular fseeko() if it's called on a FILE pointer not from fopen64(), a feature that I will be adding to our newlib port as well in the next beta release.
Great idea on adding the tickets, my memory is rubbish at the best of times so having those to look through is the way forward. I'll have another look at the code tomorrow and we can try and work out how to get the exec part sorted. Does that sound ok to you?
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
