Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
37 user(s) are online (20 user(s) are browsing Forums)

Members: 0
Guests: 37

more...

Headlines

 
  Register To Post  

« 1 2 3 (4) 5 6 7 ... 10 »
Re: GDB
Home away from home
Home away from home


See User information
@billyfish

Quote:

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 >= && regno == tdep->ppc_fpscr_regnum)
      || (
tdep->ppc_mq_regnum >= && 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 *gdbarchint 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 >= && regno == tdep->ppc_fpscr_regnum)
      || (
tdep->ppc_mq_regnum >= && 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?


in gdb/gdbarch.h they have in 6.3 that:

Quote:

#if !defined (GDB_TM_FILE) && defined (BREAKPOINT_FROM_PC)
#error "Non multi-arch definition of BREAKPOINT_FROM_PC"
#endif
#if !defined (BREAKPOINT_FROM_PC)
#define BREAKPOINT_FROM_PC(pcptr, lenptr) (gdbarch_breakpoint_from_pc (current_gdbarch, pcptr, lenptr))
#endif


While in 7.5.1 I didn't see it anymore.

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

line 95, and line 119

Go to top
Re: GDB
Just popping in
Just popping in


See User information
@kas1e

Quote:

Are you sure about PC_REGNUM to be just 3?


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.


Edited by billyfish on 2021/2/24 9:52:52
Go to top
Re: GDB
Just popping in
Just popping in


See User information
@billyfis
@kas1e

Perhaps there's some timezone confusion going on here, but I get the impression that you guys don't sleep enough :)

Go to top
Re: GDB
Home away from home
Home away from home


See User information
@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.

Go to top
Re: GDB
Just popping in
Just popping in


See User information
@sTix

You're very right!

Go to top
Re: GDB
Home away from home
Home away from home


See User information
@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.



Go to top
Re: GDB
Home away from home
Home away from home


See User information
@billyfish

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:

#if defined(__amigaos4__)
amigaos_exec_file_attach_hook(filename, from_tty);
#endif


and in exec_close_1() we add:
Quote:

#if defined(__amigaos4__)
amigaos_exec_close_hook(quitting);
#endif


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().


Go to top
Re: GDB
Just popping in
Just popping in


See User information
@kas1e

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.

Go to top
Re: GDB
Just popping in
Just popping in


See User information
@kas1e I've submitted a pull request, see if it works for you. I'm getting weird issue that https://github.com/kas1e/gdb/tree/81af ... 013839d99f854762f33b2c74c allows me to do

file helloworld


and I get the illegal seeks

but all builds from https://github.com/kas1e/gdb/tree/b880 ... 6e85518997b5be86053dce255 onwards give me requester asking for

/usr/local/lib/debugWorkspace:
/usr/local/share/gdb/auto-loadWorkspace:


workspace: being the partition with helloworld on. The bits before workspace: are paths defined by bfd so at least I can see where they come from

The only thing changed between those two revisions are the "o64" undefs, etc.

Does it all work for you? hopefully it's some stupid setting on my system.

Go to top
Re: GDB
Home away from home
Home away from home


See User information
@billyfish
Quote:

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)

Go to top
Re: GDB
Just can't stay away
Just can't stay away


See User information
Quote:

@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.

Go to top
Re: GDB
Home away from home
Home away from home


See User information
@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.

Go to top
Re: GDB
Just popping in
Just popping in


See User information
@salass00

I'll try and see if I can extract the bits that gdb is doing into a separate program and get that to you

Go to top
Re: GDB
Just popping in
Just popping in


See User information
@kas1e

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

debug_data.current_process IDOS->CreateNewProcTags(
            
NP_Seglist,         exec_seglist,
            
NP_FreeSeglist,     FALSE,
//            NP_Child,            TRUE,
            
NP_Name,            exec_file,
            
NP_Cli,             TRUE,
            
NP_Arguments,       args,
            
NP_Input,            IDOS->Input(),
            
NP_CloseInput,      FALSE,
            
NP_Output,          IDOS->Output(),
            
NP_CloseOutput,     FALSE,
            
NP_Error,           IDOS->ErrorOutput(),
            
NP_CloseError,      FALSE,
            (
homedir NP_ProgramDirTAG_IGNORE),homedir,
            
TAG_DONE
        
);



with

exec_seglist 
exec_file  
"/Workspace/helloworld" 
args "" 
homedir "NULL"


when I do a run within gdb on helloworld

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

Go to top
Re: GDB
Amigans Defender
Amigans Defender


See User information
@salass00

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'm really tired...
Go to top
Re: GDB
Home away from home
Home away from home


See User information
@billyfish
Quote:

exec_seglist being 0 maybe? I haven't used CreateNewProc () before so I'm just guessing


Yeah, exec_seglist 0 (and we need to add their check on, and exit properly instead of crash). You just missed the post about :) #67 one: https://www.amigans.net/modules/xforum ... id=123390#forumpost123390

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?

Go to top
Re: GDB
Home away from home
Home away from home


See User information
@billyfish

I updated the repo a bit:

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)

2. and our POSIX workaround (as well as creating for it a ticket so we did not forget to fix it: https://github.com/kas1e/gdb/issues/4)

3. some cosmetic cleanups.

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.


Edited by kas1e on 2021/2/24 20:56:21
Go to top
Re: GDB
Just can't stay away
Just can't stay away


See User information
@billyfish

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.

Go to top
Re: GDB
Just popping in
Just popping in


See User information
@kas1e


Ah sorry for missing that messag, you were ahead of me in spring the problem as seems to offered be the case 😊

Go to top
Re: GDB
Just popping in
Just popping in


See User information
@kas1e

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?

Go to top

  Register To Post
« 1 2 3 (4) 5 6 7 ... 10 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project