Author Topic: draft: GDB-stub goes to vhdl, how good is this idea ?  (Read 6529 times)

0 Members and 1 Guest are viewing this topic.

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
draft: GDB-stub goes to vhdl, how good is this idea ?
« on: December 30, 2015, 10:06:28 am »
This is an idea, just an idea, a friend of mine has developed his own softcore recicling the debug tap from the OpenCores in OpenRISC's ADI-TAP, and then has complained that the ADI-JTAG stub is too complex, so he wants the whole engine written in VHDL, removing the jtag and using an uart protocol (GDB usually talks over an ASCII protocol, over the uart), so he'd like to develop the GDB-stub in vhdl and able to interface the CPU and to interact with the GDB-host (PC side, /usr/bin/gdb) over the serial line.

guys, what do you think :popcorn: ?
« Last Edit: January 14, 2016, 02:08:37 am by legacy »
the Bunker is open!
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 4328
  • Country: us
    • Personal site
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #1 on: December 30, 2015, 08:15:04 pm »
guys, what do you think :popcorn: ?
Creating a parser for a serial protocol in VHDL will involve a huge state machine. And he already has a state machine - his CPU :) Just instantiate another core (with no debug components and simplified, if possible) and write a parser in assembly. If he feels confident he can make it in VHDL, it will be a piece of cake to write interface software without a debugger.
Alex
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #2 on: December 30, 2015, 09:52:12 pm »
so basically it's a bullshit, like the worst idea ever  :-DD
the Bunker is open!
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 4328
  • Country: us
    • Personal site
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #3 on: December 30, 2015, 09:56:46 pm »
Not necessarily. It is unconventional, for sure, but can be done if needed.

But GDB is useful if you have support for that processor in GDB and corresponding libraries. Having a tool chain will nor hurt either. Does he have al of this? Or is his core just an implementation of existing architecture?
Alex
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #4 on: December 30, 2015, 10:11:23 pm »
But GDB is useful if you have support for that processor in GDB and corresponding libraries.
Having a tool chain will nor hurt either. Does he have al of this?
Or is his core just an implementation of existing architecture?

he has developed a pipelined MIPS-1 (R2K) soft core, without FPU and with reduced interrupts support (Cop0)
it does not have TLB and cache, and he has a lot of difficulties in attaching a debugger TAP (especially JTAG-ADI)
the Bunker is open!
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #5 on: December 30, 2015, 10:14:10 pm »
GDB has interesting gdb-stub, gdb-server
and gdb-gui like these:

I do not like the JTAG-ADI (fpga side) + ADI-GDB-BRIDGE (host side) approach
the Bunker is open!
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 4328
  • Country: us
    • Personal site
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #6 on: December 31, 2015, 06:09:04 am »
I personally would re-evaluate a need for debugger or priority. What is the goal of all this? If this is just an exercise in VHDL and no future development is planned, then it is probably better to finish it off with a somewhat standard debugger architecture, even if it is ugly and hard (it is not like the rest of GDB is beautiful). Same goes for a real production stuff - bad standards are better than home brewstuff in most cases, unless you are really committed and sure in your abilities to push for a new standard.

For hobby use, I don't think the debugger is necessary at all, but I'm generally biased against debuggers.
Alex
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: nl
    • NCT Developments
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #7 on: December 31, 2015, 11:05:27 pm »
so basically it's a bullshit, like the worst idea ever  :-DD
I'm not quite sure. A small cpu core like the picoblaze could handle the protocol. These are simple (and almost fun) to program in assembly.
@Ataradov: the GDB protocol is also standard so if you can implement that it still adheres to a standard. Personally I'm not a fan of JTAG because it is often very obfustigated to use. Many layers stacked on top of eachother with many places for things to go wrong.
« Last Edit: December 31, 2015, 11:08:21 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #8 on: January 01, 2016, 12:07:14 am »
What is the goal of all this?

