multiarch x86_64 target

multiarch x86_64 target

[Jiri Smid]

  Hello,

  I am converting x86_64 target to multiarch as you wanted. The bfd
architecture for both i386 and x86_64 is bfd_arch_i386. And these
targets are diferentiated by machine type.
  Due to the i386 target is not yet multiarched I have a problem how to register
x86_64 in gdb.
  I have created function i386_gdbarch_init which behaves that if target
vector for machine type differs from bfd_mach_x86_64 should be created
then internal_error(Not yet implemented) is invoked.
  But when the gdb starts up then there is created target vector for default
machine type - bfd_mach_i386_i386. Thus gdb can't run.

  Do you have any ideas how to solve it?

-- 
Jiri Smid

---------------------------------------------------------------------
SuSE CR, s.r.o.                                 e-mail: smid@suse.cz
Drahobejlova 27                                tel:+420 2 83095 373
190 00 Praha 9                                 fax:+420 2 83095 374
Ceska republika                                http://www.suse.cz

Re: multiarch x86_64 target

[Andrew Cagney]

>  Hello,
> 
>   I am converting x86_64 target to multiarch as you wanted. The bfd
> architecture for both i386 and x86_64 is bfd_arch_i386. And these
> targets are diferentiated by machine type.
>   Due to the i386 target is not yet multiarched I have a problem how to register
> x86_64 in gdb.
>   I have created function i386_gdbarch_init which behaves that if target
> vector for machine type differs from bfd_mach_x86_64 should be created
> then internal_error(Not yet implemented) is invoked.
>   But when the gdb starts up then there is created target vector for default
> machine type - bfd_mach_i386_i386. Thus gdb can't run.

In x86-64-tdep.c?

>   Do you have any ideas how to solve it?

Ulgh!  For the short term, I'd just ignore it - return the x86-64 vector 
regardless.  The one thing I wouldn't be trying to do is trying to 
multi-arch the x86.

I should also note a known bug related to this (it won't affect your 
code).  The architecture selection mechanism currently doesn't handle 
multiple registrants for the same architecture (eg raw x86 vs 
x86-linux).  x86 vs x86_64 is going to be another example of this.  Once 
the x86 is multi-arched a solution will be needed.

	Andrew

help about debugging embedded linux by GDB target remote debugging

[agan]

hi,
    I want to use GDB for mips , to remote debugging  vmlinux(embedded linux
for mips) , I have builded vmlinux by adding gdb_stub.c for mips , add
set_debug_traps() , and breakpoint() function into vmlinux top, and
configure  debuging vmlinuc kernel by GDB  remote serial line.
    but I cannot get remote serila connection by typing 'target mips
/dev/ttyS0' or 'target remote /dev/ttyS0'  ; what the matter that I face is
the same as the attach mail archive"Problem on gdb (insight) under cgywin!
".
    please help me find tha matter. tks a lot.

    my debugging environment:
host:
        cpu arch: x86, os: linux (redhat 6.2) ,
        run  gdb: for target MIPS target ( configure  --target=mips-elf )
target:
        cpu arch: mips, os:wince 3.0( pocket pc) ,
        i download the vmlinux into the pocket pc, and start to run it.

matter:
        gdb cannot connect vmlinux(gdb_stubs) by serial line.


best regards.
agan shao











----------------------------------------------------------------------------
------------------

attach file ( get from GDB maillist :
                    Date: Wed, 18 Apr 2001 10:08:40 -0400 )

<Obvious question:
<To use GDB this way you must be running the GDB stub on your target
<board. Are you running the stub?

<What are you running on the 68K target?

<Also if this is an embedded target then are you sure that the
<console_output is being piped through the GDB stub?

<At 10:13 AM 4/18/01 +0800, you wrote:
>Hi:
>     I've build insight under cygwin for my m68k target.
>     I have some problems.
>
>     1.First I execute m68k-coff-gdb.
>        and open a m68k-coff image, but a error occur
>         => Error loading "...../test.coff"
>             bad offset (0x12264) in compilation unit header(offset 0x0+6)
>         The test.coff is workable when running in target.
>         So I have no idea about why GDB don't accept the coff image?
>
>    2.Using File->target setting,I set target using
Remote/serial,57600,com2.
>       and Run->connect to target.
>       After a long time,there is a message->"connected successfully".
>       But When I ececute a "console_output" command at the target,
>       sending a string like "Hello,Insight" to insight.
>       I think I should see this string at the console window?
>       But nothing there.Do I make any mistake?
>
>    3.I try another method.
>       I open insight and use console window to connect to target.
>       (gdb)target remote com2
>       After long time,the message appear."Ignoring packet
error....continue"
>       Why?
>
>    4.Because I only see baud setting and com port selection in insight.
>       But I set following configuration in target's uart:
>       =>baudrate 57600,8-bits data,1 stop-bit,no parity.
>       How do I make sure  inshgt on the host can recognize this
>configuration at the target?
>
>    5.I've see a message at the ecos-discuss mailing list about ignoring
>packet error
>       The author said he wired up the connector at the PC end to connect
>RTS&CTS,DSR&DTR,
>       and permanently enable DCD.Then it works fine?
>       What did he mean? Do I need a special serial line?Or I can use
common
>serial line that buy from store.
>
>Thank very much!
>B.R.
>

Re: multiarch x86_64 target

[Mark Kettenis]

Andrew Cagney <ac131313@cygnus.com> writes:

> Ulgh!  For the short term, I'd just ignore it - return the x86-64 vector 
> regardless.  The one thing I wouldn't be trying to do is trying to 
> multi-arch the x86.

Well, I am :-).  It's nowhere close to being finished, but I am making
progress.  I think the current situation is already a lot better than
when you started your multi-arch work.

A big problem is the fact that there are a lot of unmaintained x86
targets.  I'd like to obsolete a few of them once we get GDB 5.1 out
of the door, but even then there are targets that I cannot test, and
will be hard to multi-arch.  I'm thinking about multi-arching only a
subset of the x86 targets, leaving the others basically alone.  Would
that be acceptable to you?

Anyway, once I've multi-arched the x86, whe should probably integrate
the x86_64 target a bit closer with it.

Mark