(unknown)
Max Larsson via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CAGKMySXgjtxvrUfySTtCU6mQnPf8cdGk1nnbeKRnVwfbQ_ConQ@mail.gmail.com> |
Hi everyone, I/We (The others do the testing, I do the coding) do have a problem the our port of GDB to AmigaOS4 (PowerPC, big-endian, 32bit cpu, ELF, single/shared address space). My current port is based around GDB version 14, works in regards that it compiles,runs, can start inferiors etc. Simple debug cases works already. My problem in some cases are breakpoints. And the issue arise from the fact that the target has a single address space for all running programs. So when the inferior is launched, my nat tells the gdb core on which address the exe is really running. So if gdb file command is use to read an exe, gdb uses the address for the exe as defined in the elf file. So if i disas the _start function it show me all the assembler code starting with an address 0x010000054. So long everything is fine. Now I tell gdb to set an break point on that address and run the exe. Now the (my) nat loads the exe, figure out where the OS loaded it and correct the addresses in the section_offets and calls objfile_relocate. As more or less next step gdb tells the nat to place a breakpoint at the address 0x010000054 via (xfer_partial). And that is my problem that address isn't valid. I would have assumed that gdb is smart to know that if the exe is relocated the defined breakpoints needs to be adapted. So Am I wrong, do I need to check all address passed in in xfer_partial and do my own mapping in my nat? Or is there some magic hidden settings I need to activate? Or theoretically it should work, but because modern OS separates each exe in their own virtuell address space the feature hasn't been tested for years and thus wen bust? Any hint/information is highly welcome. kind regards Max Larsson