starting embedded linux debugging - Embedded

This is a discussion on starting embedded linux debugging - Embedded ; Hi. I'm posting this in a couple of newsgroups that seem to be the most applicable to my questions. I'm about to start a development project based on the Technologic Systems TS-7250 running linux. While I have plenty of experience ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: starting embedded linux debugging

  1. starting embedded linux debugging

    Hi. I'm posting this in a couple of newsgroups that seem to be the most
    applicable to my questions.

    I'm about to start a development project based on the Technologic
    Systems TS-7250 running
    linux. While I have plenty of experience doing embedded development,
    this is my first embedded linux project. I plan on using Cygwin on the
    host side, and I'm most interested in how people debug applications and
    kernel code in this environment. I understand I need to run dbg on the
    target and a dbg stub of some type on the Cygwin side. I'd also like to
    find some type of GUI front end for the host side debugger. Any and all
    suggestions and comments are appreciated.
    Thanks.

    Lee Thalblum


  2. Re: starting embedded linux debugging

    lee_t@bigfoot.com wrote:
    > Hi. I'm posting this in a couple of newsgroups that seem to be the most
    > applicable to my questions.
    >
    > I'm about to start a development project based on the Technologic
    > Systems TS-7250 running
    > linux. While I have plenty of experience doing embedded development,
    > this is my first embedded linux project. I plan on using Cygwin on the
    > host side, and I'm most interested in how people debug applications and
    > kernel code in this environment. I understand I need to run dbg on the
    > target and a dbg stub of some type on the Cygwin side. I'd also like to
    > find some type of GUI front end for the host side debugger. Any and all
    > suggestions and comments are appreciated.




    Next time, if you have to post the same message to several
    newsgroups, please cross-post instead of multi-posting.

    I replied in comp.arch.embedded. Please look there.


    --

    Tauno Voipio
    tauno voipio (at) iki fi

  3. Re: starting embedded linux debugging

    On 2005-11-18, lee_t@bigfoot.com wrote:

    > While I have plenty of experience doing embedded development, this is my
    > first embedded linux project. I plan on using Cygwin on the host side,


    That's too bad, you have my condolences. You can probably cut the schedule
    in half by switching to a Linux host.

    > and I'm most interested in how people debug applications and kernel code in
    > this environment.


    Same as in non-embedded environments:

    1) Look at the code and think.

    2) An occasional printf or printk.

    If it that doesn't work, I create a circular buffer and log timestamped
    "events" into it, then I put in code to dump the circular buffer when
    something interesting has happened.

    > I understand I need to run dbg on the target and a dbg stub of some type on
    > the Cygwin side.


    I don't know what dbg is. I suppose you could use gdb for application code,
    but I rarely find it useful unless I'm trying to send a bug report to
    somebody based on a core dump when their program crashes. There is some
    scheme to use a debugger on kernel code, but I've never known anybody to use
    it.

    > I'd also like to find some type of GUI front end for the host side
    > debugger.


    DDD and Insight are both good GUIs for gdb.

    > Any and all suggestions and comments are appreciated.


    My main comment: debuggers are vastly overrated. You can often accomplish
    in 20 minutes of study that which would take 20 hours of stepping and
    breakpointing.

    --
    Grant Edwards grante Yow! It's so OBVIOUS!!
    at
    visi.com

  4. Re: starting embedded linux debugging

    lee_t@bigfoot.com wrote:

    > this is my first embedded linux project. I plan on using Cygwin on the
    > host side, and I'm most interested in how people debug applications and


    Half a year ago I also started my first embedded linux project. I asked
    some suppliers of hardware and software of our company if it's
    advisable to use Cygwin . The most said: "You will not be able to
    compile the kernel, because Cygwin can't handle that long path names."
    or "Most of our customers have problems with that tftp server under
    windows, it doesn't work".
    So i didn't try it as a development environment. One problem you will
    have under Windows is, that if someone sends you a tarzipped archive
    with source code and you decompress it under windows, it will overwrite
    some files, because the file system is not case sensitive. It's a small
    problem, but if more small problems ... bla bla you know.

    The company I work for doesn't allow you to install a Linux system and
    connect it to the network. So i decided to buy a couble of VMWare
    licenses and every devolper installed VMWare on his computer. Everybody
    had Debian under VMWare running. Then I had to install some packages on
    my machine and had some programs and testcode here and there, and every
    devolper had his own isolated system with different packages and tools
    installed. Very bad solution, and it was also soooo slow to compile
    under VMWare.
    Then I set up the same system on a separate computer. All developers
    are now connected over an additional network card and switches to this
    computer. Using remote shell or telnet (Cygwin), sometimes over VNC.
    Making backups from all home directories is easy, all are using the
    same environment for compiling. If you recognize that some package ist
    missing, update one computer and all developers have it.
    I think that's the best way to make the development environment for
    Unix in a M$ corporate network.

    If you are looking for a grphical frontend for gdb, try ddd.



    Enjoy your first Linux project,

    Simon


  5. Re: starting embedded linux debugging

    josimda wrote:

    > Half a year ago I also started my first embedded linux project. I asked
    > some suppliers of hardware and software of our company if it's
    > advisable to use Cygwin . The most said: "You will not be able to
    > compile the kernel, because Cygwin can't handle that long path names."


    They're not talking a lot of sense then. I have the kernel compiling
    perfectly easily under Cygwin.

    > or "Most of our customers have problems with that tftp server under
    > windows, it doesn't work".


    TFTPD32 on Windows works perfectly : http://tftpd32.jounin.net/

    > So i didn't try it as a development environment. One problem you will
    > have under Windows is, that if someone sends you a tarzipped archive
    > with source code and you decompress it under windows, it will overwrite
    > some files, because the file system is not case sensitive. It's a small
    > problem, but if more small problems ... bla bla you know.


    If you have to work a lot on both UNIX-like systems as well as Windows,
    Cygwin is possibly a useful compromise. VMWare would definitely be
    preferable, however.

    > The company I work for doesn't allow you to install a Linux system and
    > connect it to the network. So i decided to buy a couble of VMWare
    > licenses and every devolper installed VMWare on his computer. Everybody
    > had Debian under VMWare running. Then I had to install some packages on
    > my machine and had some programs and testcode here and there, and every
    > devolper had his own isolated system with different packages and tools
    > installed. Very bad solution, and it was also soooo slow to compile
    > under VMWare.


    That isn't my experience; VMWare is almost as quick as the host machine.

  6. Re: starting embedded linux debugging

    Geronimo W. Christ Esq wrote:
    > josimda wrote:
    >
    >> Half a year ago I also started my first embedded linux project. I asked
    >> some suppliers of hardware and software of our company if it's
    >> advisable to use Cygwin . The most said: "You will not be able to
    >> compile the kernel, because Cygwin can't handle that long path names."

    >
    > They're not talking a lot of sense then. I have the kernel compiling
    > perfectly easily under Cygwin.
    >
    >> or "Most of our customers have problems with that tftp server under
    >> windows, it doesn't work".

    >
    > TFTPD32 on Windows works perfectly : http://tftpd32.jounin.net/
    >
    >> So i didn't try it as a development environment. One problem you will
    >> have under Windows is, that if someone sends you a tarzipped archive
    >> with source code and you decompress it under windows, it will overwrite
    >> some files, because the file system is not case sensitive. It's a small
    >> problem, but if more small problems ... bla bla you know.

    >
    > If you have to work a lot on both UNIX-like systems as well as Windows,
    > Cygwin is possibly a useful compromise. VMWare would definitely be
    > preferable, however.
    >
    >> The company I work for doesn't allow you to install a Linux system and
    >> connect it to the network. So i decided to buy a couble of VMWare
    >> licenses and every devolper installed VMWare on his computer. Everybody
    >> had Debian under VMWare running. Then I had to install some packages on
    >> my machine and had some programs and testcode here and there, and every
    >> devolper had his own isolated system with different packages and tools
    >> installed. Very bad solution, and it was also soooo slow to compile
    >> under VMWare.

    >
    > That isn't my experience; VMWare is almost as quick as the host machine.


    In fact, I use VMware every day, but the opposite way around, to use
    some Windows CAD programs on a Linux machine. It's just as fast as the
    host, because it's running most stuff native on the host's processor
    exactly as if the host was running the embedded OS. The only performance
    hit you *might* see is with screen drawing, because it's emulating a video
    card on top of your native OS's graphics system. Nevertheless, the graphics
    performace of the CAD stuff I use is pretty much the same as it is under
    native Windows - although it's not 3d which I'm sure would suffer. Other
    IO might suffer a bit too, although that's generally not much of a
    problem.

    Do you have the guest tools installed on your VMs? They make an
    appreciable difference to graphics performance. I've not used
    many linux VMs (because it's my host so I don't generally need to)
    but I do use a Fedora Core 1 VM (on a FC4 host) to do some backward
    compatible stuff. In that instance, though, I don't use X, and I
    edit on the host, and only compile on the guest using a virtual
    network connection to the host's filesystem. You could do the same
    with a Windows guest - I also do that for some windows based DSP compilations
    with the Analog Devices DSP compiler whose name I temporarily forget.


    I wonder if the company you work for realises that a VMware hosted OS
    is effecively a Linux machine, and if you've bridged it to the network
    it's effectively connected to the network. If they're stupid enough to
    have that policy, but still want you to develop a linux project, then
    they're undoubtedly too stupid to realise that. Why on earth do they
    have such a stupid policy? If they really insist on it, can't you
    install some Linux machines, and run a completely separate network
    with a single ethernet switch connecting them? Or get a job with
    a company that's dragging itself into the last couple of decades of the
    20th century, at least?

    --
    Nobby

  7. Re: starting embedded linux debugging

    Nobody Here wrote:

    > In fact, I use VMware every day, but the opposite way around, to use
    > some Windows CAD programs on a Linux machine. It's just as fast as the
    > host, because it's running most stuff native on the host's processor
    > exactly as if the host was running the embedded OS. The only performance
    > hit you *might* see is with screen drawing, because it's emulating a video
    > card on top of your native OS's graphics system. Nevertheless, the graphics
    > performace of the CAD stuff I use is pretty much the same as it is under
    > native Windows - although it's not 3d which I'm sure would suffer. Other
    > IO might suffer a bit too, although that's generally not much of a
    > problem.


    I'd like to run Linux by default, but unfortunately in the embedded
    world a lot of tools are fixed on Windows - things like CPLD
    programmers, some JTAG devices etc which fiddle with the parallel port
    and have proprietary Windows controlling apps.

    > Do you have the guest tools installed on your VMs? They make an
    > appreciable difference to graphics performance.


    They do, but another trick I like to do is use Cygwin/X and throw an
    XDMCP session from the VM onto the Windows machine (when the VM is a
    Linux OS). That way the display rendering is done "natively" by Windows.

    > I wonder if the company you work for realises that a VMware hosted OS
    > is effecively a Linux machine, and if you've bridged it to the network
    > it's effectively connected to the network. If they're stupid enough to
    > have that policy, but still want you to develop a linux project, then
    > they're undoubtedly too stupid to realise that. Why on earth do they
    > have such a stupid policy? If they really insist on it, can't you
    > install some Linux machines, and run a completely separate network
    > with a single ethernet switch connecting them? Or get a job with
    > a company that's dragging itself into the last couple of decades of the
    > 20th century, at least?


    I assume you're talking to the previous poster. Some larger places have
    daft and all-imposing IT departments that are restrictive about whom
    they allow on the network. They can quite easily block the MAC addresses
    that the VMware bridged networking interface uses (although you should
    still be able to use it's NAT capability).

  8. Re: starting embedded linux debugging

    Geronimo W. Christ Esq wrote:
    > Nobody Here wrote:
    >
    >> In fact, I use VMware every day, but the opposite way around, to use
    >> some Windows CAD programs on a Linux machine. It's just as fast as the
    >> host, because it's running most stuff native on the host's processor
    >> exactly as if the host was running the embedded OS. The only performance
    >> hit you *might* see is with screen drawing, because it's emulating a video
    >> card on top of your native OS's graphics system. Nevertheless, the graphics
    >> performace of the CAD stuff I use is pretty much the same as it is under
    >> native Windows - although it's not 3d which I'm sure would suffer. Other
    >> IO might suffer a bit too, although that's generally not much of a
    >> problem.

    >
    > I'd like to run Linux by default, but unfortunately in the embedded
    > world a lot of tools are fixed on Windows - things like CPLD
    > programmers, some JTAG devices etc which fiddle with the parallel port
    > and have proprietary Windows controlling apps.


    Quite true. Stuff that needs the parallel port can probably be run from
    VMware, but stuff that needs to access things on the PCI bus won't work.
    I know that parallel port dongles work fine from VMware, for example,
    because it allows direct access to the hardware - well, it might not be
    direct I guess but the end result is the same. I guess it has to track
    contention with the host's accesses somewhere.

    >> Do you have the guest tools installed on your VMs? They make an
    >> appreciable difference to graphics performance.

    >
    > They do, but another trick I like to do is use Cygwin/X and throw an
    > XDMCP session from the VM onto the Windows machine (when the VM is a
    > Linux OS). That way the display rendering is done "natively" by Windows.
    >
    >> I wonder if the company you work for realises that a VMware hosted OS
    >> is effecively a Linux machine, and if you've bridged it to the network
    >> it's effectively connected to the network. If they're stupid enough to
    >> have that policy, but still want you to develop a linux project, then
    >> they're undoubtedly too stupid to realise that. Why on earth do they
    >> have such a stupid policy? If they really insist on it, can't you
    >> install some Linux machines, and run a completely separate network
    >> with a single ethernet switch connecting them? Or get a job with
    >> a company that's dragging itself into the last couple of decades of the
    >> 20th century, at least?

    >
    > I assume you're talking to the previous poster. Some larger places have
    > daft and all-imposing IT departments that are restrictive about whom
    > they allow on the network. They can quite easily block the MAC addresses
    > that the VMware bridged networking interface uses (although you should
    > still be able to use it's NAT capability).


    Yes, I was referring to the previous poster, got confused with the
    quoting levels I know about IT departments, often the company's worst
    enemy. But don't start me, I could rant ...

    --
    Nobby

  9. Re: starting embedded linux debugging

    lee_t@bigfoot.com wrote:
    > this is my first embedded linux project. I plan on using Cygwin on the
    > host side, and I'm most interested in how people debug applications and
    > kernel code in this environment. I understand I need to run dbg on the


    One problem you will run into if you try to compile a kernel under
    cygwin is that the Windows file system is not case-sensitive, and
    unfortunately there are places in the linux source tree where two files
    appear in the same directory that differ only by case. You will have to
    find these and modify the names and places they are referenced
    (#include, Makefile, etc.) before you will be able to compile the kernel.

    Gregg

+ Reply to Thread