printf_P

Log in or register to post comments
Go To Last Post
29 posts / 0 new
Author
Message
LX_User
LX_User's picture
Level: Hangaround
Joined: Sat. Mar 5, 2011
Posts: 124 View posts
Location: CZ, Zlin
#1
Posted by LX_User: Tue. Apr 5, 2011 - 02:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In program for AVR-Mega168, AS-5, Simulator, GCC

I have command

printf_P (PSTR("Some text"));

In AS-4 everything working for F10 and for F11 key. In AS-5, when I use F10 for stepping in Debugger it is ok. But when I tried F11 - on printf_P command open windows with label: "Studio can not find: C:\home\tools\hudson\workspace\avr8-gnu toolchain\src\avr-libc\libc\stdio\printf_p.c - in my computer is no path like this. Immeditely open Disassembly window and there is :
something like this

00000D87 LDD R18,Z+3 Load indirect with displacement
00000D88 ANDI R18,0xF7 Logical AND with immediate
--- C:\home\tools\hudson\workspace\avr8-gnu-toolchain\src\avr-libc\libc\stdio\printf_p.c
00000D89 STD Z+3,R18 Store indirect with displacement

00000D8A ADIW R28,0x00 Add immediate to word
00000D8B LDI R30,0x02 Load immediate
00000D8C JMP 0x000010A7 Jump
--- C:\home\tools\hudson\workspace\avr8-gnu-toolchain\src\avr-libc\libc\stdio\puts.c

00000D8E PUSH R14 Push register on stack

Tags:

Tools, Atmel Studio (AVR-related)
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101145 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Apr 5, 2011 - 04:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is because Atmel were told about a fault that briefly occurred in WinAVR but then managed to repeat it anyway. Their toolchain has been built without some of the .o and .a library files being stripped:

D:\Program Files\Atmel\AVR Studio 5.0\extensions\Application\AVR Toolchain\avr\l
ib>find . -name \*.[ao] -exec grep tools/\hudson {} ;
Binary file ./avr25/crt86401.o matches
Binary file ./avr25/crta6289.o matches
Binary file ./avr25/crttn13.o matches
Binary file ./avr25/crttn13a.o matches
Binary file ./avr25/crttn2313.o matches
Binary file ./avr25/crttn2313a.o matches
Binary file ./avr25/crttn24.o matches
Binary file ./avr25/crttn24a.o matches
Binary file ./avr25/crttn25.o matches
Binary file ./avr25/crttn261.o matches
Binary file ./avr25/crttn261a.o matches
Binary file ./avr25/crttn4313.o matches
Binary file ./avr25/crttn43u.o matches
Binary file ./avr25/crttn44.o matches
Binary file ./avr25/crttn44a.o matches
Binary file ./avr25/crttn45.o matches
Binary file ./avr25/crttn461.o matches
Binary file ./avr25/crttn461a.o matches
Binary file ./avr25/crttn48.o matches
Binary file ./avr25/crttn84.o matches
Binary file ./avr25/crttn84a.o matches
Binary file ./avr25/crttn85.o matches
Binary file ./avr25/crttn861.o matches
Binary file ./avr25/crttn861a.o matches
Binary file ./avr25/crttn87.o matches
Binary file ./avr25/crttn88.o matches
Binary file ./avr25/libc.a matches
Binary file ./avr25/libm.a matches
Binary file ./avr25/libprintf_flt.a matches
Binary file ./avr25/libprintf_min.a matches
Binary file ./avr25/libscanf_flt.a matches
Binary file ./avr25/libscanf_min.a matches
Binary file ./avr3/crt43320.o matches
Binary file ./avr3/crt43355.o matches
Binary file ./avr3/crt76711.o matches
Binary file ./avr3/crtm103.o matches
Binary file ./avr3/crtusb162.o matches
Binary file ./avr3/crtusb82.o matches
Binary file ./avr3/libc.a matches
Binary file ./avr3/libm.a matches
Binary file ./avr3/libprintf_flt.a matches
Binary file ./avr3/libprintf_min.a matches

You can use a variant of the above find command to strip the debug info:

find . -name \*.[ao] -exec avr-strip -g {} ;

PLEASE, whoever at Atmel builds the toolchain read my post here and do it properly next time - really you should be doing the strip -g in the build script.

