Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
95 user(s) are online (78 user(s) are browsing Forums)

Members: 0
Guests: 95

more...

Support us!

Headlines




« 1 2 3 (4) 5 6 7 ... 9 »


Re: GDB
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7033
@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

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GDB
Just popping in
Joined:
2011/7/20 20:01
From In the sticks
Posts: 178
@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
   Report Go to top

Re: GDB
Just popping in
Joined:
2006/11/30 11:59
From Lund, Sweden
Posts: 153
@billyfis
@kas1e

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

   Report Go to top

Re: GDB
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7033
@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.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GDB
Just popping in
Joined:
2011/7/20 20:01
From In the sticks
Posts: 178
@sTix

You're very right!

   Report Go to top

Re: GDB
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7033
@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.



_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GDB
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7033
@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().


_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GDB
Just popping in
Joined:
2011/7/20 20:01
From In the sticks
Posts: 178
@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.

   Report Go to top

Re: GDB
Just popping in
Joined:
2011/7/20 20:01
From In the sticks
Posts: 178
@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.

   Report Go to top

Re: GDB
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7033
@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)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GDB
Just can't stay away
Joined:
2006/11/30 11:30
From Finland
Posts: 1801
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.

   Report Go to top

Re: GDB
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7033
@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.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GDB
Just popping in
Joined:
2011/7/20 20:01
From In the sticks
Posts: 178
@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

   Report Go to top

Re: GDB
Just popping in
Joined:
2011/7/20 20:01
From In the sticks
Posts: 178
@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

   Report Go to top

Re: GDB
Amigans Defender
Joined:
2006/12/2 13:27
From Taranto, Italy
Posts: 964
@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...
   Report Go to top

Re: GDB
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7033
@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?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GDB
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7033
@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
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GDB
Just can't stay away
Joined:
2006/11/30 11:30
From Finland
Posts: 1801
@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.

   Report Go to top

Re: GDB
Just popping in
Joined:
2011/7/20 20:01
From In the sticks
Posts: 178
@kas1e


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

   Report Go to top

Re: GDB
Just popping in
Joined:
2011/7/20 20:01
From In the sticks
Posts: 178
@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?

   Report Go to top


« 1 2 3 (4) 5 6 7 ... 9 »



[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project