I have never understood what he wants to do. In first place, there is no need for another softcore, we already have NIOS, LEON, ZPU, etc, also we have hybrid solution like ARM+FPGA (e.g. DE1 board), able to run linux (OpenRISC has now a specific uclibc stage 4), while his softcore comes with no TLB (no MMU), no cache, and a very reduced exception engine: in short, even if there are board with arduino-line pins, it's less useful than an arduino!
for hobby (good occasion to learn by having fun) I have already designed and suggested him a debug TAP, I have designed its protocol to be the easiest, I have written the host interface in C (with wrappers to simplify both the module test and the system integration test), but he refuses everything because he want the goddam gdd, which costs a very complex engine, especially if you also want the jtag

I am a bit tired about his project, I am tired to provide him solutions which he refuses for his motivation, which sounds "I MUST use gdb, I MUST have jtag" (even if it's for hobby purpose, I do not believe it's for commercial, as there is no need for an other soft core, and in case { ZPU, LEON, NIOS*, *BLAZE } have a better support by sever order of magnitude)

I have already written a linker-script, a full-patch for gcc-mips in order to force alignment load/store (in order to simplify the exception handler, as his softcore is not able to handle unaligned memory access exceptions, and it comes with no dedicated instructions, still to be implemented and tested), a bsp, everything integrated within geany with automagically generation of makefile, but he is still using the manual way with no linker script, which makes everything more complex to be handled as it requires more manual work

it is not like the rest of GDB is beautiful

things made by G-boys (G stands for GNU) are always thousand light years far from the concept of being simple and beautiful, these guys are complex by design, and sometimes (too often) they cause more problems than how many they solve, e.g. tar worked on UNIX until they have "improved" and since then we still have a lot of troubles

gdb is a very complex amount of stuff, even if the gdb-stub is simple, the gdb engine goes complex

For hobby use, I don't think the debugger is necessary at all, but I'm generally biased against debuggers.

it's useful and funny when you have to verify what happens inside a softcore and you can trust the software because you can't trust the hardware because bugs are there
e.g. his softcore had a lot of bugs with "delayed branch" plus other bad things, so the "monitor" (a piece of software, written in assembly, and able to catch exceptions, interrupts, and able to dump the CPU-registers content) was bugged because of these hardware bugs, so register RA was reported completely wrong (which made me things a bug in the C compiler) when the problem was elsewhere

when I implemented my TAP, I was able to show him where was the bug, even if is he refuses to use my TAP because he wants his damn GDBGDBGDBGDBGGDB even if it never comes into a working & stable state

let me say: sometimes being stubborn in things which have already proved to be the wrong choice (perhaps because they are too complex, perhaps you can't implement it in a comfortable way), makes you to look like the best moron ever!
the Bunker is open!
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #9 on: January 01, 2016, 12:11:38 am »
the GDB protocol is also standard so if you can implement that it still adheres to a standard.
 Personally I'm not a fan of JTAG because it is often very obfustigated to use. Many layers stacked on top of eachother with many places for things to go wrong.

yes, I think so, the ADI-JTAG looks obscure, unclear, unintelligible, hard to be understood and handled.
the Bunker is open!
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #10 on: January 01, 2016, 12:23:15 am »
A small cpu core like the picoblaze could handle the protocol

a debug processor! Like the one used by AnalogDevices to debug their Blackfin DSP!
the B1000 cable has a BF535 chip, used as debug processor  :D

Code: [Select]
Serial Wire Interface for Debugging

# open                                     
PHY_protocol=uart
device=/dev/ttyUSB0
client.port=na
ans=(1)

# con
connected
ans=(1)

# ping
PONG
ans=(1)

# scan
device0:
   class0 reg_size[]={ 8 8 4 2 } bytes
scan probe completed in 13 tries
ans=(1)

# regs
device0 ""
 + class0
c0.reg0 "" = {  0  0  0  0  0  0  0  0 }
c0.reg1 "" = {  0  0  0  0  0  0  0  0 }
c0.reg2 "" = {  0  0  0  0 }
c0.reg3 "" = {  0  0 }
ans=(1)
#

my TAP comes with a very simple protocol, simpler than GDB-protocol, it's uart-driven (even if it's not ASCII) and it comes with a very useful interface on the host side, it's "select" driven, you can have multi clients, so a GDB-bridge it's also possible, like a piece of cake to be developed

