[DWARF] Don't attempt to parse line tables at invalid offsets
Whilst working on improvements to the error handling of the debug line
parsing code, I noticed that if an invalid offset were to be specified
in a call to getOrParseLineTable(), an entry in the LineTableMap would
still be created, even if the offset was not within the section range.
The immediate parsing attempt afterwards would fail (it would end up
getting a version of 0), and thereafter, any subsequent calls to
getOrParseLineTable or getLineTable would return the default-
constructed, invalid line table. In reality, we shouldn't even attempt
to parse this table, and we should always return a nullptr from these
two functions for this situation.
I have tested this via a unit test, which required some new framework
for unit testing debug line. My plan is to add quite a few more unit
tests for the new error reporting mechanism that will follow shortly,
hence the reason why the supporting code for the tests are written the
way they are - I intend to extend the DwarfGenerator class to support
generating debug line. At that point, I'll make sure that there are a
few positive test cases for this and the parsing code too.
Differential Revision: https://reviews.llvm.org/D44200
Reviewers: JDevlieghere, aprantl
llvm-svn: 326995
2018-03-08 11:53:34 +01:00
|
|
|
//===--- unittests/DebugInfo/DWARF/DwarfUtils.cpp ---------------*- C++ -*-===//
|
|
|
|
//
|
2019-01-19 09:50:56 +01:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
[DWARF] Don't attempt to parse line tables at invalid offsets
Whilst working on improvements to the error handling of the debug line
parsing code, I noticed that if an invalid offset were to be specified
in a call to getOrParseLineTable(), an entry in the LineTableMap would
still be created, even if the offset was not within the section range.
The immediate parsing attempt afterwards would fail (it would end up
getting a version of 0), and thereafter, any subsequent calls to
getOrParseLineTable or getLineTable would return the default-
constructed, invalid line table. In reality, we shouldn't even attempt
to parse this table, and we should always return a nullptr from these
two functions for this situation.
I have tested this via a unit test, which required some new framework
for unit testing debug line. My plan is to add quite a few more unit
tests for the new error reporting mechanism that will follow shortly,
hence the reason why the supporting code for the tests are written the
way they are - I intend to extend the DwarfGenerator class to support
generating debug line. At that point, I'll make sure that there are a
few positive test cases for this and the parsing code too.
Differential Revision: https://reviews.llvm.org/D44200
Reviewers: JDevlieghere, aprantl
llvm-svn: 326995
2018-03-08 11:53:34 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "DwarfUtils.h"
|
|
|
|
#include "llvm/ADT/Triple.h"
|
2018-04-30 16:59:11 +02:00
|
|
|
#include "llvm/Config/llvm-config.h"
|
2019-06-04 00:22:03 +02:00
|
|
|
#include "llvm/Support/Host.h"
|
[DWARF] Don't attempt to parse line tables at invalid offsets
Whilst working on improvements to the error handling of the debug line
parsing code, I noticed that if an invalid offset were to be specified
in a call to getOrParseLineTable(), an entry in the LineTableMap would
still be created, even if the offset was not within the section range.
The immediate parsing attempt afterwards would fail (it would end up
getting a version of 0), and thereafter, any subsequent calls to
getOrParseLineTable or getLineTable would return the default-
constructed, invalid line table. In reality, we shouldn't even attempt
to parse this table, and we should always return a nullptr from these
two functions for this situation.
I have tested this via a unit test, which required some new framework
for unit testing debug line. My plan is to add quite a few more unit
tests for the new error reporting mechanism that will follow shortly,
hence the reason why the supporting code for the tests are written the
way they are - I intend to extend the DwarfGenerator class to support
generating debug line. At that point, I'll make sure that there are a
few positive test cases for this and the parsing code too.
Differential Revision: https://reviews.llvm.org/D44200
Reviewers: JDevlieghere, aprantl
llvm-svn: 326995
2018-03-08 11:53:34 +01:00
|
|
|
#include "llvm/Support/TargetRegistry.h"
|
|
|
|
#include "llvm/Support/TargetSelect.h"
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
static void initLLVMIfNeeded() {
|
|
|
|
static bool gInitialized = false;
|
|
|
|
if (!gInitialized) {
|
|
|
|
gInitialized = true;
|
|
|
|
InitializeAllTargets();
|
|
|
|
InitializeAllTargetMCs();
|
|
|
|
InitializeAllAsmPrinters();
|
|
|
|
InitializeAllAsmParsers();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-04 00:22:03 +02:00
|
|
|
Triple llvm::dwarf::utils::getNormalizedDefaultTargetTriple() {
|
|
|
|
Triple T(Triple::normalize(sys::getDefaultTargetTriple()));
|
[DWARF] Don't attempt to parse line tables at invalid offsets
Whilst working on improvements to the error handling of the debug line
parsing code, I noticed that if an invalid offset were to be specified
in a call to getOrParseLineTable(), an entry in the LineTableMap would
still be created, even if the offset was not within the section range.
The immediate parsing attempt afterwards would fail (it would end up
getting a version of 0), and thereafter, any subsequent calls to
getOrParseLineTable or getLineTable would return the default-
constructed, invalid line table. In reality, we shouldn't even attempt
to parse this table, and we should always return a nullptr from these
two functions for this situation.
I have tested this via a unit test, which required some new framework
for unit testing debug line. My plan is to add quite a few more unit
tests for the new error reporting mechanism that will follow shortly,
hence the reason why the supporting code for the tests are written the
way they are - I intend to extend the DwarfGenerator class to support
generating debug line. At that point, I'll make sure that there are a
few positive test cases for this and the parsing code too.
Differential Revision: https://reviews.llvm.org/D44200
Reviewers: JDevlieghere, aprantl
llvm-svn: 326995
2018-03-08 11:53:34 +01:00
|
|
|
|
2019-06-04 00:22:03 +02:00
|
|
|
return T;
|
|
|
|
}
|
|
|
|
|
|
|
|
Triple llvm::dwarf::utils::getDefaultTargetTripleForAddrSize(uint8_t AddrSize) {
|
|
|
|
Triple T = getNormalizedDefaultTargetTriple();
|
|
|
|
|
|
|
|
assert((AddrSize == 4 || AddrSize == 8) &&
|
|
|
|
"Only 32-bit/64-bit address size variants are supported");
|
|
|
|
|
|
|
|
// If a 32-bit/64-bit address size was specified, try to convert the triple
|
|
|
|
// if it is for the wrong variant.
|
[DWARF] Don't attempt to parse line tables at invalid offsets
Whilst working on improvements to the error handling of the debug line
parsing code, I noticed that if an invalid offset were to be specified
in a call to getOrParseLineTable(), an entry in the LineTableMap would
still be created, even if the offset was not within the section range.
The immediate parsing attempt afterwards would fail (it would end up
getting a version of 0), and thereafter, any subsequent calls to
getOrParseLineTable or getLineTable would return the default-
constructed, invalid line table. In reality, we shouldn't even attempt
to parse this table, and we should always return a nullptr from these
two functions for this situation.
I have tested this via a unit test, which required some new framework
for unit testing debug line. My plan is to add quite a few more unit
tests for the new error reporting mechanism that will follow shortly,
hence the reason why the supporting code for the tests are written the
way they are - I intend to extend the DwarfGenerator class to support
generating debug line. At that point, I'll make sure that there are a
few positive test cases for this and the parsing code too.
Differential Revision: https://reviews.llvm.org/D44200
Reviewers: JDevlieghere, aprantl
llvm-svn: 326995
2018-03-08 11:53:34 +01:00
|
|
|
if (AddrSize == 8 && T.isArch32Bit())
|
|
|
|
return T.get64BitArchVariant();
|
|
|
|
if (AddrSize == 4 && T.isArch64Bit())
|
|
|
|
return T.get32BitArchVariant();
|
|
|
|
return T;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool llvm::dwarf::utils::isConfigurationSupported(Triple &T) {
|
|
|
|
initLLVMIfNeeded();
|
|
|
|
std::string Err;
|
|
|
|
return TargetRegistry::lookupTarget(T.getTriple(), Err);
|
|
|
|
}
|
2020-09-14 19:17:11 +02:00
|
|
|
|
|
|
|
bool llvm::dwarf::utils::isObjectEmissionSupported(Triple &T) {
|
|
|
|
initLLVMIfNeeded();
|
|
|
|
std::string Err;
|
|
|
|
const Target *TheTarget = TargetRegistry::lookupTarget(T.getTriple(), Err);
|
|
|
|
return TheTarget && TheTarget->hasMCAsmBackend();
|
|
|
|
}
|