Open-source News

Tailoring your Linux command prompt  Network World

A week after seeing X.Org display driver updates for old Trident and S3 Graphics hardware, a new release of xf86-video-ark is now available that provides the open-source UMS display driver support for old ARK Logic hardware. ARK Logic only lasted through the 1990's as a purveyor of PCI video cards...

Computop debuts three new Linux-based payment terminals  Finextra

As part of the Linux networking updates for the Linux 6.3 cycle in addition to the BIG TCP support for IPv4 that can yield higher throughput and lower latency, another networking change worth pointing out is the introduction of the "ath12k" driver for Qualcomm WiFi 7 hardware support...

Linux 6.3 Adds ath12k Driver For Qualcomm WiFi 7 Hardware Support  Phoronix

Linus Torvalds Reacts to Poorly-Executed Pull Requests for Linux 6.3  It's FOSS News

Microsoft .NET 8 bolsters Linux support  InfoWorld

How I do automated accessibility testing for my website dmundra Wed, 02/22/2023 - 03:00

This article covers adding accessibility tests to your site using Pa11y (pa11y-ci with axe) and Cypress (with cypress-axe) in GitLab CI/CD. I use a Jekyll website as an example, but any website technology that runs in CI/CD can leverage this setup.

Prep your website

In addition to getting your website to run in CI/CD, I recommend enabling an XML sitemap feature. A sitemap allows the accessibility tests to parse all URLs to find accessibility issues across the site. I recommend the jekyll-sitemap plugin for Jekyll sites.

Collecting a list of all major URLs is a good alternate step if a sitemap is not possible. The URLs should cover all potential layouts of the website, such as pages with the highest traffic or the most landings. This approach won't catch all accessibility issues, especially content level concerns, but it will test the layout and main pages.

This scenario requires the npm or yarn package managers. I used npm for this article. If your project doesn't have npm initialized, run the npm init command to create the package.json file.

Begin with Pa11y

Pa11y is a free and open source software that tests websites for accessibility issues. Pa11y-ci is the command line utility geared towards continuous integration (CI). Install pa11y-ci as a development dependency with npm:

$ npm i --save-dev pa11y-ci

After you complete the installation, edit the package.json and add the following commands to the scripts section:

"start-detached": "bundle exec jekyll serve --detach", "pa11y-ci:home": "pa11y-ci http://127.0.0.1:4000", "pa11y-ci:sitemap": "pa11y-ci --sitemap http://127.0.0.1:4000/sitemap.xml --sitemap-find https://accessibility.civicactions.com --sitemap-replace http://127.0.0.1:4000 --sitemap-exclude \"/*.pdf\""

• start-detached: Starts the web server that will run Jekyll for testing.
• pa11y-ci:home: Runs pa11y-ci tests on the home page. Useful for troubleshooting.
• pa11y-ci:sitemap: Runs pa11y-ci tests using the sitemap and excludes PDFs. The sitemap will refer to the live site URLs, so replace those with local URLs for testing in the CI pipeline.

Add a JSON file named .pa11yci that configures pa11y-ci with various options. Here is a sample file:

{ "defaults": { "concurrency": 1, "standard": "WCAG2AA", "runners": ["axe", "htmlcs"], "ignore": [ "color-contrast", "frame-tested" ], "chromeLaunchConfig": { "args": ["--disable-dev-shm-usage", "--no-sandbox", "--disable-gpu"] }, "reporters": [ "cli", ["./pa11y-reporter-junit.js", { "fileName": "./pa11y-report-junit.xml" }] ] } }