on the host side it has a shell, you can scan resources on the remote TAP, you can probe, and then read/write registers from/to the remote TAP, something like …
how many devices do you have in your grid ?
how many classes per device ?
how many registers per class ?
and how many bits have these registers ?

its finite state machine comes with very reduced set of states, so it's less complex than a CPU by different orders of magnitude, so it makes sense. I have developed it because I need something to interface my fpga when I need to debug things like VDU, softcore ISA validation, DMA, LCD-driver
the Bunker is open!
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #11 on: January 01, 2016, 01:36:56 am »
I am a bit tired about his project, I am tired to provide him solutions which he refuses for his motivation, which sounds "I MUST use gdb, I MUST have jtag"

e.g. he refuses my boot loader, written in mips-assembly, provided with an host application which is able to load an elf-file out of the mips-toolchain, split it into .data section and .text section , and then upload them into fpga, because he MUST use gdb for this purpose, that even if his damn gdb is still not working and causes a lot of exception and data corruption  |O |O |O |O |O


ah friend (I can't say screw you to him, even if sometimes I am really tempted  :-DD)
the Bunker is open!
 

Online Kalvin

  • Super Contributor
  • ***
  • Posts: 1634
  • Country: fi
  • Embedded SW/HW.
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #12 on: January 01, 2016, 01:45:43 am »
+1 picoblaze

Picoblaze has also a C compiler available. I haven't used it, but it is available if writing the debugger state machine in assembly seems too complex.

Using "external" debugger allows halting the target core, single stepping, observing and modifying register values, observing stack frame, variables, memory and other fun stuff without state corruption. But it is a matter of taste how to use the debugger.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 4328
  • Country: us
    • Personal site
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #13 on: January 01, 2016, 09:11:05 am »
Personally I'm not a fan of JTAG because it is often very obfustigated to use.
I'm working on a project that involves very heavy use of ARM SWD/JTAG interface. At first I was put off by all the complexity, but then, as I learned how it all works, I got to like it. It is not like it is the best thing ever, and there is some legacy, but in general it is not that bad.

There are many things people don't think about, especially in performance and reliability department.

Your UART works at 115200 bsp, may be a bit more. JTAG can work at 16+ MHz.  And this is important for debuggers that can take advantage of this (I don't think GDB or any front end for GDB can).

What happens when a byte gets lost of damaged in your protocol? How does it handle multicore systems?

There are many things that "grown up" debug interfaces do that are not instantly obvious.

And my point is, if you are learning something, it is better to learn industry standard interfaces. For your own MCU you can do whatever you want, but when you get to work with an actual device, it will have SWD/JTAG, so might as well learn how to take full advantage of that.
Alex
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #14 on: January 01, 2016, 10:55:19 am »
Your UART works at 115200 bsp

my TAP can go up to 20Mbyte/sec, using bulk over burst mode

the protocol has been designed to be used for fast upload/download
including a RAM and ROM emulator: one protocol, different engines!

What happens when a byte gets lost of damaged in your protocol?

my TAP has 2 CRC, one for input-stream, one for output-stream
if something goes wrong the packed is rejected on both side (host, and target)
there is a stop and retry

How does it handle multicore systems?

my TAP can handle sub devices independently
- core (and their registers, general purpose registers, superuser register, floating point registers, custom registers)
- local bus
- emulated ram
- emulated rom
- shared bus (with semaphores)
- DMA
- virtual console

the real limitation is: a cpu which comes in Harvard design needs 5 sub-devices at least (instruction ram is separated from data/stack ram)
and the protocol is limited up to 32-sub devices

a virtual console is memory mapped by the tap, so it's not a physical device
but, from the point if view of the CPU, it looks like an UART (put_char, get_char, check_if_tx_is_ready, check_if_rx_is_ready, FIFO_TX, TIFO_RX)
it's useful to provide a console (not interrupt driven) when you do not have the hardware

the Bunker is open!
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #15 on: January 01, 2016, 10:57:38 am »
currently I am using a slow link @ 1Mbps
I need to downgrade the soft core clock
the Bunker is open!
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 4328
  • Country: us
    • Personal site
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #16 on: January 01, 2016, 11:03:06 am »
my TAP can go up to 20Mbyte/sec, using bulk over burst mode
But how it is attached to the actual target?

my TAP has 2 CRC, one for input-stream, one for output-stream
if something goes wrong the packed is rejected on both side (host, and target)
there is a stop and retry

SWD/JTAG has a feature, where result of a memory access is stored inside the debug unit, so that if transfer has failed, you get the buffered value, and don't do a read again. This is needed when you work with memory-mapped I/O in case if access causes side-effects. For example, many flag registers are clear on read, so you only get one shot at reading them.

I'm not saying it is impossible to design a good system, but small things like that do make a difference, and after you implement them all, you will end up with the same level of complexity.

Dealing with secure systems with varying privileges for different buses/memory regions is another story.

I personally rather go with industry standards.
Alex
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #17 on: January 01, 2016, 11:56:47 am »
how it is attached to the actual target?

I have designed a pcb, it comes with a fast USB chip (Cyprex) directly wired to the fpga and synchronously handled
while on the host side (PC), linux sees a special usb-bulk device (over a custom kernel module, which is still under development)
the Bunker is open!
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: nl
    • NCT Developments
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #18 on: January 01, 2016, 12:04:12 pm »
What happens when a byte gets lost of damaged in your protocol?
The biggest problem with JTAG is that it is synchronous and debuggers are connected with relatively long wires. If you turn on a mains powered device during a JTAG transfer it is very likely the JTAG transfer get screwed up beyond recovery. UART (or USB) is much more resilient to these kind of events.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #19 on: January 01, 2016, 12:12:34 pm »
SWD/JTAG has a feature, where result of a memory access is stored inside the debug unit, so that if transfer has failed, you get the buffered value, and don't do a read again. This is needed when you work with memory-mapped I/O in case if access causes side-effects. For example, many flag registers are clear on read, so you only get one shot at reading them.

nice trick, my TAP does not have it, while I have seen something similar with BDM on MC68332, which comes with clear on read || write devices.

I'm not saying it is impossible to design a good system, but small things like that do make a difference, and after you implement them all, you will end up with the same level of complexity.

to be honest I am very tired of GDB and these stuff, I often happen to have a lot of problems recompiling them on my embedded boards
especially when I have to recompile them on machines that are not x86 (the most used)

e.g.
Code: [Select]
2015-12-29--21-41-23---2015-12-29--21-50-00 - mips-be-glibc emerge  dev-util/cgdb - failure - root
Code: [Select]
2015-12-29--21-10-01---2015-12-29--21-15-00 - x86-be-glibc emerge  dev-util/cgdb - success - root

while my tools do always compile without any troubles as they are written in pure ANSI/C without ugly wicked tricks!

Dealing with secure systems with varying privileges for different buses/memory regions is another story.

I personally rather go with industry standards.

My TAP is not designed for the industry, it's designed for hobby, more specifically to have fun instead of having troubles with GNU, G-BOYS and their stuff
It's not better, it's not THE solution, I am not interested in Copyright, Royalties, reinventing the wheel in a new standard to do money with.
My TAP simply compiles everywhere without all the G-crap, and it works as expected.

When I have to do professional job-tasks I do not use GDB, I use Keil and Analog Devices.
I have bought their professional debuggers and I am fine with them  :D
the Bunker is open!
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 4328
  • Country: us
    • Personal site
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #20 on: January 01, 2016, 12:21:17 pm »
I have designed a pcb
Well, yes, with custom (and expensive) hardware anything can be done. But CMSIS-DAP can be implemented on any MCU with USB (all you need is HID support) and has plenty of performance for normal debugging. Trace features many need a bit more bandwidth, but with 1024-byte packets, event that is not really a big deal.
Alex
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 4328
  • Country: us
    • Personal site
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #21 on: January 01, 2016, 12:22:59 pm »
JTAG transfer get screwed up beyond recovery.
There is no way to screwup JTAG interface itself. Particular transaction will be gone, of course, but software can always recover. That's one of the design objectives.
Alex
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #22 on: January 01, 2016, 12:30:20 pm »
Well, yes, with custom (and expensive) hardware anything can be done

a papilio-pro costs ~100 euro, while my board costs 160 euro and comes with a 2Mbyte NVRAM, 8Mbyte DRAM, and a super fast Cyprex chip for the TAP. A Cyprex demo board costs 50 euro, so … I am really fine!

I can adapt my protocol (from vhdl to C) to work over HID, and in this way I could cover MPUs: the problem is, again, I am not interested!
the Bunker is open!
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 4328
  • Country: us
    • Personal site
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #23 on: January 01, 2016, 12:34:29 pm »
A Cyprex demo board costs 50 euro, so … I am really fine!
Again, we are talking about different thins here.

Inventing new stuff for hobby is perfectly fine.

I'm more industry-oriented. So I'm taking about $10 development boards that include a target board and a debugger. There is no way to put a Cypress chip on there. And it is very fortunate that everything moves towards very cheap debugger hardware.
Alex
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #24 on: January 01, 2016, 12:50:35 pm »
I'm more industry-oriented

$10 development boards

It sounds you are kidding

In first place, do really use gdb for serious job-tasks?

In second place, here "development boards" costs in order of thousands
e.g. Keils costs 1600 euro, just for the toolchain + debugger license, plus 700 euro for the debug cable/pro
my e500 board (used in automotive) costs 2500 euro, its debug engine (including Windriver + Lauterbac + debug cable) costs 32.000 euro
things from Green Hills (e.g. AdaMulti) cost more and more!

and let me say nobody sane will ever reinvent Lauterbach GmbH, they are a German electronic company specialized in in-circuit emulators and logic analyzers used for debugging embedded systems

in third place, for professional job you MUST use certified tools (especially in avionics)

 
the Bunker is open!
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 4328
  • Country: us
    • Personal site
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #25 on: January 01, 2016, 12:53:18 pm »
It sounds you are kidding
We are on different sides of the industry :) I'm talking about MCU vendors, not people who use MCUs.

In first place, do really use gdb for serious job-tasks?
Of course not. I do use GCC toolchain and very happy with it, would not change it for any other even if some one else pays. Well, maybe IAR, but I do hate Keil.

I don't use debuggers much. I'm pretty happy with other ways of debugging.
Alex
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: nl
    • NCT Developments
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #26 on: January 01, 2016, 01:05:16 pm »
JTAG transfer get screwed up beyond recovery.
There is no way to screwup JTAG interface itself. Particular transaction will be gone, of course, but software can always recover. That's one of the design objectives.
Yes, but unfortunately the recovery part is always forgotten in the software  :palm:
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 4328
  • Country: us
    • Personal site
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #27 on: January 01, 2016, 01:05:59 pm »
Yes, but unfortunately the recovery part is always forgotten in the software  :palm:
Could not agree more :)
Alex
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #28 on: January 01, 2016, 01:14:34 pm »
I do use GCC toolchain and very happy with it