Top
danv
danv's picture
Level: Hangaround
Joined: Tue. Mar 1, 2011
Posts: 224 View posts
Location: Atmel, Norway
Posted by danv: Tue. Apr 5, 2011 - 07:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will take it up internally.

What was the problem in WinAVR that was solved by stripping the debug info ? In general, I favor keeping the debug info, since it gives the user the possibility of debugging the library code by setting up the corresponding source code directory.

Regards, Dan

[edit]By debugging the library code I meant stepping through, watching variables and setting breakpoints in that code. I did not mean to imply that the library code itself needed debugging. My apologies for the confusion[/edit]

Last Edited: Wed. Apr 6, 2011 - 08:14 AM
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101145 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Apr 5, 2011 - 07:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When Eric made WinAVR20100110 he released the first one on that date (10th Jan) but it quickly became clear that he made a mistake in the build process (he was adapting "avr" only to do "avr" and "avr32" and broke this in the process). So a second WinAVR20100110 was actually released on 19th Jan (you can tell them apart by the build date shown in avrdude -v). This latter one had the fault repaired.

The reason you cannot leave debug symbols in the system libraries is because the way ELF debugging works is that it encodes into the ELF (.elf, .a or .o) the path to the source file and the line number. Then the symbolic debugger, like AVR Studio, when it tries to annotate the Asm with the source goes and opens those files and reads line N from it. If the path to those files does not exist the end user (as in this thread) gets multiple errors from the debugger saying "please identify where the file /buildpath/file.c has now been placed". The end user won't even have a copy of the AVR-LibC source files so even if they could spoof the hard-coded paths they wouldn't have the files and even if they did the likelihood they had the same line numbering as at the original build time is beyond remote.

In Eric's case the world and I can tell that on his PC he happened to build AVR-LibC in a directory called C:\AVRDEV\* because that's what was encoded in the .o's and .a's

In the case of this most recent AVR Toolchain (it was also apparent in the earlier standalone "AVR Toolchain" and many threads at the time told you this!?!) I can tell from the top of this thread and my own grep'ping results that the member of Atmel staff who built the toolchain is almost certainly called "Hudson" (or do you all call yourself characters from Conan-Doyle?). He built the AVR-LibC that is in AVR Toolchain (AS5) on his own PC in:

C:\home\tools\hudson\workspace\avr8-gnu-toolchain\src\avr-libc

He's probably the only person on earth for whom that path is valid and which contains a valid copy of the lib source. Of course, when HE tested "toolchain" and built some code in AVR Studio he is also the one person on earth who had the luxury of being able to source level debug the library code. So he probably wouldn't have spotted the error he'd made (unless he was really switched on and realised he should NOT be able to see the libc source)