• concurrency: I reduced this set to 1 because increasing it caused errors (https://github.com/pa11y/pa11y-ci/issues/168 covers the bug, which might be fixed).
• standard: I have stuck with the default WCAG2AA as the goal for this site.
• runners: I ran axe (run tests using axe-core) and htmlcs (default, run tests using HTML CodeSniffer) to cover all potential accessibility issues.
• ignore: With newer versions of axe and some of the changes to the site, I ran into color contrast false positives. I also have an embedded iframe that requires separate testing that axe will report about. I have follow-up issues to examine the axe results, so I am ignoring those criteria for now.
• chromeLaunchConfig: pa11y-ci uses Chrome, and I found that the GitLab CI pipeline requires that the Chrome browser runs properly in the pipeline.
• reports: I use the default command line reporter, but I also added a custom reporter that reports on the pa11y-ci results in a junit format. This came in handy for reporting the results in the GitLab CI pipeline.

That's it. Run this setup locally using npm, and you will see the following output (truncated for brevity):

dmundra in ~/workspace/accessibility/accessibility on branch main > npm run start-detached > start-detached > bundle exec jekyll serve --detach Configuration file: /Users/dmundra/workspace/accessibility/accessibility/_config.yml Source: /Users/dmundra/workspace/accessibility/accessibility Destination: /Users/dmundra/workspace/accessibility/accessibility/_site Incremental build: disabled. Enable with --incremental Generating... done in 8.217 seconds. Auto-regeneration: disabled when running server detached. Server address: http://127.0.0.1:4000 Server detached with pid '14850'. Run `pkill -f jekyll' or `kill -9 14850' to stop the server. dmundra in ~/workspace/accessibility/accessibility on branch main > npm run pa11y-ci:sitemap > pa11y-ci:sitemap > pa11y-ci --sitemap http://localhost:4000/sitemap.xml --sitemap-exclude "/*.pdf" Running Pa11y on 110 URLs: > http://localhost:4000/guide/glossary - 0 errors > http://localhost:4000/guide/introduction - 0 errors > http://localhost:4000/guide/history - 0 errors > http://localhost:4000/guide/design - 0 errors ... ✔ 110/110 URLs passed

The site passes the tests. Here is an example job running in GitLab. The pa11y configuration continues to test all site pages for accessibility issues and report on them.

What does an error look like? Here is an example:

> http://localhost:4000/guide/introduction - 1 errors Errors in http://localhost:4000/guide/introduction: •

and
must only directly contain
1. , or elements (https://dequeuniversity.com/rules/axe/3.5/list?application=axeAPI) (#main-content > div:nth-child(2) > div > div > div > div:nth-child(1) > nav > ul)

   You get a count of the number of errors at a given URL and then details on the accessibility issue. It also displays a link to the criteria being violated and the location in the HTML of the issue.

   Try Cypress

   Cypress is a JavaScript testing framework and is very helpful in writing tests that interact with the site and assert that features work as expected. The setup for Cypress is very similar to pa11y-ci in terms of installation with npm.

   $ npm i --save-dev cypress cypress-axe cypress-real-events

   After the installation is complete, edit the package.json and add the following commands to the scripts section:

   "cypress-tests": "cypress run --browser chrome --headless"
   • cypress-tests: Run the Cypress tests with a headless Chrome browser.

   When launching Cypress for the first time, you get a wizard to create the configuration file. Here is a sample file:

   const { defineConfig } = require('cypress') module.exports = defineConfig({ video: true, videosFolder: 'cypress/results', reporter: 'junit', reporterOptions: { mochaFile: 'cypress/results/junit.[hash].xml', toConsole: false, }, screenshotsFolder: 'cypress/results/screenshots', e2e: { // We've imported your old cypress plugins here. // You may want to clean this up later by importing these. setupNodeEvents(on, config) { return require('./cypress/plugins/index.js')(on, config) }, baseUrl: 'http://localhost:4000', }, })
   • video: Take videos of the tests, which are helpful for troubleshooting.
   • videosFolder: Defines the video storage folder.
   • reporter: Set to junit to make it easier to report the results in the GitLab CI pipeline.
   • reporterOptions: Includes a path for the junit files and the keyword [hash] to preserve unique reports for each test file (otherwise, the file is overwritten). Skip the console output for the reporter and use the default output.
   • screenshotsFolder: Defines the screenshot storage folder (useful for troubleshooting).
   • e2e: References the local URL of the site and the plugins.

   After setting up Cypress and writing some tests (see below for examples), run the tests locally using npm. You will see the following output (truncated for brevity):

   dmundra in ~/workspace/accessibility/accessibility on branch main > npm run cypress-tests > cypress-tests > cypress run --browser chrome --headless ==================================================================================================== (Run Starting) ┌────────────────────────────────────────────────────────────────────────────────────────────────┐ │ Cypress: 11.2.0 │ │ Browser: Chrome 109 (headless) │ │ Node Version: v18.10.0 (/usr/local/Cellar/node/18.10.0/bin/node) │ │ Specs: 5 found (accordion.cy.js, home.cy.js, images.cy.js, menu.cy.js, search.cy.js) │ │ Searched: cypress/e2e/**/*.cy.{js,jsx,ts,tsx} │ └────────────────────────────────────────────────────────────────────────────────────────────────┘ ──────────────────────────────────────────────────────────────────────────────────────────────────── Running: search.cy.js (5 of 5) (Results) ┌────────────────────────────────────────────────────────────────────────────────────────────────┐ │ Tests: 1 │ │ Passing: 1 │ │ Failing: 0 │ │ Pending: 0 │ │ Skipped: 0 │ │ Screenshots: 0 │ │ Video: true │ │ Duration: 2 seconds │ │ Spec Ran: search.cy.js │ └────────────────────────────────────────────────────────────────────────────────────────────────┘ (Video) - Started processing: Compressing to 32 CRF - Finished processing: /Users/dmundra/workspace/accessibility/accessibility/cypres (0 seconds) s/results/search.cy.js.mp4 ... (Run Finished) Spec Tests Passing Failing Pending Skipped ┌────────────────────────────────────────────────────────────────────────────────────────────────┐ │ ✔ search.cy.js 00:02 1 1 - - - │ ...

   While Pa11y-ci can test interactivity, Cypress and its plugins can do much more. For a Jekyll site, I found that pa11y-ci did not catch any accessibility issues in mobile drop-down menu, dynamic search, or accordion features. I ran Cypress tests to interact with the elements (like performing searches, clicking menus, or clicking the accordion) and then checked if the results still passed accessibility tests. Here is the search example:

   describe('Search', () => { it('should be accessible', () => { cy.visit('/search') cy.get('#search-input').type('accessibility') cy.checkA11yWithMultipleViewPorts() }) })

   Here is a quick video of the running test.

   The above test visits the search page, types the word "accessibility" in the search field, and then checks the results for accessibility issues. I use the cypress-axe plugin to check accessibility issues with axe core, just like pa11y-ci. I have wrapped the cypress-axe functions in a function to test multiple window sizes and report on the issues in a table format.

   I also use the plugin cypress-real-events to interact with the site with a keyboard to check that the features are keyboard-accessible. Keyboard accessibility is a critical consideration (Operable principle of WCAG), and having an automated test that can confirm the features are keyboard accessible means that, maybe, there is one less test to run manually. You can see an example of the test here.

   Here is an example of what an error looks like:

   Running: a11y/anonymous_a11y.cy.js (1 of 36) cy.log(): Accessibility scanning: Home (/) cy.log(): 4 accessibility violations were detected ┌─────────┬────────────────────────┬────────────┬────────────────────────────────────────────────────────────────────────────────────┬───────┐ │ (index) │ id │ impact │ description │ nodes │ ├─────────┼────────────────────────┼────────────┼────────────────────────────────────────────────────────────────────────────────────┼───────┤ │ 0 │ 'image-alt' │ 'critical' │ 'Ensures elements have alternate text or a role of none or presentation' │ 4 │ │ 1 │ 'link-name' │ 'serious' │ 'Ensures links have discernible text' │ 3 │ │ 2 │ 'page-has-heading-one' │ 'moderate' │ 'Ensure that the page, or at least one of its frames contains a level-one heading' │ 1 │ │ 3 │ 'region' │ 'moderate' │ 'Ensures all page content is contained by landmarks' │ 2 │ └─────────┴────────────────────────┴────────────┴────────────────────────────────────────────────────────────────────────────────────┴───────┘

   Cypress logs provide a count of the number of errors at a given URL and then details on what the accessibility issue is, the impact, and its location.

   You can find additional details and examples in the Cypress folder.

   Use the GitLab CI/CD

   Now that you have pa11y-ci and Cypress running locally, see how to run automated accessibility tests in GitLab using CI/CD features. The GitLab repository is available here. Here is the .gitlab-ci.yml file setup:

   stages: - test cache: key: ${CI_COMMIT_REF_SLUG} paths: - node_modules/ - .npm/ - vendor/ruby default: image: ruby:2 before_script: - apt-get update - apt-get install -yq gconf-service libasound2 libatk1.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libglib2.0-0 libgtk-3-0 libnspr4 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 ca-certificates fonts-liberation libnss3 lsb-release xdg-utils wget libgbm1 xvfb - apt-get install -y nodejs npm - bundle install -j $(nproc) --path vendor/ruby - npm ci --cache .npm --prefer-offline - npm run start-detached pa11y-tests: stage: test script: - npm run pa11y-ci:sitemap artifacts: when: always reports: junit: - pa11y-report-junit.xml expire_in: 1 day cypress-tests: stage: test script: # Install chrome browser manually, taken from https://github.com/cypress-io/cypress-docker-images/blob/master/browsers/node16.14.2-slim-chrome100-ff99-edge/Dockerfile#L48 - wget --no-verbose -O /usr/src/google-chrome-stable_current_amd64.deb "http://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_105.0.5195.125-1_amd64.deb" - dpkg -i /usr/src/google-chrome-stable_current_amd64.deb - rm -f /usr/src/google-chrome-stable_current_amd64.deb - npm run cypress-tests artifacts: when: always paths: - cypress/results/ reports: junit: - cypress/results/*.xml expire_in: 1 day

   The file currently defines only one stage test and caches folders that store dependencies when installed. Then:

   1. Steps used by all stages:
      1. Use the Ruby version 2 image because it is compatible with the current Jekyll installation.
      2. I install many dependencies based on the documentation at running puppeteer on GitLab. Install node and npm to install site dependencies.
      3. Install the Jekyll Ruby dependencies.
      4. Install the Cypress and pa11y-ci dependencies via npm.
      5. Start the web server.
   2. Run the pa11y-ci to test the site and capture the output to a file.*
   3. Install the Chrome browser dependencies in cypress-tests using steps provided by Cypress in their Docker image configurations. Run the Cypress tests and capture the output to files.*

   * Capture the output of Cypress and pa11y-ci tests as junit XML files.

   Here is an example screenshot of the GitLab pipeline (taken from https://gitlab.com/civicactions/accessibility/-/pipelines/744894072):

   Image by:

   (Daniel Mundra, CC BY-SA 4.0)

   Here is an example of the test results in the same pipeline:

   Image by:

   (Daniel Mundra, CC BY-SA 4.0)

   Our favorite resources about open source Git cheat sheet Advanced Linux commands cheat sheet Open source alternatives Free online course: RHEL technical overview Check out more cheat sheets

   GitLab CI/CD automatically take junit XML files and outputs them in a clear format. Cypress tests provide the junit XML output as part of their features (see above). I created a custom reporter for pa11y-ci to output the format in junit (credit to macieklewkowicz/pa11y-reporter-junit).

   Note: GitLab version 12.8+ supports Pa11y accessibility tests (see https://docs.gitlab.com/ee/ci/testing/accessibility_testing.html for details). The above setup allows for customization of the pa11y-ci and also targeting of local URLs. I recommend using their options for live sites.

   Wrap up

   Using the above steps, you can provide accessibility testing for your site locally and in CI. This process helps you track and fix accessibility issues on your site and in the content. An important caveat about automated testing is that it only catches 57% of issues, so you definitely want to include manual testing with your accessibility testing.

   Further reading and examples
   • Automated accessibility testing: Leveraging GitHub Actions and pa11y-ci with axe.
   • Automated accessibility testing with Travis CI.
   • How to Automate Web Accessibility Testing.
   • Setting up Cypress with axe for accessibility - Tim Deschryver.
   • GitLab CI | Cypress Documentation.

   Thank you to Marissa Fox and Mike Gifford for your support, thoughts, and feedback.

   Follow along with this example of performing accessibility tests in GitLab with Pa11y and Cypress on a Jekyll website.

   Accessibility GitLab What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

Mapping the program counter back to the function name in your code wcohen Wed, 02/22/2023 - 03:00

Compilers are commonly used to convert human-readable source code into a series of instructions that are directly executed by the computer. A common question is "How do the debuggers and error handlers report the place in the source code where the processor is currently at?" There are various methods to map instructions back to locations in the source code. With the compiler optimizing the code, there are also some complications in mapping the instructions back to the source code. This first article in the series describes how tools map the program counter (also known as the instruction pointer) back to the function name. Subsequent articles in this series will cover mapping the program counter back to the specific line in a source file. It also provides a backtrace describing the series of calls that resulted in the processor being in the current function.

The function entry symbols

When translating source code into an executable binary, the compiler keeps symbol information about the entry to each function. Keeping this information available makes it possible for the linker to assemble multiple object files (.o suffix) into a single executable file. Before the object files are processed by the linker, the final addresses of functions and variables are not known. The object files have placeholders for the symbols that do not yet have addresses. The linker will resolve the addresses when creating the executable. Assuming that the resulting executable is not stripped, those symbols describing the entry of each function are still available. You can see an example of this by compiling the following simple program:

#include #include int a; double b; int main(int argc, char* argv[]) { a = atoi(argv[1]); b = atof(argv[2]); a = a + 1; b = b / 42.0; printf ("a = %d, b = %f\n", a, b); return 0; }

Compile the code:

$ gcc -O2 example.c -o example

You can see where the main function starts at 0x401060 with the following command:

$ nm example |grep main U __libc_start_main@GLIBC_2.34 0000000000401060 T main

Even though the code is compiled without debugging information (-g option), gdb can still find the start of the main function with the symbol information:

$ gdb example GNU gdb (GDB) Fedora 12.1-1.fc36 … (No debugging symbols found in example) (gdb) break main Breakpoint 1 at 0x401060

Step through the code with the GDB nexti command. GDB reports the address it is currently at in the main function:

(gdb) nexti 0x0000000000401061 in main () (gdb) nexti 0x0000000000401065 in main () (gdb) where #0 0x0000000000401065 in main ()

This minimal information is useful but is not ideal. The compiler can optimize functions and split functions into non-contiguous sections to make code associated with the function not obviously tied to the listed function entry. A portion of the function's instructions might be separated from the function entry by other functions' entries. Also, the compiler may generate alternative names that do not directly match the original function names. This makes it more difficult to determine which function in the source code the instructions are associated with.

DWARF information

Code compiled with the -g option includes additional information to map between the source code and the binary executable. By default RPMs with code compiled on Fedora have the debug information generation enabled. Then this information is put into a separate debuginfo RPM, which can be installed as a supplement to the RPMs containing the binaries. This makes it easier to analyze crash dumps and debug programs. With debuginfo, you can get address ranges that map back to particular function names. It also provides the line number and file name that each instruction maps back to. The mapping information is encoded in the DWARF standard.

The DWARF function description

For each function with a function entry there is a DWARF Debug Information Entry (DIE) describing it. This information is in a machine-readable format, but there are a number of tools including llvm-dwarfdump and eu-readelf that produce human-readable output of the DWARF debug information. Below is the llvm-dwarfdump output of the example main function DIE describing the main function of the earlier example.c program.

The DIE starts with the DW_TAG_subprogram to indicate it describes a function. There are other kinds of DWARF tags used to describe other components of programs such as types and variables.

The DIE for the function has multiple attributes each starting with DW_AT_ that describe the characteristics of the function. These attributes provide information about the function, such as where the function is located in the executable binary. It also points where to find it in the original source code.

A few lines down from the DW_TAG_subprogram is the DW_AT_name attribute that describes the source code function name as main. The DW_AT_decl_file and DW_AT_decl_line DWARF attributes describe the file and line number respectively where the function came from. This allows the debugger to find the appropriate location in a file to show you the source code associated with the function. Column information is also included with the DW_AT_decl_column.

The other key pieces of information for mapping between the binary instructions and the source code are the DW_AT_low_pc and DW_AT_high_pc attributes. The use of the DW_AT_low_pc and DW_AT_high_pc indicates that the code for this function is contiguous, ranging from 0x401060 (the same value as provided by nm command earlier) up to but not including 0x4010b7. The DW_AT_ranges attribute is used to describe functions if the function covers non-contiguous regions.

With the program counter, you can map the processor's program counter to the function name and find the file and line number where the function is:

$ llvm-dwarfdump example --name=main example: file format elf64-x86-64 0x00000113: DW_TAG_subprogram DW_AT_external (true) DW_AT_name ("main") DW_AT_decl_file ("/home/wcohen/present/202207youarehere/example.c") DW_AT_decl_line (8) DW_AT_decl_column (0x01) DW_AT_prototyped (true) DW_AT_type (0x00000031 "int") DW_AT_low_pc (0x0000000000401060) DW_AT_high_pc (0x00000000004010b7) DW_AT_frame_base (DW_OP_call_frame_cfa) DW_AT_call_all_calls (true) DW_AT_sibling (0x000001ea)Inlined functions

A compiler can optimize code by replacing a call to another function with instructions that implement the operations of that called function. An inlined function eliminates control flow changes caused by function call and return instructions to implement the traditional function calls. For an inlined function, there is no need for executing additional function prologue and epilogue instructions required to conform to the Application Binary Interface (ABI) of traditional function calls.

Inline functions also provide additional opportunities for optimizations as the compiler can intermix instructions between the caller and the inlined invoked function. This provides a complete picture of what code can safely be eliminated. However, if you just used the address ranges from the real functions described by the DW_TAG_subprogram, then you might misattribute an instruction to the function that called the inlined function, rather than the actual inlined function containing it. For that reason, DWARF has the DW_TAG_inlined_subroutine to provide information about inlined functions.

Surprisingly, even example.c, the simple example provided in this article, has inlined functions in the generated code, atoi and atof. The code block below shows the output of llvm-dwarfdump for atoi. There are two parts, a DW_TAG_inlined_subroutine to describe each place atoi was actually inlined and a DW_TAG_subprogram describing the generic information that does not change between the multiple inlined copies.

The DW_AT_abstract_origin in the DW_TAG_inlined_subroutine points to the associated DW_TAG_subprogram that describes the file with DW_AT_decl_file and DW_AT_decl_line just like a DWARF DIE describing a regular function. In this case, you see that this inlined function is coming from line 362 of system file /usr/include/stdlib.h.

The actual range of addresses that are associated with atof is non-contiguous and described by DW_AT_ranges, [0x401060,0x401060), [0x401061, 0x401065), [0x401068,0x401074), and [0x40107a,0x41080). The DW_TAG_inlined_subroutine has a DW_AT_entry_pc to indicate what location is considered to be the start of the inlined function. With the compiler reordering instructions it may not be obvious what would be considered the first instruction of an inlined function:

$ llvm-dwarfdump example --name=atoi example: file format elf64-x86-64 0x00000159: DW_TAG_inlined_subroutine DW_AT_abstract_origin (0x00000208 "atoi") DW_AT_entry_pc (0x0000000000401060) DW_AT_GNU_entry_view (0x02) DW_AT_ranges (0x0000000c [0x0000000000401060, 0x0000000000401060) [0x0000000000401061, 0x0000000000401065) [0x0000000000401068, 0x0000000000401074) [0x000000000040107a, 0x0000000000401080)) DW_AT_call_file ("/home/wcohen/present/202207youarehere/example.c") DW_AT_call_line (10) DW_AT_call_column (6) DW_AT_sibling (0x00000196) 0x00000208: DW_TAG_subprogram DW_AT_external (true) DW_AT_name ("atoi") DW_AT_decl_file ("/usr/include/stdlib.h") DW_AT_decl_line (362) DW_AT_decl_column (0x01) DW_AT_prototyped (true) DW_AT_type (0x00000031 "int") DW_AT_inline (DW_INL_declared_inlined)

Programming and development Red Hat Developers Blog Programming cheat sheets Try for free: Red Hat Learning Subscription eBook: An introduction to programming with Bash Bash shell scripting cheat sheet eBook: Modernizing Enterprise Java An open source developer's guide to building applications Implications of inline functions

Most programmers think of the processor completely executing one line in the source code before moving on to the next. Similarly, with the expected function call ABI  programmers think of where the caller function completes operations in the statements before the call and statements after the call are not started until the callee function return may not hold. With inlined function, the boundaries between functions become fuzzy. Instructions from the caller function may be scheduled before or after the instructions from the inlined functions regardless of where they were in the source code if the compiler determines that the final result will be the same. This may lead to unexpected values when inspecting variables before and after the inlined functions.

Further reading

This article covers a very small part of how the mapping between source code and the executable binary is implemented with DWARF. As a starting point to learn more about DWARF, you might read Introduction to the DWARF Debugging Format by Michael J. Eager. Look for upcoming articles about how the instructions in the functions are mapped back to the source code and how backtraces are generated.

This article covers how the mapping between source code and the executable binary is implemented with DWARF.

Image by:

opensource.com

Programming What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

Embedded Linux Market Size 2023 Research Analysis by Market ...  Digital Journal

The post How to Add a Package Repository to Debian, Ubuntu and Mint first appeared on Tecmint: Linux Howtos, Tutorials & Guides .

A package repository (repo in short) is a location where software packages are stored and can be retrieved from. It is organized in a special directory tree, and usually contains an index file and

The post How to Add a Package Repository to Debian, Ubuntu and Mint first appeared on Tecmint: Linux Howtos, Tutorials & Guides.

Linux 6.3 Introduces IPv4 "BIG TCP" To Improve High Speed Network Performance  Phoronix

The networking subsystem feature updates for the Linux 6.3 kernel were submitted today that feature not only some prominent networking driver enhancements and new wired/wireless hardware support but also core networking improvements like BIG TCP for IPv4...

Red Hat brings in free partner subscriptions - Strategy - Software  CRN Australia

Linux 6.2: The First Mainstream Linux Kernel for Apple M1 Chips ...  Slashdot

Linux 6.2 Makes Apple Silicon Support Official  MUO - MakeUseOf

Linux 6.2 Brings Network-Related Updates, Adds 800 Gbps and ...  SDxCentral

GParted 1.5 Enables Repair When Checking exFAT File Systems  9to5Linux

The Clutter OpenGL "Cogl" code within the GNOME Mutter compositor has removed legacy OpenGL driver support ahead of next month's GNOME 44 release...

The Linux 6.3 merge window has been off to a good start with Linus Torvalds receiving plenty of pull requests in advance, the other early pulls all coming in quite orderly, and no colorful commentary on any of the material set for Linux 6.3 even with the likes of Microsoft Pluton (TPM2 CRB). But today Torvalds' did feel the need to share some wisdom around Git merge log message advice...