I hate gcc and everything comes from GNU (including emacs and gdb), in first place G-boys& their friends are not good programmers, these dudes too often do "jerk child code" with too much complexity, which is too ugly to be supported (pay me to see their sources, I am horrified)

I am a gentoo/MIPS supporter, I have a lot of troubles with gcc, e.g. just to tell you the last maleficent, I am supporting an old SGI machine and I had to switch to gcc 5.2, which is currently "experimental" (it means not included in the gentoo portage, the last available is gcc v4.9), because the atomic-functions were not working as expected for R12K CPUs :palm: :palm: :palm: :palm:

in short the whole SMP, and the whole userland, was crashing up and I needed a lot of pills because the compiler is a @#@$@ crap!

I have fixed the jam just switching to v5.2 (which means ... opening an overlay, invoking crossdev, forcing a new cross compiler, fixing it ... 5 days of over work and blasphemy) and recompiling everything in the right way: I have now a working SMP plus a working uclibc-stage4, I am completed, but … I still HATE their compiler!

Have you ever seen inside gcc source code ? My friend's softcore does not handle unaligned memory access, so I had to manually patch gcc to force it to avoid unaligned memory access, it's a piece of cake with LLVM, while it was a nightmare with gcc!!! It took 8 days of blasphemy!

and do I have to tell you what happened with gcc v4.1 on HPPA v2 ? I remember when applications compiled by gcc -O2 took their branches (if (condition) then else) in randomly way because the compiler had a bug! It took 3 month of blasphemy, because I was not sure that the problem was the compiler (I was used to trust it, so I was looking into different direction, including hardware failures in ram)