But unless you can think of some way to provide all users with an entire copy of the AVR-LibC build tree (and please don't make the 0.5GB install package BIGGER!!) then your only option is to "avr-strip -g" all the .a's and .o's at the end of the build (just like Eric used to do and that happened successfully in all issues of WinAVR up to the 10th Jan version of WinAVR).

I'm wondering if there's some communication break down inside Atmel between the expert(s) on GCC tools (Eric and Joerg) and the people who have now taken over their reponsibility? Do they even take part in the avr-gcc and AVR-LibC developers lists I wonder?

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30481 View posts
Location: Wormshill, England
Posted by david.prentice: Tue. Apr 5, 2011 - 08:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I disagree. The WinAvr library code is pretty robust. So a punter will seldom ever need to step through it.

It is really irritating to have thousands of useless prompts for library source files. This happens for every debug session.

If someone is worried about a library bug, they can download the source and rebuild the library themselves.

I cannot believe that Atmel can release this sort of software. Other manufacturers contract out to third party tool vendors. Rowley would be well worth asking. Let's face it. The odd bug in an application note is one thing. Studio 5 appears to be a recipe for disaster. (I bet Atmel could have done a licence deal for a reasonable amount of cash / fees)

David.

Top
danv
danv's picture
Level: Hangaround
Joined: Tue. Mar 1, 2011
Posts: 224 View posts
Location: Atmel, Norway
Posted by danv: Tue. Apr 5, 2011 - 09:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I disagree. The WinAvr library code is pretty robust. So a punter will seldom ever need to step through it.

I find it highly educational to step through library code, so there is the value of keeping debug info on my part.

david.prentice wrote:

It is really irritating to have thousands of useless prompts for library source files. This happens for every debug session.

As far as I can understand, the complaints are related to the useless prompts for non-existing source code files.

If we had a way to turn off these prompts in Studio 5, and still leave the debug info in the object file, would that be satisfactory ?

Dan

Top
danv
danv's picture
Level: Hangaround
Joined: Tue. Mar 1, 2011
Posts: 224 View posts
Location: Atmel, Norway
Posted by danv: Tue. Apr 5, 2011 - 09:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

I can tell from the top of this thread and my own grep'ping results that the member of Atmel staff who built the toolchain is almost certainly called "Hudson" (or do you all call yourself characters from Conan-Doyle?). He built the AVR-LibC that is in AVR Toolchain (AS5) on his own PC in:

C:\home\tools\hudson\workspace\avr8-gnu-toolchain\src\avr-libc

He's probably the only person on earth for whom that path is valid and which contains a valid copy of the lib source.

FYI, Hudson is our automated build system, and does exactly as told (well, most of the time he does).
Since avr-libc is open source, recreating the source code tree should be manageable (and probably required by the license). We could even post it on the AS5 site, if that is acceptable.

Dan

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101145 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Apr 5, 2011 - 09:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes but your average user isn't going to know they need to download and install such libc source, yet if they haven't and they single step into any libc system call they are going to get this mysterious "hudson" message.

You don't really have an option, they must be stripped. Like David I see virtually no merit in source debugging libc - what do expect the user to do? Are they supposed to get the libc source, modify it and rebuild it or what? Otherwise it's a pointless intellectual exercise. For the curious the libc sources are online via the CVS. The only important thing for the user of libc is that it conforms to the documented API. AFAIK it does so no one but the developers needs to debug it.

Top
danv
danv's picture
Level: Hangaround
Joined: Tue. Mar 1, 2011
Posts: 224 View posts
Location: Atmel, Norway
Posted by danv: Tue. Apr 5, 2011 - 10:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Yes but your average user isn't going to know they need to download and install such libc source, yet if they haven't and they single step into any libc system call they are going to get this mysterious "hudson" me.

We could add a setting so that the user is never prompted for missing source files from a certain directory (say Hudson...) There already is a precedent in the way Microsoft Developer Studio knows where to look for the source code to its runtime.

So this is my point : if we can make it non-intrusive, like the Microsoft Studio solution, having the ability to look and step through the libc code is a clear benefit lost in the stripping solution. This is NOT for debugging libc itself, but to understand and learn from its behaviour.

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30481 View posts
Location: Wormshill, England
Posted by david.prentice: Wed. Apr 6, 2011 - 07:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could add a setting to ignore certain magic paths. I would strongly disagree with anything 'magic'.

If you are determined to go down this route, you need to disable the 'magic' path as a default.

C Compilers and tool suites have been distributed for the last thirty years. GCC for twenty years. You never supply library debug info without the source code. Punters are able to retrieve the source and build the whole system themselves if they need to. Please do not make this compulsory.

But I do not want to build a tool suite. I want to just use it. For example, you buy a motor car that is already assembled and tested. You only take it apart if you find a problem !!

Quote:
This is NOT for debugging libc itself, but to understand and learn from its behaviour.

I do not know Atmel politics. It seems obvious to me that you should ask advice from experienced developers. Either by collaborating with a commercial company or simply asking Eric or Joerg.

The Atmel in-house employees will gain experience. In due course of time they will be able to support the Studio 5 project.

Meanwhile Atmel just looks incompetent: Xmega release date. Xmega revisions. Chip supply problems. Releasing Studio 5 ...

David.

Top
Bronze MarkJohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26945 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Wed. Apr 6, 2011 - 07:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danv wrote:
What was the problem in WinAVR that was solved by stripping the debug info ?

How about asking the person that did the WinAVR builds. Eric Weddington. Last time I checked, he was an Atmel employee..

EDIT: I just bit when I saw danv's post. I see now, reading the thread to the last post, that others have made similar responses..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here. 

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Top
danv
danv's picture
Level: Hangaround
Joined: Tue. Mar 1, 2011
Posts: 224 View posts
Location: Atmel, Norway
Posted by danv: Wed. Apr 6, 2011 - 08:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David, I am happy the proposed solution is ok with you. If going this route, we will try to make it as close as possible to the Microsoft Visual Studio solution. They have been providing binaries with debug info for 15 odd-years, while allowing the user to install the runtime source code if desired. Worked ok for me and a few other million developers.

Dan

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101145 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Apr 6, 2011 - 08:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

David, I am happy the proposed solution is ok with you.

What is wrong with Atmel these days? They ask customers what they think. Ignore the reply then deliver something the users don't want and say "this is what our users asked for". Oh dear God.

Suggest you re-read David's response. It sounds to me like you are all MS VS developers and you want to deliver a clone for AVR. This is not what AVR developers want. Those of us who use GCC want it to be common on whatever CPU we use it on. Check out the toolchains for i686, ARM, MIPS, et al. Do they supply source debuggable libraries and the baggage that it entails? No they don't so why do you folks think you can re-write history. No one wants all this pointless baggage. Computer users since the year dot have been using printf() do you think any know or care how it works internally? All that matters is that it produces formatted output the way the C standard says it will. Almost all of libc is written in hand optimised Asm anyway - of what benefit to a C programmer is visibility of that going to be?

Exactly how hard would it be for someone in Atmel to have a half hour phone call with Eric or Joerg and ask them for their opinion on important issues like this? It's clear that whoever is doing the GCC work at Atmel these days are just a bunch of contractors with no real experience of actually using GCC dev toolchains.

(PS this is just a guess as I have no experience but in your Eclipse AVR32 Studio do you provide library source for the avr32 libc? My guess is "no")

Top
Bronze MarkJohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26945 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Wed. Apr 6, 2011 - 08:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff..

Quote:

the member of Atmel staff who built the toolchain is almost certainly called "Hudson"

http://hudson-ci.org/

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here. 

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30481 View posts
Location: Wormshill, England
Posted by david.prentice: Wed. Apr 6, 2011 - 08:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@danv,

You misunderstand me. I would suggest that you distribute binaries without debug info. You offer an option for the punter to download library source and re-build the whole tool suite. In exactly the same way that you can obtain and build any GNU projects.

The average punter does NOT want to re-build GCC or re-build Linux.

The developer that does want to re-build, knows exactly how to do it.

Surely someone could take Eric out for a cup of tea, nice meal ...

You would get some practical advice. If the politics are bad, pay a commercial company.

David.

Top
danv
danv's picture
Level: Hangaround
Joined: Tue. Mar 1, 2011
Posts: 224 View posts
Location: Atmel, Norway
Posted by danv: Wed. Apr 6, 2011 - 08:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
danv wrote:
What was the problem in WinAVR that was solved by stripping the debug info ?

How about asking the person that did the WinAVR builds. Eric Weddington. Last time I checked, he was an Atmel employee..

Eric is a busy man, and I cannot run to him every time a reference is made to "Atmel has been informed". Besides, he lives in a different time zone and works on a different team, so the threshold of communication is higher then it could be.

BTW, I think the root cause of the discussion is our failure to properly populate the "Debug Source Files" tab in Solution Properties. This is where source code directories, and "ignore" paths should go in the Studio world.

Dan

Top
Bronze MarkJohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26945 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Wed. Apr 6, 2011 - 08:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danv wrote:
JohanEkdahl wrote:
danv wrote:
What was the problem in WinAVR that was solved by stripping the debug info ?

How about asking the person that did the WinAVR builds. Eric Weddington. Last time I checked, he was an Atmel employee..

[...] I cannot run to him every time [...]

1. You where the one asking "What was the problem in WinAVR". Who would know better than anyone else? Why would you want the answer to such a question from a "secondary source" rather than from the man who made the mistake and who most likely would like to help any others to not redo it?

2. From the above: Politics it is then..

Quote:
he lives in a different time zone and works on a different team, so the threshold of communication is higher then it could be.

Here are some official secrets:
3. An email will wait patiently in the receivers mailbox until he gets up, goes to work and opens the mailbox.

4. AvrLibc has been developed by numerous people around the world, obviously being in different timezones. That didn't stop them.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here. 

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Top
danv
danv's picture
Level: Hangaround
Joined: Tue. Mar 1, 2011
Posts: 224 View posts
Location: Atmel, Norway
Posted by danv: Wed. Apr 6, 2011 - 08:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Let's analyze this:

User A: never wants to see the innards of a library.
The benefit of no having debug info in the binaries is that it saves a few megabytes of download, and the user is never bothered by the "Find file" dialog.

User B: wants to step through library code.
Without debug info, the user needs to download an entire toolchain and compile his own libraries. Assuming user B is an average punter, he will probably give up halfway into the download.
With debug info: has the option to download or preinstall the library source code, and step thru with ease.

The average punter does NOT want (or know how) to compile his own library. He just wants to see how itoa, malloc, exit or whatever are implemented. I routinely set breakpoints inside abort() where all the asserts are ending.

All in all, I see more value in providing debug info in the binaries.

Last Edited: Wed. Apr 6, 2011 - 08:47 AM
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101145 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Apr 6, 2011 - 08:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

BTW, I think the root cause of the discussion is our failure to properly populate the "Debug Source Files" tab in Solution Properties

Err no. Like I said WinAVR20100110 (10th Jan) suffered from this same malady and was a stand alone toolchain, nothing to do with AS5, IDEs and such.

Top
danv
danv's picture
Level: Hangaround
Joined: Tue. Mar 1, 2011
Posts: 224 View posts
Location: Atmel, Norway
Posted by danv: Wed. Apr 6, 2011 - 08:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
1. You where the one asking "What was the problem in WinAVR". Who would know better than anyone else? Why would you want the answer to such a question from a "secondary source" rather than from the man who made the mistake and who most likely would like to help any others to not redo it?

I asked the person who stated that there was a problem. I did not know that there was a problem , and what the problem was, and I don't agree that having debug info in the binaries should be a problem with Studio 5, so I was fishing for the angles.

Toolchain users that do not use Studio 5 will probably want to strip their binaries. We could maybe add an option to the installer to cover that angle.

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30481 View posts
Location: Wormshill, England
Posted by david.prentice: Wed. Apr 6, 2011 - 08:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
All in all, I see more value in providing debug info in the binaries.

I disagree. It would only be acceptable if the library source code was installed on the exact path. Even then, I do not think the punter wants the aggravation.

Yes. If I have wanted to know how a library function was written, I have installed the libC source code.

Over the years there have been one or two bugs in the library source code. A workaround is generally published, a bug report filed and the next release is fixed.

Most often, 'bugs' are mentioned here. 95% of the time it is confirmed to be user error. The other 5% get AvrFreaks members finding a workaround.

David.

Top
EW
EW's picture
Level: Raving Lunatic
Joined: Thu. Mar 1, 2001
Posts: 4914 View posts
Location: Rocky Mountains
Posted by EW: Wed. Apr 6, 2011 - 12:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

Surely someone could take Eric out for a cup of tea, nice meal ...

Oh, that would be lovely. I like an iced chai tea (sorry, from an American point of view), or darjeeling black, preferably organic. :)

Eric Weddington
www.linkedin.com/in/ericweddington/

Top
danv
danv's picture
Level: Hangaround
Joined: Tue. Mar 1, 2011
Posts: 224 View posts
Location: Atmel, Norway
Posted by danv: Wed. Apr 6, 2011 - 01:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I apologize for my ignorance in not contacting EW directly instead of discussing the issue here.

I do believe it is possible to accomodate both users that want stripped binaries, and academic users that would appreciate the debug info and the library source code.

Last Edited: Wed. Apr 6, 2011 - 02:51 PM
Top
Bronze MarkJohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26945 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Wed. Apr 6, 2011 - 01:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is getting ridicolous. A person obviously deeply involved in building the AVR Tool Chain does not know that WinAVR was built by Eric Weddington, and that he is an Atmel employee.

Dan! In all friendliness: Since you're new to AVRfreaks, then maybe you are new at Atmel Norway too. If so then have a look around for a while. You will find

1) A lot of traffic on WinAVR over the years. nd you will see Eric very involved. (In my view Eric more or less is WinAVR.)

2) Several people have been very disappointed by recent actions by Atmel. To be fair others have not, but the ones that have been have largely been so re AVR Studio 5, it's closed-platform property, it premature release into beta, and perhaps a plethoria of other things. If you are not aware of this, and just merrily plunge into the AVRfreaks pool then you will probably be well (b)eaten up by the grumpy sharks. If you are actually new to all this, then I suggest you sit down for a while with one of your seasoned colleagues, preferrably one that frequents AVRfreaks, over a cup of coffee an get his story of it. Anything you bring to AVRfreaks right now risks bringing it to critical mass, and the last thing you will see is a very bright light. As I said, in all friendliness, since no-one (not Atmel, not us) gains anything by posts that are made in good faith, but actually set the house ablaze.

Quote:

EW wrote:

The important thing in all of this, is that you are assuming you know what the users want in a toolchain.

No, I claimed that I know what *I* want from a toolchain.


B-b-but... You are building it for the users. (Hopefully..)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here. 

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Wed. Apr 6, 2011 - 01:48 PM
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101145 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Apr 6, 2011 - 01:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Now you are assuming I knew I should have contacted you.

That's a very worrying statement. Do folks inside Atmel not know that Eric Weddington and Joerg Wunsch are two of the "gods" of avr-gcc development then?!? I think everyone who's been using it for the last N years know exactly who they are and how significant their input has been. If it's passed to a team who don't even know this it looks like a VERY worrying development for the future of avr-gcc. Talk about a case of "chinese walls"!

Top
Bronze MarkJohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26945 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Wed. Apr 6, 2011 - 01:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

If it's passed to a team who don't even know this it looks like a VERY worrying development for the future of avr-gcc.

No it does not, Cliff. avr-gcc will continue to develop. So will avrlibc. WinAVR is sleeping but could be awoken.

The worring future is for AVR Tool Chain. If it was just for that in itself, I'd simply say: "So what?" But of course it is not just about the Tool Chain..

What is imoprtant is to keep the initiative around avr-gcc, avrlibc and related stuff so that it's "center of gravity" is kept outside of Atmel. (Yes, I am (slowly) building up knowledge and confidence to hopefully be able to participate. You too?) It is quite obvious that if it would end up inside Atmel of today, the thing would probably be derailed into a mess. (Just take a look at how hard it was for them to actually publish sources for patches and stuff. Oh, speaking of that, who was it that taught them how it should be done... :evil:)

