Running into some issues trying to build a project for an ATSAMV17Q21. Specifically, I'm trying to locate constant data into an external eeprom. I've done this before in GCC with no problem, but XC32 is being a pain.
In GCC, it was easy:
const int somevariablename __attribute__((section(".nvdata")) = value
Then, by locating these sections in a "fake" memory region, I use objcopy to spit out an eeprom s-record relocated to an address of zero. Our code knows if it encounters an address in this "fake" memory region to read from the spi eeprom using only the lower address bits, and it works fine.
However, in XC32, in order to locate things correctly without section overlaps, I had to use:
__attribute__((space(data), section(".nvdata"))
I can see in the linker map that it locates all the variables in that section, and using objcopy I can generate an s-record.
But... I noticed the code flash section was quite large. When I looked at the contents in a hex viewer, I see that all the text strings (which have similar attributes) got lumped into the initialized data section, because I can read them in a hex viewer. The main reason we put constant data into an external eeprom is so we spare code flash for code. How do I specify the attributes to get XC32 to cooperate?
Related
In MachOView, I can see that in a iOS binary file, class pointers are stored in section __objc_classlist. They are absolute address values which point to class Data in section __objc_data. But we known that iOS use ASLR, so when loaded, the real address must be different.
I checked the "getsectiondata" method, can not found any rebase logic.
So the question is:
when and how does the pointer Data rebased?
Is the rebased data dirty?
dyld handles rebasing as part of loading the binary, long before you call getsectiondata. The LC_DYLD_INFO_ONLY load command within the binary points to the rebase opcodes which contain information about which addresses to update and how.
You can use xcrun dyldinfo -rebase <binary> to see the list of addresses that dyld will rebase. You'll see entries for each class within __DATA,__objc_classlist. You can set DYLD_PRINT_REBASINGS=1 in the environment prior to launch to have dyld print out each address it rebases.
And yes, since dyld modifies data as it rebases it, the page no longer matches the underlying storage and is dirty. Avoiding dirtying pages during load has been a motivation for switching some Objective-C data structures from using pointers to relative offsets.
XRef table at offset 666027 has /Prev entry as 0, which seems to be wrong, how to handle such pdfs, how to get the actual /Prev in such cases?
Please look into attached pdf http://www.filedropper.com/hackermonthly-issue-11
Acrobat opens it 'as usual' but then wants to save it on closing. This is an indication it "repaired" the file; probably by enumerating the objects in the file and ignoring the xref tables.
Technically speaking, the file is damaged and there is no right way to "handle" it. Opening then saving it with Acrobat may work for some files, but is it not totally fail-safe; Acrobat still has to guess which objects are still valid and which are not.
The PDF was originally created with Adobe InDesign CS5, which is not known to generate faulty PDFs, and one can assume the tool that was used to add the annotations damaged the file. A cursory glance at the end of the file confirms this: the startxref offset is off by a couple of bytes, and when fixing this with a hex editor, you will only find the previous startxref (for another annotation) is also off by a couple of bytes – at which point I gave up and did not check further. So whatever tool you used to annotate the PDF, don't use it anymore.
I use java and saxonee-9.5.1.6.jar included build path , when run, getting these errors at different times.
Error at xsl:import-schema on line 6 column 169 of stylesheet.xslt:
XTSE1650: net.sf.saxon.trans.LicenseException: Requested feature (xsl:import-schema)
requires Saxon-EE
Error on line 1 column 1
SXXP0003: Error reported by XML parser: Content is not allowed in prolog.
javax.xml.transform.TransformerConfigurationException: Failed to compile stylesheet. 1 error detected.
I open .xslt file in hex editor and dont see any different character at the beginning AND
I use transformerfactory in a different project but any error I get.
Check what the implementation class of tFactory is. My guess is it is probably net.sf.saxon.TransformerFactoryImpl - which is basically the Saxon-HE version.
When you use JAXP like this, you're very exposed to configuration problems, because it loads whatever it finds sitting around on the classpath, or is affected by system property settings which could be set in parts of the application you know nothing about.
If your application depends on particular features, it's best to load a specific TransformerFactory, e.g. tFactory = new com.saxonica.config.EnterpriseTransformerFactory().
I don't know whether your stylesheet expects the source document to be validated against the schema, but it it does, note that this isn't automatic: you can set properties on the factory to make it happen.
I would recommend using Saxon's s9api interface rather than JAXP for this kind of thing. The JAXP interface was designed for XSLT 1.0, and it's a real stretch to use it for some of the new 2.0 features like schema-awareness: it can be done, but you keep running into limitations.
Does anyone here have experiences of using gnuplot with iOS? I want to develop a scientific computing app on iOS devices and want to use gnuplot as the plotting engine. Are there any good tutorials from which I can start with?
I have the same general question, a quick google search led me to the following app, which seems to use gnuplot.
https://apps.apple.com/us/app/icas-workstation-class-scientific/id394637176
I followed the trail to their website:
http://alsoftiphone.com/iCAS/
I contacted them about it, and I will follow up if/when I get a response.
The response:
Hello,
As you've aptly pointed out, there are some complications when embedding gnuplot in an app, particularly if you intend to dynamically create and dispose of it. That is, gnuplot (as of v4.4.0 which is what I used) doesn't explicitly release some memory that it allocates presumably because it assumes that it will be released when it is quit, which would be the case when it is used as a standalone application. This will of course result in memory leaks. Similarly, gnuplot doesn't explicitly close its output file descriptor (which is set to stdout as far as I know). And it also doesn't clear multiplot mode when the main function exits which is problematic because the next time you call gnuplot in an embedded situation, some global variables will reflect multiplot mode if called thereafter.
Fortunately for you, I've already identified them so you won't have to hunt them down like I did. Unfortunately, though, I didn't create a library for my projects but here are the relevant changes that you'll need to make to the gnuplot source code.
plot.c line #615, at the end of the else block for the "if (interactive && term != 0)" conditional block of the main() function (which you will also want to change to some appropriate entry function name):
// Free replot_line
if (replot_line != NULL)
{
free(replot_line);
replot_line = NULL;
}
plot.c line #680, before "return exit_status" at the end of the main() function:
// Free replot_line if it was allocated
if (replot_line != NULL)
free(replot_line);
// Clear multiplot mode, if it was active
if (multiplot)
term_end_multiplot();
// Close current file
if (gpoutfile)
fclose(gpoutfile);
The other issue is that gnuplot is written to use stdin and stdout so for my apps I replaced them with my own appropriate file descriptors to serve as the interface to/from gnuplot. That will be implementation specific, so I won't list my own particular changes but you'll basically need to look through the gnuplot source for instances of stdin and stdout and replace them as appropriate for your needs.
You'll also want to #define NO_GIH in config.h.
Other than that, you'll probably need to hard code the appropriate gnuplot terminal type for your app (I used SVG in my apps).
I hope this helps.
Best Regards,
Antonio Lagana
I am trying to create a code coverage tool using Delphi 2007.
My general approach is to use the Win32 Debug API to insert breakpoints for each source line and then remove the breakpoints as I pass them - thus I would be able to track each executed source line.
Outline of my approach:
parse the detailed MAP file (as generated by Delphi 2007) to find all the addresses for each source line (only for .text segments)
open the application in debug mode using the OpenProcess API call
iterate over each source line and insert an Int3 instruction (one $cc byte using WriteProcessMemory + FlushInstructionCache) at the address of each line
continue executing and as each breakpoint is triggered, remove the corresponding breakpoint and mark the line as covered
After either each breakpoint is passed or program exists I generate a report on what lines were covered and which lines were not for each source module
Now on to my question:
Is each source line address in a detailed MAP file a valid address to insert an Int3 breakpoint?
While the approach was successful for some simple units, I run in to access violations for some larger applications where the violated address includes a $cc - which would lead me to think that my approach needs some modification to work.
Hints on better approaches also very welcome!
Well, in theory: yes. And practical, I think yes too. If Delphi can place a breakpoint on every line, so can you :-).
Probably you need some specific handling for some case (for example: first line of a procedure is initialization of local vars, setting EBP etc).
So can you find out in which case it fails?
Btw: nice project! Is it open source?
P.S. if you need some assembly code handling: look at koldetours.pas (use google search).