in short, don't say "gcc" for job-tasks  :D


I do hate Keil.

I hate their IDE, but everything else (including their support and assistance) is more than comfortable (and they are very kind on the phone)
the Bunker is open!
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 4328
  • Country: us
    • Personal site
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #29 on: January 01, 2016, 01:29:00 pm »
I am a gentoo/MIPS supporter
Here is your problem :)

I would not want to go into the guts of GCC. Well, I had to a few times for AVR, and I did not enjoy it.

That's why I use ARM. They actually maintain official toolchain, that always works and always up to date and available for variety of platforms. Never had any problems with it and if ARM engineers suffer to make it work, I feel for them, but it is not my problem.

I hope Clang/LLVM get up to speed soon on all major platforms, not just x86.
Alex
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: nl
    • NCT Developments
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #30 on: January 01, 2016, 01:55:04 pm »
Using anything for a less common platform is going to land you in a world of pain due to lack of support. That is not GCC's fault! I have used GCC in the past on a MIPS based Linux platform but I didn't had any problems with the GCC compiler.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #31 on: January 01, 2016, 10:09:40 pm »
Which System and Which Work, buddy ?

if you mean, I got the last trunk from OpenWRT and then I built a kernel+rootfs for the last router
well, sure, it works out of the box, but it's not the point!!!
the point is: do you know how hard was the effort under the hood in order to get this purpose?