But yes, it boggles me too that a person obviously involved in building the AVR Tool Chain does not know about core names behind the components involved. In a post above I more or less suppose that it is because of noob-ness. I'm hoping for that, since the alternative is very uncomfortable to imagine..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here. 

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30481 View posts
Location: Wormshill, England
Posted by david.prentice: Wed. Apr 6, 2011 - 02:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If you are actually new to all this, then I suggest you sit down for a while with one of your seasoned colleagues, preferrably one that frequents AVRfreaks, over a cup of coffee an get his story of it.

Personally, I prefer tea. But the result is the same:

1. you get to know each other.
2. you pick up on other people's experience.

A punter (me included) wants to have tools work straight out of the box.

Yes. Debugging in Studio 4 would be better and easier if avr-gcc default options were changed.
Yes. At least the current Studio 4 works.

I think that the whole team needs to discuss any changes before implementation. (Or else punters are upset by differences)

You are better off with a Compiler that is good but not quite as good as say IAR. A Compiler that is broken is no good to anybody.

David.

Top
dl8dtl
dl8dtl's picture
Level: Raving Lunatic
Joined: Fri. Dec 20, 2002
Posts: 7506 View posts
Location: Dresden, Germany
Posted by dl8dtl: Mon. Aug 1, 2011 - 11:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danv wrote:

> In general, I favor keeping the debug info, since it gives the user the
> possibility of debugging the library code by setting up the corresponding
> source code directory.

Well, anyone capable of installing the source code will likely also be
able to compile that source code himself then, and thus link against
their self-compiled code, which includes debugging information
guaranteed to match the actual source.

I'm not an AVR Studio user myself (no Gates, no Windows), but I think
an option to not issue any (annoying) prompts for non-existant source
files might be a good addition anyway, even though my vote goes for
shipping binary versions with the debugging symbols stripped. In
fact, I used to provide "official" binary avr-libc distributions for
quite some time (and only stopped doing so since I've got the
impression nobody is using them), and my script to package these
distributions up (which, btw., is part of the public avr-libc source
tree) contains:

# Remove all debugging symbols so debuggers don't get confused about
# the different location of source files.
find . -name '*.[ao]' | xargs avr-strip -g

as one of the last actions before rolling the release package.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101145 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Aug 1, 2011 - 11:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jörg,

Hi there, haven't seen you here for ages!

Can I just ask a completely off-topic question about xargs? What makes that a better solution than:

find . -name '*.[ao]' -exec avr-strip -g {} \;

(I always tend to use -exec in this way).

Top