...
edit: details removed
...


the point with gcc: an easy task too often comes into troubles, which requires too much effort to be solved!
« Last Edit: January 02, 2016, 08:43:47 am by legacy »
the Bunker is open!
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 4328
  • Country: us
    • Personal site
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #32 on: January 01, 2016, 10:34:22 pm »
Stop whining and create a better compiler, what stops you?

Unlike you, "G-Boys" have created a compiler that is used in a lot of machines, and at the moment it is the best we have, even if it is not pretty.

If you hate it so much, don't work with it, leave it alone.
Alex
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: nl
    • NCT Developments
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #33 on: January 01, 2016, 10:35:34 pm »
MIPS based Linux platform but I didn't had any problems with the GCC compiler.

Which System and Which Work, buddy ?

if you mean, I got the last trunk from OpenWRT and then I built a kernel+rootfs for the last router
well, sure, it works out of the box, but it's not the point !!!
the point is: do you know how hard was the effort under the hood in order to get this purpose?
Yes. That is a world of pain which is why you shouldn't drift away from the beaten path  O0 IIRC the system I worked on had a MIP32 core. The systems you are writing about are very archaic so it might be better to stick to old versions of GCC which work for those.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2798
  • Country: 00
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #34 on: January 02, 2016, 03:32:51 am »
so it might be better to stick to old versions of GCC which work for those.

yes, absolutely :D
the Bunker is open!
 

Offline helius

  • Super Contributor
  • ***
  • Posts: 2264
  • Country: us
Re: draft: GDB-stub goes to vhdl, how good is this idea ?
« Reply #35 on: January 02, 2016, 04:52:40 am »
Even GNU developers have decided that GCC is doomed.
https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00457.html
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf